init-mode
Skill3.4k starsChanged 2 months agoMITView on GitHub
Team initialization flow (Phase 1 proposal + Phase 2 creation)
3 other projects use a version of this, 3 of them edited.
Adopted by
Most recently taken up by
- microsoft/github-vteam-industry-demosedited, first seen Oct 25, 2026
- github/gh-awedited, first seen May 27, 2026
- Azure/apiops-cliedited, first seen Apr 27, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 3
- github/gh-aw★ 5.6k85% same
- Azure/apiops-cli★ 3295% same
- microsoft/github-vteam-industry-demos★ 298% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository247 other files it gives its agents.
- .github/agents.mdAGENTS.md
- .github/copilot-instructions.mdCopilot instructions
- packages/squad-cli/templates/copilot-instructions.mdCopilot instructions
- packages/squad-sdk/templates/copilot-instructions.mdCopilot instructions
- .squad-templates/copilot-instructions.mdCopilot instructions
- .squad/templates/copilot-instructions.mdCopilot instructions
- templates/copilot-instructions.mdCopilot instructions
- action-skill-contractsSkill
- agent-collaborationSkill
- agent-conductSkill
- architectural-proposalsSkill
- architectural-reviewSkill
- archival-integritySkill
- ci-validation-gatesSkill
- client-compatibilitySkill
- cli-wiringSkill
- content-scopeSkill
- distributed-meshSkill
- documentation-maintenanceSkill
- github-multi-accountSkill
- git-workflowSkill
- history-hygieneSkill
- model-selectionSkill
- pr-lifecycleSkill
- protected-filesSkill
- release-processSkill
- reskillSkill
- reviewer-protocolSkill
- secret-handlingSkill
- security-reviewSkill
- squad-conventionsSkill
- test-disciplineSkill
- windows-compatibilitySkill
- agentic-workflow-designerSkill
- gh-aw-reliabilitySkill
- iterative-retrievalSkill
- reflectSkill
- {skill-name}Skill
- agent-collaborationSkill
- agent-conductSkill
- architectural-proposalsSkill
- ci-validation-gatesSkill
- client-compatibilitySkill
- cli-wiringSkill
- coordinator-init-modeSkill
- coordinator-response-modeSkill
- coordinator-source-of-truthSkill
- cross-machine-coordinationSkill
- cross-squad-communicationSkill
- cross-squadSkill
- distributed-meshSkill
- docs-standardsSkill
- e2e-template-testingSkill
- economy-modeSkill
- error-recoverySkill
- external-commsSkill
- fact-checkingSkill
- gh-auth-isolationSkill
- gh-aw-enlistmentSkill
- github-multi-accountSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
6 rules. 3 are common, 0 are distinctive, and 3 are very specific to this project.
3
Common
Most of the 3 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Common: line 21
No team exists yet. Propose one — but DO NOT create any files until the user confirms.
- Common: line 24
Ask: *"What are you building?
- Common: line 25
Cast the team: Before proposing names, run the Casting & Persistent Naming algorithm (see that section):
- Very specific: line 43
Use the ask_user tool to confirm the roster.
- Very specific: line 55
Create the .squad/ directory structure (see .squad/templates/ for format guides or use the standard structure: team.md, routing.md, …
- Very specific: line 63
Merge driver for append-only files: Create or update .gitattributes at the repo root to enable conflict-free merging of .squad/ state …
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Context
Init Mode activates when .squad/team.md does not exist, or exists but has zero roster entries under ## Members. The coordinator proposes a team (Phase 1), waits for user confirmation, then creates the team structure (Phase 2).
Patterns
Phase 1: Propose the Team
No team exists yet. Propose one — but DO NOT create any files until the user confirms.
- Identify the user. Run
git config user.nameto learn who you're working with. Use their name in conversation (e.g., "Hey {user}, what are you building?"). Store their name (NOT email) inteam.mdunder Project Context. Never read or storegit config user.email— email addresses are PII and must not be written to committed files. - Ask: "What are you building? (language, stack, what it does)"
- Cast the team. Before proposing names, run the Casting & Persistent Naming algorithm (see that section):
- Determine team size (typically 4–5 + Scribe).
- Determine assignment shape from the user's project description.
- Derive resonance signals from the session and repo context.
- Select a universe. If the universe is custom, allocate character names from that universe based on the related list found in the
.squad/templates/casting/directory. Prefer custom universes when available. - Scribe is always "Scribe" — exempt from casting.
- Ralph is always "Ralph" — exempt from casting.
- Propose the team with their cast names. Example (names will vary per cast):
🏗️ {CastName1} — Lead Scope, decisions, code review
⚛️ {CastName2} — Frontend Dev React, UI, components
🔧 {CastName3} — Backend Dev APIs, database, services
🧪 {CastName4} — Tester Tests, quality, edge cases
📋 Scribe — (silent) Memory, decisions, session logs
🔄 Ralph — (monitor) Work queue, backlog, keep-alive- Use the
ask_usertool to confirm the roster. Provide choices so the user sees a selectable menu:- question: "Look right?"
- choices:
["Yes, cast this team", "Add someone", "Change a role"]
⚠️ STOP. Your response ENDS here. Do NOT proceed to Phase 2. Do NOT create any files or directories. Wait for the user's reply.
Phase 2: Create the Team
Trigger: The user replied to Phase 1 with confirmation ("yes", "looks good", or similar affirmative), OR the user's reply to Phase 1 is a task (treat as implicit "yes").
If the user said "add someone" or "change a role," go back to Phase 1 step 3 and re-propose. Do NOT enter Phase 2 until the user confirms.
- Create the
.squad/directory structure (see.squad/templates/for format guides or use the standard structure: team.md, routing.md, ceremonies.md, decisions.md, decisions/inbox/, casting/, agents/, orchestration-log/, skills/, log/).
Casting state initialization: Copy .squad/templates/casting-policy.json to .squad/casting/policy.json (or create from defaults). Create registry.json (entries: persistent_name, universe, created_at, legacy_named: false, status: "active") and history.json (first assignment snapshot with unique assignment_id).
Seeding: Each agent's history.md starts with the project description, tech stack, and the user's name so they have day-1 context. Agent folder names are the cast name in lowercase (e.g., .squad/agents/ripley/). The Scribe's charter includes maintaining decisions.md and cross-agent context sharing.
Team.md structure: team.md MUST contain a section titled exactly ## Members (not "## Team Roster" or other variations) containing the roster table. This header is hard-coded in GitHub workflows (squad-heartbeat.yml, squad-issue-assign.yml, squad-triage.yml, sync-squad-labels.yml) for label automation. If the header is missing or titled differently, label routing breaks.
Merge driver for append-only files: Create or update .gitattributes at the repo root to enable conflict-free merging of .squad/ state across branches:
.squad/decisions.md merge=union
.squad/agents/*/history.md merge=union
.squad/log/** merge=union
.squad/orchestration-log/** merge=unionThe union merge driver keeps all lines from both sides, which is correct for append-only files. This makes worktree-local strategy work seamlessly when branches merge — decisions, memories, and logs from all branches combine automatically.
- Say: "✅ Team cast. Try: '{FirstCastName}, set up the project structure'"
- Post-setup input sources (optional — ask after team is created, not during casting):
- PRD/spec: "Do you have a PRD or spec document? (file path, paste it, or skip)" → If provided, follow PRD Mode flow
- GitHub issues: "Is there a GitHub repo with issues I should pull from? (owner/repo, or skip)" → If provided, follow GitHub Issues Mode flow
- Human members: "Are any humans joining the team? (names and roles, or just AI for now)" → If provided, add per Human Team Members section
- Copilot agent: "Want to include @copilot? It can pick up issues autonomously. (yes/no)" → If yes, follow Copilot Coding Agent Member section and ask about auto-assignment
- These are additive. Don't block — if the user skips or gives a task instead, proceed immediately.
Examples
Example flow:
- Coordinator detects no team.md → Init Mode
- Runs
git config user.name→ "{user}" - Asks: "Hey {user}, what are you building?"
- User: "TypeScript CLI tool with GitHub API integration"
- Coordinator runs casting algorithm → selects "The Usual Suspects" universe
- Proposes: Agent Alpha (Lead), Agent Beta (Prompt), Agent Gamma (Backend), Agent Delta (Tester), Scribe, Ralph
- Uses
ask_userwith choices → user selects "Yes, cast this team" - Coordinator creates
.squad/structure, initializes casting state, seeds agents - Says: "✅ Team cast. Try: 'Agent Alpha, set up the project structure'"
Anti-Patterns
- ❌ Creating files before user confirms Phase 1
- ❌ Mixing agents from different universes in the same cast
- ❌ Skipping the
ask_usertool and assuming confirmation - ❌ Proceeding to Phase 2 when user said "add someone" or "change a role"
- ❌ Using
## Team Rosterinstead of## Membersas the header (breaks GitHub workflows) - ❌ Forgetting to initialize
.squad/casting/state files - ❌ Reading or storing
git config user.email(PII violation)
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

