init-mode

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.

1. Identify the user. Run 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.
2. Ask: "What are you building? (language, stack, what it does)"
3. 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.
4. 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

1. Use the ask_user tool 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"]