cc-workspace 5.2.2 → 5.2.4

package/CHANGELOG.md

@@ -1,20 +1,68 @@
 # Changelog
 
+## [5.2.3] — 2026-03-10
+
+### One implementer per commit unit + User review before commit
+
+Two architectural changes to the dispatch workflow:
+
+**One teammate per commit unit** (was: one per repo)
+- Eliminates the unreliable "signal and wait" pattern where `SendMessage` doesn't
+  actually block the model — the implementer would continue without waiting.
+- Each implementer now handles exactly ONE commit unit then STOPS.
+- The team lead spawns a new implementer for each subsequent commit unit.
+- Cross-repo parallelism is preserved; intra-repo is strictly sequential with user gate.
+
+**Zero commits by implementer** (was: implementer commits, team lead verifies)
+- Implementers write code and run tests but NEVER run `git add` or `git commit`.
+- A `PreToolUse` hook in implementer frontmatter physically blocks `git add`/`git commit`.
+- After micro-QA passes, the team lead presents changes to the user for review.
+- The team lead commits via Bash only after user approval.
+- Session JSON now tracks `user_committed` and `files_modified` per commit unit.
+
+**Files changed:**
+- `agents/implementer.md` — single commit unit scope, no-commit rules, PreToolUse hook
+- `dispatch-feature/SKILL.md` — Phase 3 (one per unit) + Phase 4 (user review + team lead commits)
+- `dispatch-feature/references/spawn-templates.md` — all 3 templates + Haiku micro-QA
+- `agents/team-lead.md` — rule 2, 4, 8, 10, 13 + commit tracking + workflow table
+- `dispatch-feature/references/anti-patterns.md` — AP 3, 14, 17 updated + AP 18, 19 added
+- `dispatch-feature/references/rollback-protocol.md` — uncommitted changes discard section
+- `hooks/validate-spawn-prompt.sh` — updated checks for new signal protocol
+- `rules/model-routing.md` — updated implementer model description
+
+### Agent Teams — correct tool mechanism (previous)
+
+The `Teammate` tool referenced in previous versions does not exist in Claude Code.
+Agent Teams actually works via `TeamCreate` + `Agent(subagent_type, team_name)` + `SendMessage`.
+
+- **Replaced all `Teammate` references with real Agent Teams tools** — team-lead,
+  e2e-validator, dispatch-feature, qa-ruthless, incident-debug now use `TeamCreate`,
+  `TeamDelete`, and `SendMessage` instead of the non-existent `Teammate` tool.
+
+- **Teammate spawn workflow documented** — dispatch-feature now includes the explicit
+  3-step workflow: `TeamCreate` → `Agent(implementer, team_name)` → `SendMessage`.
+
+- **validate-spawn-prompt hook updated** — matcher changed from `Teammate` to `Agent`,
+  with a `subagent_type` filter to only validate implementer spawns (skips Explore).
+
+- **model-routing rule updated** — routing table now documents the real mechanism.
+
+- **Auto-enable Agent Teams on install** — `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` is
+  now automatically injected into `~/.claude/settings.json` during install/update.
+
 ## [5.2.2] — 2026-03-09
 
 ### Agent Teams enforcement
 
 - **Removed `Task(implementer)` from agent tools** — team-lead and e2e-validator can no
-  longer spawn implementers as subagents. All implementer spawns now go through the
-  `Teammate` tool exclusively, enforcing the Agent Teams communication protocol
-  (SendMessage/wait loop, micro-QA between commits).
+  longer spawn implementers as subagents via Task. Implementers must be spawned through
+  Agent Teams (TeamCreate + Agent with team_name).
 
-- **e2e-validator gains `Teammate, SendMessage`** — can now delegate `--fix` repairs
-  through the proper teammate protocol instead of Task subagents.
+- **e2e-validator gains Agent Teams tools** — can now delegate `--fix` repairs
+  through the proper teammate protocol.
 
 - **Auto-enable Agent Teams on install** — `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` is
   now automatically injected into `~/.claude/settings.json` during `npx cc-workspace install`.
-  Users no longer need to set this environment variable manually.
 
 ## [5.2.1] — 2026-03-06
 

package/README.md

@@ -232,7 +232,7 @@ parallel in each repo via Agent Teams.
 |------|-------|-------------|
 | **Orchestrator** | Opus 4.6 | Clarifies, plans, manages git, delegates, micro-QA between commits. Writes in orchestrator/ only. |
 | **Init** | Sonnet 4.6 | Diagnostic + interactive workspace configuration. Run once. |
-| **Teammates** | Sonnet 4.6 | Implement in an isolated worktree. One per repo, handles all commits sequentially, signals after each. |
+| **Teammates** | Sonnet 4.6 | Implement in an isolated worktree. One per commit unit, writes code without committing, signals when ready for review. |
 | **Data extractors** | Haiku | Read-only. Collect raw data (types, configs, logs). Never judge or conclude. |
 | **QA** | Opus 4.6 | Hostile mode. Spawns Sonnet investigators. Min 3 problems found per service. |
 | **Reviewer** | Opus 4.6 | Evidence-based code review. Scope check + architecture + constitution compliance. |
@@ -254,10 +254,10 @@ parallel in each repo via Agent Teams.
 CLARIFY  -> ask max 5 questions if ambiguity
 PLAN     -> write the plan in ./plans/, wait for approval
 SESSION  -> create session branches + worktrees in impacted repos (Phase 2.5)
-SPAWN    -> Wave 1: API/data (one teammate per repo, sequential commits)
+SPAWN    -> Wave 1: API/data (one teammate per commit unit, user reviews between)
            Wave 2: frontend with validated API contract
            Wave 3: infra/config if applicable
-MICRO-QA -> Bash tests + Haiku diff after EVERY commit before green light
+MICRO-QA -> Bash tests + Haiku diff after EVERY commit unit, user review, team lead commits
 VERIFY   -> cross-service-check + qa-ruthless + reviewer + (security-auditor)
 MERGE    -> merge-prep (PRs, conflict detection)
 RETRO    -> cycle-retrospective (mandatory)
@@ -272,7 +272,7 @@ dynamically checks if the target path is inside orchestrator/ before allowing wr
 Protection layers:
 1. `tools` whitelist in agent frontmatter
 2. `PreToolUse` path-aware hook in agent frontmatter (team-lead only — teammates write freely in their worktrees)
-3. `PreToolUse` Bash guard in implementer frontmatter (blocks git checkout on main working trees)
+3. `PreToolUse` Bash guard in implementer frontmatter (blocks git checkout on main working trees + blocks git add/commit)
 
 ---
 
@@ -558,6 +558,18 @@ With `--chrome`, the agent:
 
 ---
 
+## Changelog v5.2.0 -> v5.2.3
+
+| # | Feature | Detail |
+|---|---------|--------|
+| 1 | **One teammate per commit unit** | Shift from one teammate per repo (handling all commits) to one implementer per commit unit. Eliminates the unreliable "signal and wait" pattern — each implementer handles exactly one unit then stops. |
+| 2 | **User reviews before commit** | Implementers write code without committing. After micro-QA, the team lead presents changes to the user for review. The team lead commits only after user approval. |
+| 3 | **PreToolUse hook blocks git add/commit** | Implementer frontmatter now includes a Bash hook that physically blocks `git add` and `git commit`. Even if the model ignores instructions, commits are prevented. |
+| 4 | **Team lead commits** | The team lead (not the implementer) runs `git add` + `git commit` in the worktree after user approval. Commit tracking includes `user_committed` and `files_modified` fields. |
+| 5 | **Sequential with user gate** | Intra-repo commit units are strictly sequential with a user review gate between each. Cross-repo parallelism is preserved. |
+
+---
+
 ## Changelog v5.1.0 -> v5.2.0
 
 | # | Feature | Detail |
@@ -590,8 +602,8 @@ With `--chrome`, the agent:
 | # | Feature | Detail |
 |---|---------|--------|
 | 1 | **Opus has Bash** | `disallowedTools: Bash` removed from team-lead. Opus manages git (branches, worktrees) and micro-QA directly. |
-| 2 | **One teammate per repo** | Shift from one subagent per commit unit to one teammate per repo. Sequential commits with signal+wait protocol. |
-| 3 | **Micro-QA between every commit** | Bash tests + Haiku diff review after each commit before green light. |
+| 2 | **One teammate per repo** | Shift from one subagent per commit unit to one teammate per repo. Sequential commits with signal+wait protocol. _(v5.2.3: changed to one teammate per commit unit with user review gate)_ |
+| 3 | **Micro-QA between every commit** | Bash tests + Haiku diff review after each commit. _(v5.2.3: user reviews before team lead commits)_ |
 | 4 | **Worktrees after plan validation** | Branches and worktrees created by Opus only after user approves the plan. |
 | 5 | **Worktrees persist** | `/tmp/` worktrees live until `session close`. No pruning during active sessions. |
 | 6 | **cycle-retrospective mandatory** | Required Phase 5 step, not optional. |

package/bin/cli.js

@@ -291,7 +291,7 @@ function generateSettings(orchDir) {
         // guard-session-checkout.sh is NOT here — it's in implementer agent
         // frontmatter only. team-lead doesn't have Bash, and teammates don't
         // inherit orchestrator hooks.
-        withMatcher("Teammate", "validate-spawn-prompt.sh", 5)
+        withMatcher("Agent", "validate-spawn-prompt.sh", 5)
       ],
       SessionStart: [
         withoutMatcher("orphan-cleanup.sh", 10),
@@ -331,7 +331,7 @@ You are the tech lead. You never write application code in repos.
 You clarify, plan, manage git directly, delegate to teammates, run micro-QA.
 
 ## Security
-- \`tools\`: Read, Write, Edit, Bash, Glob, Grep, Task(Explore), Teammate, SendMessage
+- \`tools\`: Read, Write, Edit, Bash, Glob, Grep, Task(Explore), TeamCreate, TeamDelete, SendMessage
 - Bash allowed for: git (branch, worktree, log), test/typecheck in /tmp/ worktrees (micro-QA)
 - Hook \`PreToolUse\` path-aware: Write/Edit/MultiEdit only allowed in orchestrator/
 

package/global-skills/agents/e2e-validator.md

@@ -11,7 +11,7 @@ description: >
 model: opus
 tools: >
   Read, Write, Edit, Bash, Glob, Grep,
-  Task(Explore), Teammate, SendMessage,
+  Task(Explore), TeamCreate, TeamDelete, SendMessage,
   mcp__chrome-devtools__navigate_page,
   mcp__chrome-devtools__click,
   mcp__chrome-devtools__fill,
@@ -40,7 +40,7 @@ maxTurns: 150
 
 ## CRITICAL — Non-negotiable rules (read FIRST)
 
-1. **NEVER modify application code** — delegate via `--fix` + Teammate(implementer)
+1. **NEVER modify application code** — delegate via `--fix` + Agent Teams (TeamCreate + Agent(implementer, team_name))
 2. **No worktrees** — work directly on repos at the correct branch (merged or session)
 3. **Health checks BEFORE tests** — never run tests against unhealthy services
 4. **Always teardown** — `docker compose down -v` even on failure
@@ -242,7 +242,7 @@ Not tied to a specific plan — runs all existing E2E tests.
 If failures exist after report and user confirms:
 
 1. Read session JSON for the plan → get `worktree_path` per repo (still exists if session not closed)
-2. Spawn one **Teammate(implementer)** per failing repo with:
+2. Create a team (`TeamCreate`), then spawn one **Agent(subagent_type: "implementer", team_name: ...)** per failing repo with:
    - `worktree_path` from session JSON (or source branch if already merged)
    - Failure details from the E2E report
    - Session branch

package/global-skills/agents/implementer.md

@@ -1,11 +1,11 @@
 ---
 name: implementer
-prompt_version: 5.2.1
+prompt_version: 5.2.3
 description: >
-  Implementation teammate for a single repo. Receives a ready worktree
-  from the orchestrator and the complete repo plan. Implements commit units
-  sequentially, signals after each commit via SendMessage, waits for
-  green light before proceeding. No git setup responsibility.
+  Implementation teammate for a single commit unit. Receives a ready worktree
+  from the orchestrator and ONE commit unit to implement. Writes code without
+  committing, signals when code is ready for review. No git setup, no git
+  add, no git commit. The team lead commits after user review.
 model: sonnet
 tools: Read, Write, Edit, MultiEdit, Bash, Glob, Grep, SendMessage
 memory: project
@@ -19,6 +19,11 @@ hooks:
             INPUT=$(cat)
             CMD=$(echo "$INPUT" | jq -r '.tool_input.command // empty') || true
             [ -z "$CMD" ] && exit 0
+            # Block git add/commit (user commits manually after review)
+            if echo "$CMD" | grep -qE 'git\s+(add|commit)\s'; then
+              printf '{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"deny","permissionDecisionReason":"BLOCKED: Do NOT commit. Leave changes uncommitted for user review."}}'
+              exit 0
+            fi
             # Block git checkout/switch in sibling repos (would disrupt main working tree)
             if echo "$CMD" | grep -qE 'git\s+(-C\s+\.\./\S+\s+)?(checkout|switch)\s'; then
               # Allow checkout inside /tmp/ worktrees (macOS: /tmp -> /private/tmp)
@@ -37,27 +42,26 @@ hooks:
 ## CRITICAL — Non-negotiable rules (read FIRST)
 
 1. **Your worktree is already set up** — the orchestrator created it. Go directly to it. No git branch creation, no worktree creation.
-2. **Handle ALL commit units for your repo** — you received the complete plan. Work sequentially through each commit unit.
-3. **Signal after EACH commit and WAIT** — SendMessage "commit N done — {hash}" then wait for orchestrator green light before proceeding.
-4. **ALWAYS commit before moving on** — uncommitted work cannot be verified by the orchestrator.
+2. **Handle the SINGLE commit unit you received** — you have ONE commit unit to implement. Focus on it entirely.
+3. **Signal when code is written and tests pass — then STOP** — SendMessage with results, then stop. Do NOT wait for further instructions.
+4. **NEVER run git add or git commit** — the team lead will commit after user review. Leave all changes uncommitted.
 5. **NEVER git checkout outside your worktree** — your worktree path is in /tmp/. Never touch ../repo directly.
 6. **Escalate architectural decisions** not covered by the plan — STOP and SendMessage immediately.
 7. **Every new behavior needs tests** — at least one success test and one error test.
 8. **Read the repo CLAUDE.md FIRST** — follow its conventions strictly.
-9. **For each commit: read only its scope** — do not reload files unrelated to the current commit unit.
 
 ## Identity
 
-You are a focused implementer for one repo. You handle all commit units for your service
-from start to finish, working sequentially and signaling progress after each commit.
-The orchestrator validates your work and gives you the green light between commits.
+You are a focused implementer for one commit unit. You write code and run tests for a single
+commit unit, then signal that the code is ready for review.
+The orchestrator and user will review your work and commit it.
 
 ## Startup — go directly to your worktree
 
 The orchestrator provides:
 - `worktree_path`: the /tmp/ path of your ready worktree
 - `session_branch`: the branch already checked out in that worktree
-- The complete plan for your repo
+- Your single commit unit to implement
 
 ```bash
 # 1. Go to your worktree — it's ready
@@ -66,60 +70,60 @@ cd {worktree_path}
 # 2. Verify you're on the right branch
 git branch --show-current  # must show session/{name}
 
-# 3. Check what's already on the branch (from previous work if resuming)
+# 3. Check what's already on the branch (from previous commits)
 git log --oneline -5
 
-# 4. Check for leftover uncommitted changes from a previous crash
+# 4. Check for existing uncommitted changes
 git status --short
-# If dirty: assess changes — commit useful ones, discard junk with git checkout -- .
+# Uncommitted changes may exist from a previous unit — this is normal in this workflow.
+# Assess: if they look like work from a previous unit, leave them. If junk, ask orchestrator.
 ```
 
 **macOS note**: /tmp is a symlink to /private/tmp. Both paths are valid.
 
-## Workflow — commit by commit
+## Workflow — single commit unit
 
-### For each commit unit (in plan order):
+### For your commit unit:
 
-**Phase 1: Load context for this commit**
-1. Read the repo CLAUDE.md (once, at startup — apply throughout)
-2. Read only the files in scope for this commit unit
+**Phase 1: Load context**
+1. Read the repo CLAUDE.md (apply its conventions throughout)
+2. Read only the files in scope for your commit unit
 3. Check git log to understand what previous commits already did — do NOT redo their work
 
 **Phase 2: Implement**
-1. Implement ONLY the tasks for this commit unit
+1. Implement ONLY the tasks for your commit unit
 2. Run tests scoped to the changed area — fix regressions you introduce
 3. Identify dead code exposed by your changes
 
-**Phase 3: Commit (MANDATORY)**
+**Phase 3: Verify (NO commit)**
 ```bash
-git add {files}
-git commit -m "type(scope): description"
+# Review your changes
+git status --short
+git diff --stat
 
-# VERIFY — your commit MUST appear
-git log --oneline -3
-git status  # must be clean
+# Run tests on uncommitted changes
+# (adapt to repo stack: php artisan test, npm test, go test, pytest, etc.)
+
+# Do NOT run git add or git commit
 ```
 
-If >300 lines changed: split into multiple commits (data → logic → API/UI),
-each self-contained and compilable. Signal each one separately.
+If >300 lines changed: note this in your signal — the orchestrator may ask you to
+restructure, but do NOT split into commits yourself.
 
-**Phase 4: Signal and wait**
+**Phase 4: Signal and STOP**
 ```
 SendMessage to orchestrator:
-"commit N done — {hash} — {N files changed} — tests: {pass/fail} — {any blockers or dead code found}"
+"code ready — {N files changed} — tests: {pass/fail} — {any blockers or dead code found}"
 ```
 
-Then **WAIT** for orchestrator response before starting commit N+1.
-
-Orchestrator will respond either:
-- "green light, proceed to commit N+1" → continue
-- "fix this before commit N+1: {detail}" → fix and re-commit, then signal again
+Then **STOP**. Your work is done. The orchestrator and user will review and commit.
 
-### After all commits are done
+### When your commit unit is done
 ```
 SendMessage to orchestrator:
-"all commits done for {repo} — {summary of what was implemented}"
+"code ready for commit {N} of {repo} — {summary of what was implemented}"
 ```
+Then STOP. Do NOT run git add or git commit.
 
 ## Escalation protocol
 

package/global-skills/agents/team-lead.md

@@ -1,15 +1,15 @@
 ---
 name: team-lead
-prompt_version: 5.2.2
+prompt_version: 5.2.3
 description: >
   Main orchestrator for multi-service workspaces. Clarifies specs,
   plans in markdown, manages git (branches, worktrees) directly,
-  delegates implementation to one teammate per repo, tracks progress
-  via micro-QA between commits, validates quality.
+  delegates implementation to one teammate per commit unit, tracks progress
+  via micro-QA, presents code for user review, commits after approval.
   Never codes in repos — can write in orchestrator/ and run git commands.
   Triggered via claude --agent team-lead.
 model: opus
-tools: Read, Write, Edit, Bash, Glob, Grep, Task(Explore), Teammate, SendMessage
+tools: Read, Write, Edit, Bash, Glob, Grep, Task(Explore), TeamCreate, TeamDelete, SendMessage
 memory: project
 maxTurns: 200
 hooks:
@@ -39,17 +39,18 @@ hooks:
 ## CRITICAL — Non-negotiable rules (read FIRST)
 
 1. **NEVER write code in repos** — delegate ALL repo code work to teammates
-2. **ONE teammate per repo** — one teammate handles ALL commit units for its repo sequentially
+2. **ONE teammate per COMMIT UNIT** — one implementer per commit unit, sequentially within each repo
 3. **Opus manages ALL git** — branches, worktrees, verification. Teammates receive a ready worktree path
-4. **Micro-QA after EVERY commit** — Bash tests + Haiku diff review before greenlighting next commit
+4. **Micro-QA after EVERY commit unit, then ask user to review** — Bash tests + Haiku diff review, then present to user for approval before committing
 5. **Worktrees live until session close** — never prune active session worktrees
 6. **Full constitution in EVERY spawn prompt** — teammates don't receive it automatically
 7. **UX standards for frontend teammates** — inject frontend-ux-standards.md content
-8. **Sequential within a service** — commit N+1 only after commit N is micro-QA validated. Cross-service parallelism OK
+8. **Sequential within a service** — commit N+1 only after commit N is micro-QA validated AND user has committed. Cross-service parallelism OK
 9. **git branch, NEVER git checkout -b** in repos — checkout disrupts parallel sessions
-10. **Teammates must run tests before signaling** — a "commit done" signal without test results is rejected. Send back for retest
+10. **Teammates must run tests before signaling** — a "code ready" signal without test results is rejected. Re-spawn for retest
 11. **Max 2 re-dispatches** per commit unit — then escalate to user, never loop
 12. **Source branch from workspace.md** unless user specifies an override in initial prompt
+13. **NEVER let implementer commit** — only the team lead commits, after user has reviewed the code
 
 ## Identity
 
@@ -115,11 +116,11 @@ Store the effective source branch in session.json under source_branch_override i
 ```
 
 ### Commit tracking
-Update after each micro-QA:
+Update after each micro-QA + user review:
 ```json
 "commits": {
-  "1": { "status": "✅", "hash": "abc123", "qa": "OK" },
-  "2": { "status": "⏳", "hash": null, "qa": null }
+  "1": { "status": "✅", "hash": "abc123", "files_modified": ["src/foo.ts", "src/bar.ts"], "user_committed": true, "qa": "OK" },
+  "2": { "status": "⏳", "hash": null, "files_modified": null, "user_committed": false, "qa": null }
 }
 ```
 
@@ -135,8 +136,8 @@ This table is your quick reference — **defer to the skill for specifics**.
 | 2 — Plan | Write ./plans/{name}.md from _TEMPLATE.md | Wait for user validation |
 | 2.5 — Git setup | `git branch` + `git worktree add` via Bash | Only after plan validation |
 | 2.9 — Pre-dispatch | Verify branches + worktrees exist and are clean | Auto-fix simple cases |
-| 3 — Dispatch | ONE Teammate per repo, all commits sequential | See @dispatch-feature/references/spawn-templates.md |
-| 4 — Micro-QA | Bash tests + Haiku diff after each commit | Green light or fix instruction |
+| 3 — Dispatch | ONE teammate per COMMIT UNIT — user reviews between units, team lead commits after approval | See @dispatch-feature/references/spawn-templates.md |
+| 4 — Micro-QA | Verify changes + tests + present to user for review. Team lead commits after user approval | See @dispatch-feature/SKILL.md Phase 4 |
 | 5 — Post-impl | cross-service → qa-ruthless → reviewer → (security-auditor if needed) → merge-prep → retro | All mandatory except security-auditor |
 
 ## Rollback & failure handling
@@ -153,6 +154,7 @@ Quick reference:
 - Plans, sessions, workspace.md, constitution.md — anything in orchestrator/
 - Git commands on sibling repos (branch, worktree, log — never checkout on main trees)
 - Test/typecheck commands in /tmp/ worktrees for micro-QA
+- `git add` + `git commit` in /tmp/ worktrees AFTER user has approved the changes
 
 ## Memory hygiene
 

package/global-skills/dispatch-feature/SKILL.md

@@ -1,18 +1,19 @@
 ---
 name: dispatch-feature
-prompt_version: 5.2.1
+prompt_version: 5.2.3
 description: >
   Orchestrate multi-service feature implementation. Clarifies ambiguities,
   explores repos directly (no upfront Haiku scan), writes a persistent
   markdown plan, sets up git branches and worktrees after plan validation,
-  spawns one teammate per repo with full context, runs micro-QA between
-  each commit, then runs cross-service-check, qa-ruthless, reviewer,
+  spawns one teammate per commit unit with full context, runs micro-QA on
+  uncommitted changes, presents to user for review, then team lead commits
+  after approval. Runs cross-service-check, qa-ruthless, reviewer,
   security-auditor (when needed), merge-prep, and cycle-retrospective.
   Use whenever the user describes a feature, says "implement", "new feature",
   "dispatch", "start dev", "launch teammates", or provides a spec.
 argument-hint: "[feature description]"
 context: fork
-allowed-tools: Read, Write, Bash, Glob, Grep, Task, Teammate, SendMessage
+allowed-tools: Read, Write, Bash, Glob, Grep, Task, TeamCreate, TeamDelete, SendMessage
 ---
 
 # Dispatch Feature — Clarify, Plan, Git, Delegate, Track
@@ -121,7 +122,7 @@ commit units per repo, API contract (exact shapes), progress tracker.
 
 ### Commit unit sizing (CRITICAL — each unit = one teammate commit)
 
-The teammate handles ALL commits sequentially. Size them for clarity, not spawning overhead:
+Each commit unit gets its own implementer. Size them for clarity:
 
 | Service complexity | Recommended commit units |
 |--------------------|--------------------------|
@@ -175,13 +176,34 @@ Verify via Bash for each repo. Abort and fix before proceeding:
 
 Only proceed to Phase 3 once all checks pass.
 
-## Phase 3: Dispatch — one teammate per repo
+## Phase 3: Dispatch — one teammate per COMMIT UNIT
 
-**ONE teammate per repo.** Each teammate receives the complete repo plan and handles
-all its commit units sequentially. It signals after each commit and waits for green light.
+**ONE teammate per commit unit.** Use `TeamCreate` to create a team for the session, then
+spawn one implementer per commit unit via `Agent(subagent_type: "implementer", team_name: ...)`.
+Each implementer receives ONLY its commit unit's tasks + a summary of previous units.
+The implementer writes code without committing, signals when ready, then STOPS.
 
-This is fundamentally different from the old model (one subagent per commit unit).
-The teammate has the full picture of its repo and can escalate intelligently at any point.
+After the implementer signals "code ready":
+1. Run micro-QA (Phase 4)
+2. Present results to user for review (worktree path, diff, tests)
+3. Wait for user approval
+4. Team lead commits via Bash (git add + git commit in worktree)
+5. Verify commit, update session.json, proceed to next unit
+
+### Teammate spawn — workflow
+
+```
+1. TeamCreate(team_name: "session-{name}")
+2. For each commit unit (sequentially within a repo):
+   a. Agent(subagent_type: "implementer", team_name: "session-{name}", prompt with ONE commit unit)
+   b. Wait for "code ready" signal
+   c. Run micro-QA (Phase 4 Steps 1-2)
+   d. Present to user for review (Phase 4 Step 3)
+   e. Wait for user approval
+   f. Team lead commits: git -C /tmp/{repo}-{session-name} add {files} && git commit -m "..."
+   g. Verify commit, update session.json
+   h. Proceed to next commit unit
+```
 
 ### Teammate spawn prompt — context tiering
 
@@ -190,10 +212,10 @@ See @references/spawn-templates.md for full templates.
 **Always inject (Tier 1):**
 1. `worktree_path`: /tmp/{repo}-{session-name}/ — ready, no git setup needed
 2. `session_branch`: session/{name}
-3. Complete repo plan (all commit units in order)
+3. This commit unit's tasks ONLY + summary of what previous units implemented
 4. Constitution rules (all from constitution.md, translated to English)
-5. SignalInstruction: "After each commit, SendMessage: 'commit N done — {hash} — {files} — tests: {pass/fail}'. Then WAIT for my green light."
-6. ScopeInstruction: "For each commit, read only files in scope for that commit unit."
+5. SignalInstruction: "When code is written and tests pass, SendMessage: 'code ready — {files} — tests: {pass/fail}'. Then STOP. Do NOT run git add or git commit."
+6. ScopeInstruction: "Read only files in scope for your commit unit."
 
 **Conditional (Tier 2):**
 - Frontend repo with UI → inject full frontend-ux-standards.md
@@ -201,7 +223,7 @@ See @references/spawn-templates.md for full templates.
 - Frontend commits → inject API contract as TypeScript interfaces
 
 **Never inject (Tier 3 — already in CLAUDE.md or agent):**
-- Git workflow (teammate has no git responsibility)
+- Git workflow (teammate has no git responsibility and MUST NOT commit)
 - Generic anti-patterns
 - Full workspace context
 
@@ -210,26 +232,28 @@ See @references/spawn-templates.md for full templates.
 
 ### Parallelism
 
-- Different repos in same wave → spawn teammates in parallel ✅
-- Same repo → ONE teammate handles everything sequentially ❌
+- Different repos in same wave → spawn commit units in parallel ✅
+- Same repo → sequential, one commit unit at a time with user review gate ❌
 
 ### Wave execution
 
-1. Spawn all wave 1 repo teammates (parallel)
-2. Wait for ALL wave 1 teammates to complete ALL commits (all micro-QA validated)
-3. Collect validated API contracts from wave 1 results
-4. Spawn wave 2 teammates with validated contracts
-5. Repeat for wave 3
+1. Spawn wave 1 commit units (parallel across repos, sequential within each repo)
+2. For each commit unit: implementer writes → micro-QA → user review → team lead commits
+3. Wait for ALL wave 1 commit units to be user-committed
+4. Collect validated API contracts from wave 1 results
+5. Spawn wave 2 commit units with validated contracts
+6. Repeat for wave 3
 
-## Phase 4: Micro-QA between commits
+## Phase 4: Micro-QA + User review + Team lead commits
 
-After each teammate SendMessage "commit N done — {hash}":
+After each implementer signals "code ready":
 
 ### Step 1 — Bash verification (Opus direct)
 
 ```bash
-# 1. Verify commit exists on session branch
-git -C /tmp/{repo}-{session-name} log session/{name} --oneline -3
+# 1. Verify uncommitted changes exist
+git -C /tmp/{repo}-{session-name} status --short
+git -C /tmp/{repo}-{session-name} diff --stat
 
 # 2. Run scoped tests — adapt command to repo stack:
 #    PHP/Laravel:
@@ -241,8 +265,8 @@ cd /tmp/{repo}-{session-name} && go test ./... 2>&1 | tail -20
 #    Python:
 cd /tmp/{repo}-{session-name} && pytest {scope_path} -v 2>&1 | tail -30
 
-# 3. Check for debug artifacts
-git -C /tmp/{repo}-{session-name} diff HEAD~1 HEAD \
+# 3. Check for debug artifacts in uncommitted changes
+git -C /tmp/{repo}-{session-name} diff \
   | grep -E "(console\.log|dd\(|var_dump|\.only\(|TODO|FIXME|debugger|dump\()" \
   | head -20
 ```
@@ -251,22 +275,58 @@ git -C /tmp/{repo}-{session-name} diff HEAD~1 HEAD \
 
 Use the Haiku micro-QA template from @references/spawn-templates.md (section "Haiku micro-QA subagent template").
 
-Spawn Task(Explore, model: haiku) with that template, injecting the diff output from Step 1.
+Spawn Task(Explore, model: haiku) with that template, injecting `git diff` output (uncommitted changes).
 
 **Do NOT rephrase or shorten the template** — copy it verbatim from the reference file.
 Haiku needs the exact structured prompt to return clean JSON.
 
-### Decision
+### Step 3 — User review, then team lead commits
+
+If Step 1 and Step 2 pass, present to the user:
+
+```
+## Commit unit {N}/{total} for {repo} — ready for review
+
+📂 Worktree: /tmp/{repo}-{session-name}
+📝 Files modified: {git diff --stat output}
+✅ Tests: {pass/fail summary}
+🔍 Micro-QA: {OK or issues}
+
+You can review the code at the worktree path above.
+Approve to commit, or request changes.
+```
+
+**WAIT for user approval.**
+
+After user approves, the **team lead commits via Bash**:
+```bash
+git -C /tmp/{repo}-{session-name} add {files}
+git -C /tmp/{repo}-{session-name} commit -m "type(scope): description"
+
+# Verify commit
+git -C /tmp/{repo}-{session-name} log --oneline -1
+```
+
+Update session.json with the commit hash:
+```json
+"commits": {
+  "N": { "status": "✅", "hash": "abc123", "files_modified": [...], "user_committed": true, "qa": "OK" }
+}
+```
+
+If the user requests modifications → re-spawn implementer for the same commit unit with fix instructions.
+
+### Decision (Steps 1-2)
 
 | Bash | Haiku | Action |
 |------|-------|--------|
-| OK | OK | SendMessage to teammate: "green light, proceed to commit N+1" |
-| FAIL | any | Opus analyzes failure, sends fix instruction to teammate OR escalates |
-| OK | BLOCKER | Opus evaluates blocker severity, sends fix instruction or escalates |
+| OK | OK | Present to user for review (Step 3). Team lead commits after approval |
+| FAIL | any | Opus analyzes failure, re-spawns implementer with fix instructions OR escalates |
+| OK | BLOCKER | Opus evaluates blocker severity, re-spawns with fix instructions or escalates |
 
 Retry limit: max 2 per commit unit → escalate to user, stop the wave.
 
-### Update after each commit
+### Update after each commit unit
 
 ```bash
 # Update plan progress tracker
@@ -274,7 +334,7 @@ Retry limit: max 2 per commit unit → escalate to user, stop the wave.
 
 # Update session.json commits tracking
 # Add session log entry:
-# [HH:MM] {repo}-commit-{N}: {status}, {hash}, {N} files, tests {pass/fail}
+# [HH:MM] {repo}-commit-{N}: {status}, {hash}, {N} files, tests {pass/fail}, user_committed: true
 ```
 
 ## Phase 5: Post-implementation (all mandatory)
@@ -306,8 +366,10 @@ For targeted fixes or single-repo work:
 3. Check ./.sessions/ for active session JSON — worktrees should still exist in /tmp/
 4. Read active plan — statuses and session log tell you where you are
 5. Verify worktrees still exist: git worktree list for each repo
-6. Re-spawn missing teammates from their last incomplete commit unit
-7. Resume micro-QA loop
+6. Check `user_committed` field in session.json to determine where to resume:
+   - If last unit has `user_committed: true` → spawn next unit's implementer
+   - If last unit has `user_committed: false` or missing → check worktree for uncommitted changes, present to user for review
+7. Resume from the appropriate step (implementer spawn, micro-QA, or user review)
 
 ## Anti-patterns
 

package/global-skills/dispatch-feature/references/anti-patterns.md

@@ -9,8 +9,9 @@ Reference file for dispatch-feature and team-lead. Loaded on-demand.
 
 2. **NEVER skip clarify on ambiguous requests** — if in doubt, ask.
 
-3. **NEVER spawn more than one teammate per repo** — one teammate handles ALL commit units
-   for its repo sequentially. Two teammates on the same repo = guaranteed conflicts.
+3. **NEVER spawn more than one teammate per commit unit for the same repo at the same time** —
+   commit units for the same repo are handled sequentially, one teammate at a time.
+   Two teammates on the same repo = guaranteed conflicts.
 
 4. **NEVER skip the plan file** — everything is tracked on disk.
 
@@ -35,8 +36,8 @@ Reference file for dispatch-feature and team-lead. Loaded on-demand.
 13. **NEVER use git checkout -b in repos** — use git branch {name} {source} (no checkout).
     Checkout changes the working directory, which disrupts other sessions running in parallel.
 
-14. **NEVER skip micro-QA between commits** — Bash tests + Haiku diff after every commit.
-    Waiting until the final QA is too late — issues compound across commits.
+14. **NEVER skip micro-QA between commit units** — Bash tests + Haiku diff after every commit unit, before user review.
+    Waiting until the final QA is too late — issues compound across units.
 
 15. **NEVER prune worktrees during an active session** — worktrees persist until session close.
     The session-start-context.sh hook only cleans worktrees that are truly orphaned (no session JSON).
@@ -44,8 +45,14 @@ Reference file for dispatch-feature and team-lead. Loaded on-demand.
 16. **NEVER over-split commit units** — 10+ commit units per service is excessive.
     Sweet spot: 2-5 per repo. Each spawn has context loading overhead.
 
-17. **NEVER greenlight next commit before micro-QA completes** — Bash verification AND
-    Haiku review must both pass before SendMessage "green light" to teammate.
+17. **NEVER spawn the next commit unit before user has committed the previous** — micro-QA must pass,
+    user must review and approve, team lead must commit — only then spawn the next unit's implementer.
+
+18. **NEVER let implementer run git add or git commit** — the implementer writes code and runs tests.
+    The team lead commits after user review. The PreToolUse hook blocks git add/commit as a safety net.
+
+19. **NEVER spawn the next commit unit before user has committed the previous** — each commit unit
+    requires: implementer writes code → micro-QA → user review → team lead commits → next unit.
 
 ## Common mistakes to watch for
 
@@ -56,8 +63,9 @@ Reference file for dispatch-feature and team-lead. Loaded on-demand.
 | Plan has vague tasks like "implement feature" | Each task should have a clear input→output | Rewrite plan with specific tasks before dispatch |
 | API contract has {} placeholder | Frontend can't build types | Complete the contract shapes before wave 2 |
 | Two teammates spawned on same repo | Git conflicts guaranteed | Kill one, let the remaining handle all commits |
-| Teammate proceeds without waiting for green light | Commits stack unverified | Send explicit STOP instruction, run micro-QA on all unverified commits |
-| No signal from teammate after commit | Silent failure | Check git log on worktree, re-send green light or ask teammate to signal |
+| Implementer runs git add/commit | Code committed without user review | PreToolUse hook should block it; if bypassed, reset with git reset HEAD~1 and re-present for review |
+| Next unit spawned before user committed previous | Uncommitted changes from unit N conflict with unit N+1 | Wait for user approval + team lead commit before spawning next unit |
+| No signal from teammate after implementation | Silent failure | Check worktree git status/diff, ask teammate to signal or escalate |
 | Worktree missing after crash | git worktree list shows nothing | Recreate worktree from session branch: git worktree add /tmp/... session/{name} |
 | Giant commit (500+ lines) | Unreadable PR | Note in session log; teammate should split next time |
 | Commit unit not self-contained | Teammate can't understand scope | Rewrite: each unit must be understandable with only previous context |

package/global-skills/dispatch-feature/references/rollback-protocol.md

@@ -20,6 +20,19 @@ If the branch is unrecoverable:
 3. Re-dispatch ALL commit units for this service from scratch
 4. Warn the user — this resets all progress on this service
 
+## Discarding uncommitted changes (failed commit unit)
+
+If an implementer produces bad code that fails micro-QA and cannot be fixed:
+
+1. Discard all uncommitted changes in the worktree:
+   ```bash
+   git -C /tmp/{repo}-{session-name} checkout -- .
+   git -C /tmp/{repo}-{session-name} clean -fd  # remove untracked files if needed
+   ```
+2. Mark the commit unit ❌ in the plan with reason
+3. Re-spawn implementer with corrected instructions
+4. If 2 retries fail → escalate to user
+
 ## Failed dispatch tracking
 
 After 2 failed re-dispatches of a commit unit:

package/global-skills/dispatch-feature/references/spawn-templates.md

@@ -2,21 +2,21 @@
 
 Reference file for dispatch-feature and team-lead. Loaded on-demand.
 
-> v5 model: ONE teammate per repo, handles ALL commit units sequentially.
-> The teammate signals after each commit and waits for orchestrator green light.
-> Teammates receive a ready worktree — NO git setup in spawn prompts.
-> Implementers do NOT receive the constitution automatically. Every spawn
-> template below includes a "Constitution" section that you MUST fill with
-> all rules from your workspace's constitution.md.
+> v5.2.3 model: ONE teammate per COMMIT UNIT. The teammate writes code without
+> committing, then signals when code is ready for review. The team lead commits
+> after user approval. Teammates receive a ready worktree — NO git setup in
+> spawn prompts. Implementers do NOT receive the constitution automatically.
+> Every spawn template below includes a "Constitution" section that you MUST
+> fill with all rules from your workspace's constitution.md.
 
 ## Context tiering — what to inject per repo type
 
 | Context | Backend repo | Frontend repo | Infra repo |
 |---------|:-:|:-:|:-:|
 | worktree_path + session_branch | ALWAYS | ALWAYS | ALWAYS |
-| Complete repo plan (all commits) | ALWAYS | ALWAYS | ALWAYS |
+| This commit unit's tasks ONLY + context summary | ALWAYS | ALWAYS | ALWAYS |
 | Constitution rules | ALWAYS | ALWAYS | ALWAYS |
-| Signal + wait instruction | ALWAYS | ALWAYS | ALWAYS |
+| Signal-when-ready instruction (no commit) | ALWAYS | ALWAYS | ALWAYS |
 | API contract shapes | If API commits | ALWAYS (TypeScript) | Never |
 | UX standards | Never | If UI commits | Never |
 
@@ -40,36 +40,31 @@ You are the implementer teammate for [{repo}].
 {paste the exact request/response shapes for all endpoints in this plan}
 {note: frontend will build TypeScript interfaces from these shapes}
 
-## Your complete plan — all {N} commit units
+## Your commit unit — {N} of {total} for this repo
+{summary of what previous units already implemented, if any}
 
-### Commit 1: {title}
+### Commit {N}: {title}
 {tasks}
 ~{N} files, ~{N} lines
 
-### Commit 2: {title}
-{tasks}
-~{N} files, ~{N} lines
-
-{...}
-
 ## Signal protocol (MANDATORY)
-After EACH commit:
-  SendMessage: "commit N done — {hash} — {N files} — tests: {pass/fail} — {dead code or blockers if any}"
-Then WAIT for my "green light" before starting the next commit.
-If you hit an architectural decision not covered by the plan: SendMessage immediately and wait.
+When code is written and tests pass:
+  SendMessage: "code ready — {N files changed} — tests: {pass/fail} — {blockers}"
+Then STOP. Do NOT run git add or git commit.
+If you hit an architectural decision not covered by the plan: SendMessage immediately and STOP.
 
-## Scope discipline
-For each commit unit: read ONLY the files in scope for that commit.
-Do not reload the entire repo between commits.
+## CRITICAL: No committing
+Do NOT run git add or git commit. Leave all changes uncommitted.
+The team lead will commit after user review.
 
 ## Instructions
 1. Go directly to your worktree: cd {worktree_path}
 2. Read the repo CLAUDE.md — follow its conventions throughout
 3. Check git log to see what's already on the branch (if resuming)
-4. Work through each commit unit sequentially, waiting for green light between each
-5. Run tests after each commit — report pass/fail in your signal
-6. List dead code found after each commit
-7. If >300 lines in a single commit, split it (data → logic → API layer)
+4. Implement your commit unit — run tests and report results
+5. Do NOT run git add or git commit
+6. List dead code found
+7. If >300 lines changed, note it in your signal
 8. Escalate immediately if you hit an architectural decision not in the plan
 ```
 
@@ -92,37 +87,33 @@ You are the implementer teammate for [{repo}].
 ## API contract (TypeScript interfaces)
 {paste exact response shapes as TypeScript interfaces for all endpoints used in this plan}
 
-## Your complete plan — all {N} commit units
+## Your commit unit — {N} of {total} for this repo
+{summary of what previous units already implemented, if any}
 
-### Commit 1: {title}
-{tasks}
-~{N} files, ~{N} lines
-
-### Commit 2: {title}
+### Commit {N}: {title}
 {tasks — if UI components: MUST handle 4 states: skeleton, empty+CTA, error+retry, success}
 ~{N} files, ~{N} lines
 
-{...}
-
 ## Signal protocol (MANDATORY)
-After EACH commit:
-  SendMessage: "commit N done — {hash} — {N files} — tests: {pass/fail} — UX states: {compliant/issues} — {dead code or blockers if any}"
-Then WAIT for my "green light" before starting the next commit.
-If you hit an architectural decision not covered by the plan: SendMessage immediately and wait.
+When code is written and tests pass:
+  SendMessage: "code ready — {N files changed} — tests: {pass/fail} — UX states: {compliant/issues} — {blockers}"
+Then STOP. Do NOT run git add or git commit.
+If you hit an architectural decision not covered by the plan: SendMessage immediately and STOP.
 
-## Scope discipline
-For each commit unit: read ONLY the files in scope for that commit.
-Do not reload the entire repo between commits.
+## CRITICAL: No committing
+Do NOT run git add or git commit. Leave all changes uncommitted.
+The team lead will commit after user review.
 
 ## Instructions
 1. Go directly to your worktree: cd {worktree_path}
 2. Read the repo CLAUDE.md — follow its conventions throughout
 3. Check git log to see what's already on the branch (if resuming)
-4. Work through each commit unit sequentially, waiting for green light between each
+4. Implement your commit unit
 5. For every UI component: implement all 4 states (skeleton, empty+CTA, error+retry, success)
-6. Run tests after each commit — report pass/fail in your signal
-7. List dead code (unused components, composables, store actions, CSS)
-8. Escalate immediately if you hit an architectural decision not in the plan
+6. Run tests — report pass/fail in your signal
+7. Do NOT run git add or git commit
+8. List dead code (unused components, composables, store actions, CSS)
+9. Escalate immediately if you hit an architectural decision not in the plan
 ```
 
 ## Infra/Config teammate spawn template
@@ -138,33 +129,36 @@ You are the implementer teammate for [{repo}] (infrastructure/configuration).
 ## Constitution (non-negotiable)
 {paste all rules from constitution.md, translated to English}
 
-## Your complete plan — all {N} commit units
+## Your commit unit — {N} of {total} for this repo
+{summary of what previous units already implemented, if any}
 
-### Commit 1: {title}
+### Commit {N}: {title}
 {tasks — typically gateway routes, env vars, docker configs}
 ~{N} files
 
-{...}
-
 ## Signal protocol (MANDATORY)
-After EACH commit:
-  SendMessage: "commit N done — {hash} — {N files} — consistency check: {OK/issues}"
-Then WAIT for my "green light" before starting the next commit.
+When code is written and checks pass:
+  SendMessage: "code ready — {N files changed} — consistency check: {OK/issues} — {blockers}"
+Then STOP. Do NOT run git add or git commit.
+
+## CRITICAL: No committing
+Do NOT run git add or git commit. Leave all changes uncommitted.
+The team lead will commit after user review.
 
 ## Instructions
 1. Go directly to your worktree: cd {worktree_path}
 2. Implement ONLY configuration changes — no application code
-3. Verify consistency with other services after each commit (env vars, routes, schemas)
-4. Commit message format: chore(scope): description
+3. Verify consistency with other services (env vars, routes, schemas)
+4. Do NOT run git add or git commit
 5. Escalate if you hit configuration decisions not covered by the plan
 ```
 
 ## Haiku micro-QA subagent template
 
-Used by Opus in Phase 4 micro-QA between commits.
+Used by Opus in Phase 4 micro-QA on uncommitted changes (git diff, not git diff HEAD~1 HEAD).
 
 ```
-Read the following git diff and return ONLY a JSON object — no markdown, no preamble:
+Read the following git diff (uncommitted changes) and return ONLY a JSON object — no markdown, no preamble:
 
 If no issues found:
 {"status":"OK"}
@@ -180,7 +174,7 @@ Check for:
 
 Return ONLY the JSON object. No text before or after it.
 
-Diff:
+Diff (uncommitted):
 {git diff output}
 ```
 
@@ -190,9 +184,9 @@ When a teammate signals a failure or when Bash/Haiku micro-QA fails:
 
 | Situation | Action |
 |-----------|--------|
-| Tests fail on commit N | Send fix instruction to teammate, ask to re-commit |
-| Haiku BLOCKER on commit N | Opus evaluates — if fixable: send instruction; if architectural: escalate to user |
+| Tests fail on commit unit N | Re-spawn implementer with fix instructions for the same commit unit |
+| Haiku BLOCKER on commit unit N | Opus evaluates — if fixable: re-spawn with instructions; if architectural: escalate to user |
 | Architectural decision not in plan | STOP the wave, escalate to user, resume after direction |
-| Teammate silent / no signal | Check worktree git log, re-send green light or escalate |
+| Teammate silent / no signal | Check worktree git status/diff, re-spawn or escalate |
 | Max 2 retries on same commit | Mark ❌ ESCALATED, stop the wave, present to user |
 | Corrupted branch | Use rollback protocol (see team-lead agent / rollback-protocol.md) |

package/global-skills/hooks/test_hooks.sh

@@ -135,32 +135,32 @@ echo ""
 echo "▸ validate-spawn-prompt.sh"
 
 # Complete prompt should have no warnings
-GOOD_PROMPT='{"tool_input":{"prompt":"## Constitution\n1. **Multi-tenancy** is sacred.\n2. **No hardcoded secrets.**\n\n## Your complete plan — all 3 commit units\n### Commit 1: Data layer\nCreate models\n\n## Your workspace\n- Worktree (ready, go directly here): /tmp/svc-feature-auth\n- Session branch: session/feature-auth\n\n## Signal protocol (MANDATORY)\nAfter EACH commit: SendMessage commit N done. Then WAIT for my green light.\n\nRead the repo CLAUDE.md first.\nIf you hit an architectural decision not in the plan: SendMessage immediately and wait."}}'
+GOOD_PROMPT='{"tool_input":{"subagent_type":"implementer","prompt":"## Constitution\n1. **Multi-tenancy** is sacred.\n2. **No hardcoded secrets.**\n\n## Your commit unit — 1 of 3 for this repo\n### Commit 1: Data layer\nCreate models\n\n## Your workspace\n- Worktree (ready, go directly here): /tmp/svc-feature-auth\n- Session branch: session/feature-auth\n\n## Signal protocol (MANDATORY)\nWhen code is written and tests pass: SendMessage code ready. Then STOP. Do NOT run git add or git commit.\n\nRead the repo CLAUDE.md first.\nIf you hit an architectural decision not in the plan: SendMessage immediately and STOP."}}'
 OUT=$(run_hook "validate-spawn-prompt.sh" "$GOOD_PROMPT")
 assert_empty "complete prompt (non-API/non-frontend) — no warnings" "$OUT"
 
 # Missing constitution should warn
-NO_CONST='{"tool_input":{"prompt":"## Your plan\n### Commit 1: stuff\nworktree_path: /tmp/api-x\nSendMessage after each commit and wait for green light."}}'
+NO_CONST='{"tool_input":{"subagent_type":"implementer","prompt":"## Your commit unit\n### Commit 1: stuff\nworktree_path: /tmp/api-x\nSendMessage code ready. Do NOT run git add or git commit."}}'
 OUT=$(run_hook "validate-spawn-prompt.sh" "$NO_CONST")
 assert_contains "warns on missing constitution" "$OUT" "project-specific rules"
 
 # Missing plan should warn
-NO_PLAN='{"tool_input":{"prompt":"## Constitution\n1. **Rule one.**\nworktree_path: /tmp/api-x\nSendMessage after each commit."}}'
+NO_PLAN='{"tool_input":{"subagent_type":"implementer","prompt":"## Constitution\n1. **Rule one.**\nworktree_path: /tmp/api-x\nSendMessage after each commit."}}'
 OUT=$(run_hook "validate-spawn-prompt.sh" "$NO_PLAN")
 assert_contains "warns on missing plan/tasks" "$OUT" "plan/tasks"
 
 # Missing worktree path should warn
-NO_WT='{"tool_input":{"prompt":"## Constitution\n1. **Rule one.**\n## Your plan\n### Commit 1: stuff\nSendMessage after each commit."}}'
+NO_WT='{"tool_input":{"subagent_type":"implementer","prompt":"## Constitution\n1. **Rule one.**\n## Your commit unit\n### Commit 1: stuff\nSendMessage code ready."}}'
 OUT=$(run_hook "validate-spawn-prompt.sh" "$NO_WT")
 assert_contains "warns on missing worktree_path" "$OUT" "worktree_path"
 
 # Missing signal protocol should warn
-NO_SIGNAL='{"tool_input":{"prompt":"## Constitution\n1. **Rule one.**\n## Your plan\n### Commit 1: stuff\nWorktree ready: /tmp/api-x"}}'
+NO_SIGNAL='{"tool_input":{"subagent_type":"implementer","prompt":"## Constitution\n1. **Rule one.**\n## Your commit unit\n### Commit 1: stuff\nWorktree ready: /tmp/api-x"}}'
 OUT=$(run_hook "validate-spawn-prompt.sh" "$NO_SIGNAL")
 assert_contains "warns on missing signal protocol" "$OUT" "signal protocol"
 
 # Frontend without UX standards should warn
-FRONT_NO_UX='{"tool_input":{"prompt":"## Constitution\n1. **Rule one.**\nfrontend Vue component\n## Your plan\n### Commit 1: UI\n/tmp/front-x\nSendMessage commit N done. WAIT for green light."}}'
+FRONT_NO_UX='{"tool_input":{"subagent_type":"implementer","prompt":"## Constitution\n1. **Rule one.**\nfrontend Vue component\n## Your commit unit\n### Commit 1: UI\n/tmp/front-x\nSendMessage code ready. Do NOT run git add or git commit."}}'
 OUT=$(run_hook "validate-spawn-prompt.sh" "$FRONT_NO_UX")
 assert_contains "warns frontend without UX standards" "$OUT" "UX standards"
 

package/global-skills/hooks/validate-spawn-prompt.sh

@@ -1,6 +1,6 @@
 #!/usr/bin/env bash
 # validate-spawn-prompt.sh
-# PreToolUse hook (matcher: Teammate): validates that teammate spawn prompts
+# PreToolUse hook (matcher: Agent): validates that teammate spawn prompts
 # contain the required context before allowing the spawn.
 # v5.0: Updated for one-teammate-per-repo model with worktree_path and signal protocol.
 # ALL checks are non-blocking warnings (exit 0 + stdout).
@@ -8,6 +8,12 @@ set -euo pipefail
 
 INPUT=$(cat)
 
+# Only validate implementer spawns (skip Explore and other subagent types)
+SUBAGENT_TYPE=$(echo "$INPUT" | jq -r '.tool_input.subagent_type // empty' 2>/dev/null) || true
+if [ "$SUBAGENT_TYPE" != "implementer" ]; then
+    exit 0
+fi
+
 # Extract the spawn prompt from tool input
 PROMPT=$(echo "$INPUT" | jq -r '.tool_input.prompt // empty' 2>/dev/null) || true
 
@@ -42,18 +48,18 @@ if [ "$RULES_FOUND" -eq 0 ]; then
 fi
 
 # Check 2: Tasks / plan section must be present
-if ! echo "$PROMPT" | grep -qiE '(your (complete )?plan|## (commit|tasks|plan)|commit [0-9]+:|all [0-9]+ commit)' 2>/dev/null; then
-    BLOCKERS+="- Missing plan/tasks section in spawn prompt. Include the complete repo plan with all commit units.\n"
+if ! echo "$PROMPT" | grep -qiE '(your (complete )?plan|your commit unit|## (commit|tasks|plan)|commit [0-9]+:|all [0-9]+ commit)' 2>/dev/null; then
+    BLOCKERS+="- Missing plan/tasks section in spawn prompt. Include the commit unit tasks.\n"
 fi
 
 # Check 3: Worktree path (v5 — teammates receive a ready worktree)
 if ! echo "$PROMPT" | grep -qiE '(worktree.path|worktree.ready|go directly|/tmp/[a-z])' 2>/dev/null; then
-    BLOCKERS+="- Missing worktree_path in spawn prompt. Teammate needs the /tmp/ path prepared by Opus.\n"
+    BLOCKERS+="- Missing worktree_path in spawn prompt. Implementer needs the /tmp/ path prepared by Opus.\n"
 fi
 
 # Check 4: Signal protocol instruction
-if ! echo "$PROMPT" | grep -qiE '(SendMessage|signal protocol|commit N done|green light|wait for)' 2>/dev/null; then
-    BLOCKERS+="- Missing signal protocol instruction. Teammate must know to SendMessage after each commit and wait for green light.\n"
+if ! echo "$PROMPT" | grep -qiE '(SendMessage|signal protocol|code ready|commit N done|no commit)' 2>/dev/null; then
+    BLOCKERS+="- Missing signal protocol instruction. Implementer must know to SendMessage when code is ready and NOT commit.\n"
 fi
 
 # Check 5: CLAUDE.md instruction

package/global-skills/incident-debug/SKILL.md

@@ -8,7 +8,7 @@ description: >
   stack traces or error logs. Also French triggers: "erreur", "ça marche pas".
 argument-hint: "[error description or stack trace]"
 context: fork
-allowed-tools: Read, Write, Glob, Grep, Task, Teammate, SendMessage
+allowed-tools: Read, Write, Glob, Grep, Task, TeamCreate, TeamDelete, SendMessage
 ---
 
 # Incident Debug — Multi-Layer Investigation

package/global-skills/qa-ruthless/SKILL.md

@@ -10,7 +10,7 @@ description: >
 argument-hint: "[plan-name or 'all']"
 context: fork
 model: opus
-allowed-tools: Read, Write, Glob, Grep, Task, Teammate, SendMessage
+allowed-tools: Read, Write, Glob, Grep, Task, TeamCreate, TeamDelete, SendMessage
 ---
 
 # QA Ruthless — Adversarial Quality Review

package/global-skills/rules/model-routing.md

@@ -20,9 +20,9 @@ If you write application code in a repo (not a markdown plan, not a git command,
 | Role | Model | Mechanism |
 |------|-------|-----------|
 | Orchestrator | **Opus** | `claude --agent team-lead` (frontmatter `model: opus`) |
-| Implementation teammates | **Sonnet** | `Teammate` tool via Agent Teams |
+| Implementation teammates | **Sonnet** | `TeamCreate` + `Agent(implementer, team_name)` via Agent Teams |
 | QA orchestration | **Opus** | `qa-ruthless` skill (frontmatter `model: opus`) |
-| QA investigators | **Sonnet** | `Teammate` tool via Agent Teams (spawned by qa-ruthless) |
+| QA investigators | **Sonnet** | `TeamCreate` + `Agent(implementer, team_name)` via Agent Teams (spawned by qa-ruthless) |
 | Code reviewer | **Opus** | `claude --agent reviewer` (evidence-based review, architecture judgment) |
 | Security auditor | **Opus** | `claude --agent security-auditor` (auth flows, tenant isolation, secrets, CVEs) |
 | Plan review | **Sonnet** | `plan-review` skill (constitution compliance needs reasoning) |
@@ -55,5 +55,5 @@ Rationale: Opus knows what to look for based on the feature. Haiku summaries los
 Constraint: Opus reads only files directly related to the feature scope.
 
 ## Implementer model
-Implementation teammates use **Sonnet** via the `Teammate` tool.
-One teammate per repo. The teammate handles all commit units for its repo sequentially.
+Implementation teammates use **Sonnet** via Agent Teams (`TeamCreate` + `Agent(subagent_type: "implementer", team_name: ...)`).
+One teammate per commit unit. Each implementer handles a single commit unit, writes code without committing, and signals when ready for review.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cc-workspace",
-  "version": "5.2.2",
+  "version": "5.2.4",
   "description": "Claude Code multi-workspace orchestrator \u2014 skills, hooks, agents, and templates for multi-service projects",
   "bin": {
     "cc-workspace": "./bin/cli.js"