Standard collaboration patterns for all squad agents — worktree awareness, decisions, cross-agent communication
日本語の概要は準備中です。原文の説明を表示しています。
The complete two-phase Init Mode protocol the Squad coordinator runs when no team exists yet in the current repo. Phase 1 = propose the team (no files created, wait for user confirm). Phase 2 = create .squad/ scaffolding, casting state, .gitattributes for merge drivers, and the always-on built-ins (Scribe, Ralph, Rai, Fact Checker). Loaded on demand when the coordinator detects no .squad/team.md exists.
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
Load this skill when: you detect that no
.squad/team.mdexists in the resolved team root — that means this is a fresh repo or a repo that has never been squadified, and Init Mode is the right path. The short stub insquad.agent.mdtells you to load this skill; the full two-phase protocol lives here.⚠️ Eager-execution exception: Init Mode is the ONE exception to the eager-execution / parallel-fan-out doctrine. Phase 1 MUST end with a user confirmation before any file is created. Do not bypass.
No team exists yet. Propose one — but DO NOT create any files until the user confirms.
git config user.name to learn who you're working with. Use their name in conversation (e.g., "Hey {user}, what are you building?"). Store their name (NOT email) in team.md under Project Context. Never read or store git config user.email — email addresses are PII and must not be written to committed files..squad/templates/casting-reference.md):
squad.agent.md). A typical fresh squad has 8–9 total roster entries, not 4–5.🏗️ {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
🛡️ Rai — (background) RAI awareness, content safety
🔍 Fact Checker — (verifier) Verification + Devil's Advocate
Use the ask_user tool to confirm the roster. Provide choices so the user sees a selectable menu.
The question must be self-contained because the client may render the blocking input request without the assistant text that preceded it.
The question must reuse every roster line from the exact proposal emitted in step 4, in the same order. Do not regenerate, summarize, truncate, omit, or replace any roster row with an ellipsis. Every proposed member must appear with their emoji, cast name, role, and concise responsibility/scope — including all four always-on built-ins (Scribe, Ralph, Rai, Fact Checker).
Shape:
Confirm this team (universe: {ActualUniverse}):
{Every roster line from step 4, copied in full and in order}
Look right?
Never use a bare "Look right?" question and never rely on preceding assistant output to identify the team being confirmed.
["Yes, hire 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.
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.
.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/, rai/).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. Rai's charter is seeded from the Rai-charter.md template, and .squad/rai/policy.md is seeded from rai-policy.md. Fact Checker's charter is seeded from fact-checker-charter.md and .squad/fact-checker/policy.md is seeded from fact-checker-policy.md.
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=union
.squad/rai/audit-trail.md merge=union
The 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 hired. Try: '{FirstCastName}, set up the project structure'"
Post-setup input sources (optional — ask after team is created, not during casting):
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Standard collaboration patterns for all squad agents — worktree awareness, decisions, cross-agent communication
日本語の概要は準備中です。原文の説明を表示しています。
Shared hard rules enforced across all squad agents
日本語の概要は準備中です。原文の説明を表示しています。
Route gh-aw design, creation, diagnosis, patching, active debugging, and upgrade requests to the right strategies.
日本語の概要は準備中です。原文の説明を表示しています。
How to write comprehensive architectural proposals that drive alignment before code is written
日本語の概要は準備中です。原文の説明を表示しています。
Upgrade gh-aw to latest gh-aw-firewall release and identify follow-up spec tasks.
日本語の概要は準備中です。原文の説明を表示しています。
Review code that performs git or gh operations against repository checkouts in gh-aw, checking that the right credentials are available at the right time and that sparseness, shallowness and credential-free factors are properly considered.
日本語の概要は準備中です。原文の説明を表示しています。