@mmerterden/multi-agent-pipeline 8.6.0

package/pipeline/commands/multi-agent/dev-autopilot.md

@@ -0,0 +1,120 @@
+---
+description: "Fastest mode: Dev (Opus) plus Autopilot. Init → Dev → Commit → Report with zero confirmations."
+---
+
+# multi-agent dev autopilot — Fastest Path
+
+**Input**: $ARGUMENTS
+
+> **Language (read FIRST)**: Before any status output, read `prefs.global.outputLanguage` and render every conversational line in it. `AskUserQuestion` and external payloads stay English. Full contract: `refs/rules.md` "Language Application".
+
+Dev mode + Autopilot combined: a 4-phase pipeline with no confirmations, end-to-end autonomous.
+
+## When to use it
+- Small, trusted, urgent changes
+- Bug fixes, copy updates, config tweaks
+- "Just do it, commit, open the PR" scenarios
+
+## Pipeline
+
+```
+Phase 0: Init       → project detection, worktree, branch, identity
+Phase 3: Dev        → direct development on Opus
+Phase 6: Commit     → auto commit + push + PR (no confirmations)
+Phase 7: Report     → short terminal summary
+```
+
+**Skipped phases**: Analysis (1), Planning (2), Review (4), User Test (5).
+**Skipped confirmations**: Plan Approval Gate (clarification + approval loop), test prompt, commit prompt, PR prompt.
+
+> If you want to talk through the plan, do not use this mode — pick `/multi-agent "task"` (normal) or any mode without `autopilot`. The Dev+Autopilot contract is: "ask nothing."
+
+## Steps
+
+1. **Parse input** — standard multi-agent input formats (Issue URL, Jira ID, free text)
+2. **Phase 0: Init** — set `"mode": "dev", "autopilot": true` in `agent-state.json`
+3. **Phase 3: Dev** — write code directly on `claude-opus-4.6` and verify the build
+4. **Phase 6: Commit** — auto commit + push + PR
+5. **Phase 7: Report** — terminal summary
+
+## Safety
+
+- Build failure → 3 retries; if it still fails → **pause** (ask the user)
+- Kill / Purge → always asks for confirmation (destructive)
+
+## Differences
+
+| | Full | Dev | Autopilot | **Dev+Autopilot** |
+|--|------|-----|-----------|-------------------|
+| Phases | 8 | 4 | 8 | **4** |
+| Model | Sonnet | Opus | Sonnet | **Opus** |
+| Plan Approval Gate | ✅ (clarification + approval) | ❌ | ❌ | **❌** |
+| Confirmations (test / commit / PR) | Yes | Yes | No | **No** |
+| Review | Parallel + triage (CLI-aware) | None | Parallel + triage (CLI-aware) | **None** |
+| Estimated duration | ~12 min | ~5 min | ~10 min | **~3 min** |
+## Required: Phase Tracker Contract
+
+**The phase tracker is mandatory** — the agent cannot skip it. Full spec: [`refs/tracker-contract.md`](./refs/tracker-contract.md).
+
+> **Autopilot mode:** user confirmations are skipped. The tracker is still mandatory — autopilot agent calls cannot skip it; skipping breaks `smoke-tracker-contract.sh`.
+
+Two channels run in parallel at every phase boundary:
+
+1. **State channel** (every CLI, identical): `phase-tracker.sh` writes to `tracker-state.json`. Drives `:resume`, `:log`, `:status`.
+2. **Visual channel** (CLI-specific): native widget on Claude Code, ANSI render on every other CLI. Without it the user sees no phase progress.
+
+```bash
+# Phase 0, very first shell call (every CLI):
+bash $HOME/.claude/scripts/phase-tracker.sh init "$TASK_ID"
+for p in "0:Init" "3:Dev" "6:Commit" "7:Report"; do
+  bash $HOME/.claude/scripts/phase-tracker.sh add "${p%%:*}" "${p#*:}"
+done
+bash $HOME/.claude/scripts/phase-tracker.sh update 0 in_progress
+
+# Every phase boundary (every CLI):
+bash $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress|completed|failed|skipped
+
+# After every LLM call (every CLI):
+bash $HOME/.claude/scripts/phase-tracker.sh tokens <N> <in> <out>
+```
+
+### Visual channel — Claude Code (native TaskList widget, required)
+
+In Claude Code the agent MUST also drive the native TaskList widget so the user sees a sticky phase tile stack — this is the only progress signal Claude Code surfaces. Skipping these calls is the #1 source of "I don't see any phases" complaints.
+
+**TaskCreate ordering (strict)**: All TaskCreate calls fire in strict phase-number order BEFORE any TaskUpdate is applied. The native widget renders by creation order, not by phase number — out-of-order calls produce visually scrambled tile stacks (e.g. `1 ✓ · 2 ✓ · 4 ✓ · 0 ▶ · 3 ☐`) even when the underlying state is correct. Pre-marking phases as completed/skipped before Phase 0 starts is FORBIDDEN — register the tile in order, then flip status via TaskUpdate when the phase actually short-circuits. Full contract in `refs/tracker-contract.md` § "TaskCreate ordering (strict)".
+
+```text
+# Phase 0 startup — register one tile per phase (0..N), capture the taskId, persist it:
+for each phase in 0:Init, 3:Dev, 6:Commit, 7:Report:
+  TaskCreate({ subject: "Phase <N>: <Name>", activeForm: "<doing-form>" })
+    -> returns taskId
+  bash $HOME/.claude/scripts/phase-tracker.sh meta <N> tasklist_id "<taskId>"
+
+# Phase entry — flip the tile to in_progress alongside the state update:
+TaskUpdate({ taskId: <saved>, status: "in_progress" })
+bash $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress
+
+# Active sub-step inside a phase — update activeForm so the spinner header reflects what's happening now:
+TaskUpdate({ taskId: <saved>, activeForm: "Editing TopBarView.swift" })
+
+# Phase exit — flip to completed/failed/skipped on both channels:
+TaskUpdate({ taskId: <saved>, status: "completed" })
+bash $HOME/.claude/scripts/phase-tracker.sh update <N> completed
+```
+
+`--dev autopilot` mode does NOT TaskCreate phases 1/2/4/5 — those are not part of the `--dev autopilot` phase set (`0:Init 3:Dev 6:Commit 7:Report`). Only register tiles for the active set.
+
+#### TaskCreate ordering (strict)
+
+**All TaskCreate calls fire in strict phase-number order BEFORE any TaskUpdate is applied.** For `--dev autopilot` that means: Phase 0 → Phase 3 → Phase 6 → Phase 7. The native widget renders by creation order, not by phase number — out-of-order calls produce visually scrambled tile stacks. Full ordering contract in `refs/tracker-contract.md` § "TaskCreate ordering (strict)".
+
+### Visual channel — Copilot CLI / Cursor / Windsurf / plain shell
+
+These CLIs have no TaskList widget. After every state change the agent calls render, which prints a bordered ANSI card as the last tool result so the user sees an updated phase table:
+
+```bash
+bash $HOME/.claude/scripts/phase-tracker.sh render
+```
+
+Do NOT call TaskCreate on these CLIs — the tool does not exist and the call fails.

package/pipeline/commands/multi-agent/dev-local-autopilot.md

@@ -0,0 +1,110 @@
+---
+description: "Fastest + local — Dev(Opus) + autopilot, no worktree, zero interaction."
+allowed-tools: Agent, Bash, Read, Write, Edit, Glob, Grep, TaskCreate, TaskUpdate, TaskList, TaskGet, WebFetch, Skill
+---
+
+# multi-agent dev-local-autopilot — Fastest + Local
+
+> **Language (read FIRST)**: Before any status output, read `prefs.global.outputLanguage` and render every conversational line in it. `AskUserQuestion` and external payloads stay English. Full contract: `refs/rules.md` "Language Application".
+
+The triple `--dev` + `--local` + `autopilot` — the fastest form available. Zero confirmations, NO worktree.
+
+## Pipeline
+
+```
+Phase 0: Init       → project detection, branch check, state (NO worktree, NO confirmation)
+Phase 3: Dev        → direct development on Opus (automatic)
+Phase 6: Commit     → auto commit + push + PR (no local checkout prompt)
+Phase 7: Report     → Jira / Wiki + log + knowledge/memory
+```
+
+## When to use it
+
+- Routine change you trust that needs no review
+- A CI / batch environment running the pipeline automatically — no user interaction
+- Prototype / spike — you care about speed, quality gates can wait
+
+## When NOT to use it
+
+- Production-bound change — at minimum use `--dev` (without autopilot)
+- Security-sensitive code — autopilot bypasses the safety gates
+- A first big refactor — human review is required
+
+## Delegation
+
+Routes to the orchestrator with `--dev --local autopilot` flags. The pipeline contract matches `dev-autopilot.md` exactly, with Phase 0 Step 8 (worktree creation) skipped.
+
+## Examples
+
+```bash
+/multi-agent:dev-local-autopilot "PROJ-12345"                  # Jira
+/multi-agent:dev-local-autopilot "Add retry to HomeNetworking" # Free-text
+```
+## Required: Phase Tracker Contract
+
+**The phase tracker is mandatory** — the agent cannot skip it. Full spec: [`refs/tracker-contract.md`](./refs/tracker-contract.md).
+
+> **Autopilot mode:** user confirmations are skipped. The tracker is still mandatory — autopilot agent calls cannot skip it; skipping breaks `smoke-tracker-contract.sh`.
+
+> **Local mode:** no worktree is created, work happens on the current branch. Phase 0 Init still calls `init` — the `--local` flag is stored in tracker-state.json, and `:resume` restores the correct CWD.
+
+Two channels run in parallel at every phase boundary:
+
+1. **State channel** (every CLI, identical): `phase-tracker.sh` writes to `tracker-state.json`. Drives `:resume`, `:log`, `:status`.
+2. **Visual channel** (CLI-specific): native widget on Claude Code, ANSI render on every other CLI. Without it the user sees no phase progress.
+
+```bash
+# Phase 0, very first shell call (every CLI):
+bash $HOME/.claude/scripts/phase-tracker.sh init "$TASK_ID"
+for p in "0:Init" "3:Dev" "6:Commit" "7:Report"; do
+  bash $HOME/.claude/scripts/phase-tracker.sh add "${p%%:*}" "${p#*:}"
+done
+bash $HOME/.claude/scripts/phase-tracker.sh update 0 in_progress
+
+# Every phase boundary (every CLI):
+bash $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress|completed|failed|skipped
+
+# After every LLM call (every CLI):
+bash $HOME/.claude/scripts/phase-tracker.sh tokens <N> <in> <out>
+```
+
+### Visual channel — Claude Code (native TaskList widget, required)
+
+In Claude Code the agent MUST also drive the native TaskList widget so the user sees a sticky phase tile stack — this is the only progress signal Claude Code surfaces. Skipping these calls is the #1 source of "I don't see any phases" complaints.
+
+**TaskCreate ordering (strict)**: All TaskCreate calls fire in strict phase-number order BEFORE any TaskUpdate is applied. The native widget renders by creation order, not by phase number — out-of-order calls produce visually scrambled tile stacks (e.g. `1 ✓ · 2 ✓ · 4 ✓ · 0 ▶ · 3 ☐`) even when the underlying state is correct. Pre-marking phases as completed/skipped before Phase 0 starts is FORBIDDEN — register the tile in order, then flip status via TaskUpdate when the phase actually short-circuits. Full contract in `refs/tracker-contract.md` § "TaskCreate ordering (strict)".
+
+```text
+# Phase 0 startup — register one tile per phase (0..N), capture the taskId, persist it:
+for each phase in 0:Init, 3:Dev, 6:Commit, 7:Report:
+  TaskCreate({ subject: "Phase <N>: <Name>", activeForm: "<doing-form>" })
+    -> returns taskId
+  bash $HOME/.claude/scripts/phase-tracker.sh meta <N> tasklist_id "<taskId>"
+
+# Phase entry — flip the tile to in_progress alongside the state update:
+TaskUpdate({ taskId: <saved>, status: "in_progress" })
+bash $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress
+
+# Active sub-step inside a phase — update activeForm so the spinner header reflects what's happening now:
+TaskUpdate({ taskId: <saved>, activeForm: "Editing TopBarView.swift" })
+
+# Phase exit — flip to completed/failed/skipped on both channels:
+TaskUpdate({ taskId: <saved>, status: "completed" })
+bash $HOME/.claude/scripts/phase-tracker.sh update <N> completed
+```
+
+`--dev local autopilot` mode does NOT TaskCreate phases 1/2/4/5 — those are not part of the `--dev local autopilot` phase set (`0:Init 3:Dev 6:Commit 7:Report`). Only register tiles for the active set.
+
+#### TaskCreate ordering (strict)
+
+**All TaskCreate calls fire in strict phase-number order BEFORE any TaskUpdate is applied.** For `--dev local autopilot` that means: Phase 0 → Phase 3 → Phase 6 → Phase 7. The native widget renders by creation order, not by phase number — out-of-order calls produce visually scrambled tile stacks. Full ordering contract in `refs/tracker-contract.md` § "TaskCreate ordering (strict)".
+
+### Visual channel — Copilot CLI / Cursor / Windsurf / plain shell
+
+These CLIs have no TaskList widget. After every state change the agent calls render, which prints a bordered ANSI card as the last tool result so the user sees an updated phase table:
+
+```bash
+bash $HOME/.claude/scripts/phase-tracker.sh render
+```
+
+Do NOT call TaskCreate on these CLIs — the tool does not exist and the call fails.

package/pipeline/commands/multi-agent/dev-local.md

@@ -0,0 +1,105 @@
+---
+description: "Fast mode + local — Init → Dev(Opus) → Commit → Report, no worktree."
+allowed-tools: Agent, Bash, Read, Write, Edit, Glob, Grep, TaskCreate, TaskUpdate, TaskList, TaskGet, AskUserQuestion, WebFetch, Skill
+---
+
+# multi-agent dev-local — Fast + Local
+
+> **Language (read FIRST)**: Before any status output, read `prefs.global.outputLanguage` and render every conversational line in it. `AskUserQuestion` and external payloads stay English. Full contract: `refs/rules.md` "Language Application".
+
+Dedicated form of the `--dev` + `--local` combination. A 4-phase fast pipeline with NO worktree.
+
+## Pipeline
+
+```
+Phase 0: Init       → project detection, branch check, state (NO worktree)
+Phase 3: Dev        → direct development on Opus (Analysis + Planning + Review skipped)
+Phase 6: Commit     → pre-commit checkout prompt, commit + push + PR
+Phase 7: Report     → Jira / Wiki + log + knowledge/memory
+```
+
+## When to use it
+
+- Quick bug fix or small feature — review overhead is unnecessary
+- You're working on the current branch and don't want to switch worktrees
+- A change you trust — no need for multi-model review
+## Required: Phase Tracker Contract
+
+**The phase tracker is mandatory** — the agent cannot skip it. Full spec: [`refs/tracker-contract.md`](./refs/tracker-contract.md).
+
+> **Local mode:** no worktree is created, work happens on the current branch. Phase 0 Init still calls `init` — the `--local` flag is stored in tracker-state.json, and `:resume` restores the correct CWD.
+
+Two channels run in parallel at every phase boundary:
+
+1. **State channel** (every CLI, identical): `phase-tracker.sh` writes to `tracker-state.json`. Drives `:resume`, `:log`, `:status`.
+2. **Visual channel** (CLI-specific): native widget on Claude Code, ANSI render on every other CLI. Without it the user sees no phase progress.
+
+```bash
+# Phase 0, very first shell call (every CLI):
+bash $HOME/.claude/scripts/phase-tracker.sh init "$TASK_ID"
+for p in "0:Init" "3:Dev" "6:Commit" "7:Report"; do
+  bash $HOME/.claude/scripts/phase-tracker.sh add "${p%%:*}" "${p#*:}"
+done
+bash $HOME/.claude/scripts/phase-tracker.sh update 0 in_progress
+
+# Every phase boundary (every CLI):
+bash $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress|completed|failed|skipped
+
+# After every LLM call (every CLI):
+bash $HOME/.claude/scripts/phase-tracker.sh tokens <N> <in> <out>
+```
+
+### Visual channel — Claude Code (native TaskList widget, required)
+
+In Claude Code the agent MUST also drive the native TaskList widget so the user sees a sticky phase tile stack — this is the only progress signal Claude Code surfaces. Skipping these calls is the #1 source of "I don't see any phases" complaints.
+
+**TaskCreate ordering (strict)**: All TaskCreate calls fire in strict phase-number order BEFORE any TaskUpdate is applied. The native widget renders by creation order, not by phase number — out-of-order calls produce visually scrambled tile stacks (e.g. `1 ✓ · 2 ✓ · 4 ✓ · 0 ▶ · 3 ☐`) even when the underlying state is correct. Pre-marking phases as completed/skipped before Phase 0 starts is FORBIDDEN — register the tile in order, then flip status via TaskUpdate when the phase actually short-circuits. Full contract in `refs/tracker-contract.md` § "TaskCreate ordering (strict)".
+
+```text
+# Phase 0 startup — register one tile per phase (0..N), capture the taskId, persist it:
+for each phase in 0:Init, 3:Dev, 6:Commit, 7:Report:
+  TaskCreate({ subject: "Phase <N>: <Name>", activeForm: "<doing-form>" })
+    -> returns taskId
+  bash $HOME/.claude/scripts/phase-tracker.sh meta <N> tasklist_id "<taskId>"
+
+# Phase entry — flip the tile to in_progress alongside the state update:
+TaskUpdate({ taskId: <saved>, status: "in_progress" })
+bash $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress
+
+# Active sub-step inside a phase — update activeForm so the spinner header reflects what's happening now:
+TaskUpdate({ taskId: <saved>, activeForm: "Editing TopBarView.swift" })
+
+# Phase exit — flip to completed/failed/skipped on both channels:
+TaskUpdate({ taskId: <saved>, status: "completed" })
+bash $HOME/.claude/scripts/phase-tracker.sh update <N> completed
+```
+
+`--dev local` mode does NOT TaskCreate phases 1/2/4/5 — those are not part of the `--dev local` phase set (`0:Init 3:Dev 6:Commit 7:Report`). Only register tiles for the active set.
+
+#### TaskCreate ordering (strict)
+
+**All TaskCreate calls fire in strict phase-number order BEFORE any TaskUpdate is applied.** For `--dev local` that means: Phase 0 → Phase 3 → Phase 6 → Phase 7. The native widget renders by creation order, not by phase number — out-of-order calls produce visually scrambled tile stacks. Full ordering contract in `refs/tracker-contract.md` § "TaskCreate ordering (strict)".
+
+### Visual channel — Copilot CLI / Cursor / Windsurf / plain shell
+
+These CLIs have no TaskList widget. After every state change the agent calls render, which prints a bordered ANSI card as the last tool result so the user sees an updated phase table:
+
+```bash
+bash $HOME/.claude/scripts/phase-tracker.sh render
+```
+
+Do NOT call TaskCreate on these CLIs — the tool does not exist and the call fails.
+## Delegation
+
+Routes to the orchestrator with `--dev --local` flags. Apply the `$HOME/.claude/commands/multi-agent/dev.md` pipeline in local mode:
+- Phase 0: skip worktree creation, continue on the current branch
+- Phase 3: develop on Opus (instead of the Sonnet TDD cycle)
+- Phase 5 (Test) and Phase 4 (Review) are skipped (`--dev`)
+- Phase 6: commit + push + PR (the local checkout prompt is natural in local mode — you're already there)
+
+## Examples
+
+```bash
+/multi-agent:dev-local "PROJ-12345"                            # Jira
+/multi-agent:dev-local "Bug: LoginView dark mode"              # Free-text
+```

package/pipeline/commands/multi-agent/dev.md

@@ -0,0 +1,246 @@
+---
+description: "Fast development mode: Init → Dev (Opus) → Test → Commit → Report. Analysis, planning, and review phases are skipped."
+---
+
+# multi-agent dev — Fast Development Mode (--dev)
+
+**Input**: $ARGUMENTS
+
+> **Language (read FIRST)**: Two language axes, independent:
+>
+> 1. **`prefs.global.promptLanguage` is always `en`** — instructions to the LLM (this file, every skill spec, every slash-command body, agent system prompts) stay in English. Do not translate spec docs.
+> 2. **`prefs.global.outputLanguage` is user-selectable** — applies to (a) every conversational line the agent writes back, and (b) every user-facing external payload: PR description body, Jira comment, Confluence body, Wiki body.
+>
+> Regardless of `outputLanguage`, these stay English (interop / convention):
+>   - `AskUserQuestion` labels and descriptions (UI contract)
+>   - Commit message subject/body (git convention)
+>   - Branch names (`feature/`, `bugfix/`, …)
+>   - Code identifiers, file paths, log lines
+>   - PR title prefix (`feat:`, `fix:`, …) — only the body honors `outputLanguage`
+>
+> Full contract: `refs/rules.md` "Language Application".
+
+A 5-phase fast pipeline: Init → Dev → Test → Commit → Report. Development runs on the Opus model.
+
+## When to use it
+- Small changes, bug fixes, quick features
+- Simple tasks that don't need the full 8-phase pipeline
+- Routine work that does not require formal review
+
+## Pipeline
+
+```
+Phase 0: Init       → project detection, worktree, branch, identity (full picker)
+Phase 3: Dev        → direct development on Opus (TDD optional)
+Phase 5: Test       → User Test (interactive simulator)
+Phase 6: Commit     → commit + push + PR
+Phase 7: Report     → channels (Jira / Confluence / PR / Wiki)
+```
+
+`--dev` skips Phase 1 (Analysis), Phase 2 (Planning + Approval Gate), and Phase 4 (Review). Phase 3 Dev runs on **Opus**. Phase 0 picker, Phase 5 test, Phase 6 commit, and Phase 7 channels are identical to the full pipeline.
+
+## What `--dev` does NOT skip (required)
+
+`--dev` skips the LLM-heavy phases (Phase 1 Analysis, Phase 2 Planning + Approval, Phase 4 Review) and runs Phase 3 Dev on Opus. Phase 0 (Init), Phase 5 (Test), Phase 6 (Commit), and Phase 7 (Report + channels) are byte-for-byte the same as the full pipeline. User-facing prompts **always run** — they exist for audit, not speed.
+
+### Required user prompts (Phase 0)
+
+The agent CANNOT make these Phase 0 decisions automatically; it suggests, then waits for confirmation:
+
+1. Issue / Jira ID confirm
+2. **Account picker — provider-aware**: First detect the git remote provider via `git remote get-url origin`, then list provider-appropriate accounts. Do not default to `gh auth` when the remote is non-GitHub.
+   - `bitbucket.*` → Bitbucket account (parse user from remote URL: `https://USER:TOKEN@host/...`; if multiple stored tokens in OS keychain, pick from those)
+   - `github.com` → `gh auth status` accounts
+   - `gitlab.*` → GitLab account (similar URL parse / keychain)
+   - Unknown host → list all stored credentials and ask
+   - Show the chosen provider in the picker label (e.g. "Bitbucket account?" not "GitHub account?")
+3. Project root (state inheritance is FORBIDDEN — picker runs every run)
+4. dev-context picker (extra repos / submodules — read `.gitmodules` and suggest)
+5. **Network reachability gate (run before branch picker)**: Test remote with `git ls-remote --heads origin <baseBranch>` (5s timeout). One of three outcomes:
+   - **Reachable** → proceed to base branch picker, fetch latest, create worktree from `origin/<baseBranch>`
+   - **Unreachable** (DNS resolve fail / timeout) → STOP and ask the user:
+     ```
+     [N/Total] Network gate
+       Detected: <host> unreachable (VPN/DNS).
+       Options:
+         1. Enable VPN and retry (recommended — branch will be fresh)
+         2. Continue from local origin/<baseBranch> ref (may be stale)
+         3. Cancel
+       Confirm? [1/2/3]
+     ```
+   - User picks `2` → log warning + record `"baseRefFreshness": "stale"` in `agent-state.json`, proceed from local ref. Phase 6 push needs network anyway, so re-prompt VPN there if still unreachable.
+6. Base branch picker (show recents, take an explicit pick)
+7. Branch name (suggest, allow edit)
+8. Maturity flags acknowledge (read from the issue body's Progress table)
+
+### STOP-AND-CONFIRM format
+
+For each decision:
+
+```
+[N/Total] <Decision name>
+  Detected: <suggestion> [+ reason]
+  Recent: <last N values used, if any>
+  Alternatives: <other options, if any>
+
+  Confirm? [y/<number>/other/cancel]
+→ <waiting for user input — agent stays SILENT>
+```
+
+**Rules:**
+- Confirmation is required even when there is only one option
+- Empty Enter ≠ confirmation; require an explicit answer (`y`, `yes`, `1`, …)
+- State inheritance is FORBIDDEN — the previous `agent-state.json` of the same task ID is not a template
+- Cancel always halts
+- One prompt per decision — bundling is FORBIDDEN
+
+### Required commit / report prompts
+
+- Phase 6 → "Check out locally to test? 1 = Yes (WIP) / 2 = No (continue)" (default 2)
+- Phase 6 → When pushing directly to a shared branch (`iteration/develop`, `develop`, `main`), a one-line final confirm: "This pushes to iteration/develop with no CI gate. Confirm? (y/n)"
+- Phase 7 → Channels prompt: Jira comment / Confluence / PR description / (optional) Wiki — multi-select
+
+### Phase 6: PR creation contract
+
+When opening a PR, the agent must:
+
+1. **Always add default reviewers**: GET the host's default-reviewers endpoint (Bitbucket Server: `/rest/default-reviewers/1.0/projects/{projectKey}/repos/{repoSlug}/reviewers?sourceRepoId=...&targetRepoId=...&sourceRefId=...&targetRefId=...`; GitHub: `CODEOWNERS` / branch protection required reviewers). Exclude the author from the list. Attach via the create-PR payload's `reviewers` array (Bitbucket Server) or via the `review_requests` API (GitHub) at creation time.
+2. **Never wipe reviewers on update**: Bitbucket Server `PUT /pull-requests/{id}` REPLACES the entire resource. If the payload omits `reviewers`, the field is cleared. Two safe patterns:
+   - **Preferred**: do not PUT-update; pre-render the final description so the create-PR call is one-shot.
+   - **If you must PUT**: re-fetch the current PR, copy the existing `reviewers` array into the PUT payload along with `version` + the field you're changing.
+   - **Or use sub-resource endpoints**: `POST /pull-requests/{id}/participants` (Bitbucket) adds individual reviewers without touching the rest.
+3. **Verify after every PR write**: re-fetch the PR and assert `len(reviewers) >= len(defaultReviewers) - 1` (minus author). If it dropped, re-add via the participants endpoint immediately.
+4. **PR description language**: render in `prefs.global.outputLanguage`. Required sections — Summary, Changed Files, Behavior / Flow, Test Plan, Build Verification (or their localized equivalents). Match the Jira comment structure for cross-channel consistency.
+
+### Build "pre-existing" claim rule
+
+Before reporting a build failure as "pre-existing, not my problem", reproduce it on the baseline:
+
+1. `git stash push -u -m "wip-baseline-check"` (stash local changes)
+2. `git checkout <baseline-sha>` (one commit before any of yours)
+3. Run the same build command — does the failure repeat?
+4. If it repeats: pre-existing is confirmed, report it as such
+5. If it does not repeat: the bug is YOURS — return and fix it
+6. `git checkout -` and `git stash pop`
+
+No "pre-existing" claim is allowed without a baseline reproduce.
+
+## Skipped phases (definitive list)
+
+- Phase 1 (Analysis → Opus deep-think + explore agents)
+- Phase 2 → Plan Approval Gate including clarification + approval
+- Phase 4 (Review → parallel + triage)
+
+Phase 0 (Init full picker), Phase 5 (User Test), Phase 6 (Commit), and Phase 7 (Report + channels) run exactly as in the full pipeline. Phase 3 Dev model is **Opus**.
+
+## Steps
+
+1. **Parse input** — same multi-agent input formats (GitHub Issue URL, Jira ID, free-text)
+
+2. **Phase 0: Init** — same as the full pipeline (full picker: account, project, dev-context, base branch, branch name, maturity check, identity, worktree, state)
+   - Add `"mode": "dev"` to `agent-state.json`
+
+3. **Phase 3: Dev** — on the **Opus model**, with `taskType`-based dispatch:
+
+   **3a. If `state.taskType === "component"` (figma URL detected at Phase 0 Step 7):**
+   - Run the **full figma 17-substep orchestrator** — the same one the full pipeline uses. `--dev` does NOT shrink this. Sub-phases:
+     ```
+     3.0-Init → 3.1-Gather → 3.2A-TestingIDs → 3.2B-Localization → 3.2C-Accessibility → 3.2D-Analytics
+     → 3.3-TokenMapping → 3.4A-Configuration → 3.4B-View → 3.4C-Docs → 3.4D-Preview → 3.4E-Modifiers
+     → 3.5A-Structural (ViewInspector) → 3.5B-Snapshot → 3.5C-Unit
+     → 3.6-CodeConnect → 3.7-Wiki → 3.8-Cleanup
+     ```
+   - **Tests are mandatory** (3.5A + 3.5B + 3.5C). The "tests optional in dev mode" exception below applies to non-component tasks only.
+   - Code Connect publish (3.6) is mandatory if `figmaConfig.codeConnect.enabled` (default true).
+   - Wiki page generation (3.7) is mandatory if `figmaConfig.wiki.enabled`.
+
+   **3b. Else (free-text task, bug fix, refactor, generic feature):**
+   - Brief analysis (no explore agent — read files directly)
+   - Write code + verify build
+   - Write tests if needed (not mandatory in dev mode for non-component work)
+
+   The dispatch is keyed on `agent-state.taskType`, written by Phase 0 Step 7 (`feedback_phase0_tasktype.md`). If the issue body contains a Figma URL, the type is `"component"` and 3a applies — no exception, even in `--dev`.
+
+4. **Phase 5: User Test** — same as the full pipeline (interactive simulator / local-test prompt)
+
+5. **Phase 6: Commit** — same as the full pipeline (commit + push + PR + shared-branch final confirm)
+
+6. **Phase 7: Report** — same as the full pipeline (channels prompt: Jira / Confluence / PR description / Wiki)
+
+## Differences vs full pipeline
+
+| Aspect | Full (`/multi-agent`) | Dev (`/multi-agent:dev`) |
+|---------|---------------------|------------------------|
+| Phases | 8 (0-7) | 5 (0, 3, 5, 6, 7) — 1, 2, 4 skipped |
+| Phase 3 Dev model | Sonnet | **Opus** |
+| Phase 1 Analysis (explore agents) | ✅ | ❌ |
+| Phase 2 Planning + Approval Gate | ✅ | ❌ |
+| Phase 4 Review (parallel + triage) | ✅ | ❌ |
+| Phase 0 picker (account, repos, branch, …) | ✅ | ✅ (same) |
+| Phase 5 User Test | ✅ | ✅ (same) |
+| Phase 7 channels (Jira / Confluence / PR / Wiki) | ✅ | ✅ (same) |
+| Duration | ~10-15 min | ~5-7 min |
+## Required: Phase Tracker Contract
+
+**The phase tracker is mandatory** — the agent cannot skip it. Full spec: [`refs/tracker-contract.md`](./refs/tracker-contract.md).
+
+Two channels run in parallel at every phase boundary:
+
+1. **State channel** (every CLI, identical): `phase-tracker.sh` writes to `tracker-state.json`. Drives `:resume`, `:log`, `:status`.
+2. **Visual channel** (CLI-specific): native widget on Claude Code, ANSI render on every other CLI. Without it the user sees no phase progress.
+
+```bash
+# Phase 0, very first shell call (every CLI):
+bash $HOME/.claude/scripts/phase-tracker.sh init "$TASK_ID"
+for p in "0:Init" "3:Dev" "5:Test" "6:Commit" "7:Report"; do
+  bash $HOME/.claude/scripts/phase-tracker.sh add "${p%%:*}" "${p#*:}"
+done
+bash $HOME/.claude/scripts/phase-tracker.sh update 0 in_progress
+
+# Every phase boundary (every CLI):
+bash $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress|completed|failed|skipped
+
+# After every LLM call (every CLI):
+bash $HOME/.claude/scripts/phase-tracker.sh tokens <N> <in> <out>
+```
+
+### Visual channel — Claude Code (native TaskList widget, required)
+
+In Claude Code the agent MUST also drive the native TaskList widget so the user sees a sticky phase tile stack — this is the only progress signal Claude Code surfaces. Skipping these calls is the #1 source of "I don't see any phases" complaints.
+
+**TaskCreate ordering (strict)**: All TaskCreate calls fire in strict phase-number order BEFORE any TaskUpdate is applied. The native widget renders by creation order, not by phase number — out-of-order calls produce visually scrambled tile stacks (e.g. `1 ✓ · 2 ✓ · 4 ✓ · 0 ▶ · 3 ☐`) even when the underlying state is correct. Pre-marking phases as completed/skipped before Phase 0 starts is FORBIDDEN — register the tile in order, then flip status via TaskUpdate when the phase actually short-circuits. Full contract in `refs/tracker-contract.md` § "TaskCreate ordering (strict)".
+
+```text
+# Phase 0 startup — register one tile per phase (0..N), capture the taskId, persist it:
+for each phase in 0:Init, 3:Dev, 5:Test, 6:Commit, 7:Report:
+  TaskCreate({ subject: "Phase <N>: <Name>", activeForm: "<doing-form>" })
+    -> returns taskId
+  bash $HOME/.claude/scripts/phase-tracker.sh meta <N> tasklist_id "<taskId>"
+
+# Phase entry — flip the tile to in_progress alongside the state update:
+TaskUpdate({ taskId: <saved>, status: "in_progress" })
+bash $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress
+
+# Active sub-step inside a phase — update activeForm so the spinner header reflects what's happening now:
+TaskUpdate({ taskId: <saved>, activeForm: "Editing TopBarView.swift" })
+
+# Phase exit — flip to completed/failed/skipped on both channels:
+TaskUpdate({ taskId: <saved>, status: "completed" })
+bash $HOME/.claude/scripts/phase-tracker.sh update <N> completed
+```
+
+`--dev` mode does NOT TaskCreate phases 1/2/4 — those are not part of the `--dev` phase set (`0:Init 3:Dev 5:Test 6:Commit 7:Report`). Only register tiles for the active set.
+
+#### TaskCreate ordering (strict)
+
+**All TaskCreate calls fire in strict phase-number order BEFORE any TaskUpdate is applied.** For `--dev` that means: Phase 0 → Phase 3 → Phase 5 → Phase 6 → Phase 7. The native widget renders by creation order, not by phase number — out-of-order calls produce visually scrambled tile stacks. Full ordering contract in `refs/tracker-contract.md` § "TaskCreate ordering (strict)".
+
+### Visual channel — Copilot CLI / Cursor / Windsurf / plain shell
+
+These CLIs have no TaskList widget. After every state change the agent calls render, which prints a bordered ANSI card as the last tool result so the user sees an updated phase table:
+
+```bash
+bash $HOME/.claude/scripts/phase-tracker.sh render
+```
+
+Do NOT call TaskCreate on these CLIs — the tool does not exist and the call fails.

package/pipeline/commands/multi-agent/diff-explain.md

@@ -0,0 +1,68 @@
+---
+description: "Map Phase 4 triage findings to branch diff lines. Read-only post-hoc command, used after review to answer 'which finding lines up with which code change'."
+argument-hint: "[#task-id | --triage <path> | --state <path>] [--branch <name>] [--base <name>]"
+---
+
+# multi-agent diff-explain — Phase 4 Triage to Diff Bridge
+
+Maps the Phase 4 triage output (`accepted` / `deferred` / `rejected`) onto the branch's `git diff`. Every finding lands inline with the matching file / line hunk.
+
+**This command has no side effects.** It runs `git diff` and prints markdown.
+
+## When to use it
+
+- Between Phase 4 and Phase 5/6: answers "5 findings — which one belongs to which file?"
+- Phase 7 reporting: a "review summary with code context" block to embed in the Wiki / Confluence output.
+- Post-hoc audit: for a closed PR, a "what did review flag, and how did the code change" diff.
+
+## Steps
+
+1. **Resolve input** — figure out the triage source from `$ARGUMENTS`:
+   - `#N` or `JIRA-N`: pull the triage from the task's state file
+   - `--triage <path>`: triage-output.json directly
+   - `--state <path>`: agent-state.json (with embedded triage)
+   - None: use the active task
+
+2. **Pick the diff source**:
+   - `--branch <name>`: target branch (default: HEAD)
+   - `--base <name>`: comparison base (default: origin/main → main)
+   - `--diff <path>`: precomputed diff (skips the git call; for CI / sandboxes)
+
+3. **Run the script** and show the output directly to the user:
+   ```bash
+   node "$HOME/.claude/scripts/diff-explain.mjs" \
+     --triage "<resolved-path>" \
+     --branch "<branch>" \
+     --base "<base>"
+   ```
+
+4. **Annotate the output** (optional):
+   - Whether every blocking finding actually got touched (Phase 3 fix-coverage check)
+   - Whether every deferred finding is on the Phase 7 follow-up list
+
+## Output template
+
+```markdown
+# Phase 4 Triage Diff Bridge
+
+## Summary
+- Accepted: 3 (🚫 1 blocking · ⚠️ 1 important · 💡 1 suggestion)
+- Deferred: 1 · Rejected: 0
+- Approved: ❌ no
+
+## src/api/checkout.ts
+
+### ✅ 🚫 BLOCKING — line 102 (opus)
+> Race condition: order total computed twice without lock
+**Fix:** Compute total once inside the existing transaction block
+```diff
+@@ -98,5 +98,7 @@ ...
+   const total = sum(items);
++  const total2 = sum(items);  // duplicate
+   await chargeCard(total);
+```
+```
+
+Icons:
+- Bucket: ✅ accepted · ⏭️ deferred · ❌ rejected
+- Severity: 🚫 blocking · ⚠️ important · 💡 suggestion