@mmerterden/multi-agent-pipeline 8.6.1 → 10.0.6

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

@@ -1,8 +1,8 @@
 ---
-description: "Fastest mode: Dev (Opus) plus Autopilot. Init → Dev → Commit → Report with zero confirmations."
+description: "Fastest mode: Dev (Fable) plus Autopilot. Init → Dev → Commit → Report with zero confirmations."
 ---
 
-# multi-agent dev autopilot — Fastest Path
+# multi-agent dev autopilot  -  Fastest Path
 
 **Input**: $ARGUMENTS
 
@@ -19,7 +19,7 @@ Dev mode + Autopilot combined: a 4-phase pipeline with no confirmations, end-to-
 
 ```
 Phase 0: Init       → project detection, worktree, branch, identity
-Phase 3: Dev        → direct development on Opus
+Phase 3: Dev        → direct development on Fable
 Phase 6: Commit     → auto commit + push + PR (no confirmations)
 Phase 7: Report     → short terminal summary
 ```
@@ -27,15 +27,15 @@ 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."
+> 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
+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
 
@@ -47,16 +47,16 @@ Phase 7: Report     → short terminal summary
 | | Full | Dev | Autopilot | **Dev+Autopilot** |
 |--|------|-----|-----------|-------------------|
 | Phases | 8 | 4 | 8 | **4** |
-| Model | Sonnet | Opus | Sonnet | **Opus** |
+| Model | Sonnet | Fable | Sonnet | **Fable** |
 | 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).
+**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`.
+> **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:
 
@@ -78,38 +78,38 @@ bash $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress|completed|fai
 bash $HOME/.claude/scripts/phase-tracker.sh tokens <N> <in> <out>
 ```
 
-### Visual channel — Claude Code (native TaskList widget, required)
+### 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.
+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)".
+**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` section "TaskCreate ordering (strict)".
 
 ```text
-# Phase 0 startup — register one tile per phase (0..N), capture the taskId, persist it:
+# 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:
+# 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:
+# 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:
+# 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.
+`--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)".
+**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` section "TaskCreate ordering (strict)".
 
-### Visual channel — Copilot CLI / Cursor / Windsurf / plain shell
+### 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:
 
@@ -117,4 +117,4 @@ These CLIs have no TaskList widget. After every state change the agent calls ren
 bash $HOME/.claude/scripts/phase-tracker.sh render
 ```
 
-Do NOT call TaskCreate on these CLIs — the tool does not exist and the call fails.
+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

@@ -1,19 +1,19 @@
 ---
-description: "Fastest + local — Dev(Opus) + autopilot, no worktree, zero interaction."
+description: "Fastest + local  -  Dev(Fable) + 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
+# 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.
+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 3: Dev        → direct development on Fable (automatic)
 Phase 6: Commit     → auto commit + push + PR (no local checkout prompt)
 Phase 7: Report     → Jira / Wiki + log + knowledge/memory
 ```
@@ -21,14 +21,14 @@ 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
+- 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
+- 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
 
@@ -42,11 +42,11 @@ Routes to the orchestrator with `--dev --local autopilot` flags. The pipeline co
 ```
 ## Required: Phase Tracker Contract
 
-**The phase tracker is mandatory** — the agent cannot skip it. Full spec: [`refs/tracker-contract.md`](./refs/tracker-contract.md).
+**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`.
+> **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.
+> **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:
 
@@ -68,38 +68,38 @@ bash $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress|completed|fai
 bash $HOME/.claude/scripts/phase-tracker.sh tokens <N> <in> <out>
 ```
 
-### Visual channel — Claude Code (native TaskList widget, required)
+### 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.
+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)".
+**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` section "TaskCreate ordering (strict)".
 
 ```text
-# Phase 0 startup — register one tile per phase (0..N), capture the taskId, persist it:
+# 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:
+# 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:
+# 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:
+# 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.
+`--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)".
+**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` section "TaskCreate ordering (strict)".
 
-### Visual channel — Copilot CLI / Cursor / Windsurf / plain shell
+### 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:
 
@@ -107,4 +107,4 @@ These CLIs have no TaskList widget. After every state change the agent calls ren
 bash $HOME/.claude/scripts/phase-tracker.sh render
 ```
 
-Do NOT call TaskCreate on these CLIs — the tool does not exist and the call fails.
+Do NOT call TaskCreate on these CLIs  -  the tool does not exist and the call fails.

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

@@ -1,33 +1,35 @@
 ---
-description: "Fast mode + local — Init → Dev(Opus) → Commit → Report, no worktree."
+description: "Fast mode + local  -  Init → Dev(Fable) → 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
+# 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.
+Dedicated form of the `--dev` + `--local` combination. A 4-phase fast pipeline (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 3: Dev        → direct development on Fable (Analysis + Planning + Review skipped)
 Phase 6: Commit     → pre-commit checkout prompt, commit + push + PR
 Phase 7: Report     → Jira / Wiki + log + knowledge/memory
 ```
 
+`--dev local` skips Phase 1 (Analysis), Phase 2 (Planning + Approval Gate), Phase 4 (Review), and Phase 5 (User Test  -  local/autopilot variants skip the interactive test gate). It differs from `--dev` on two axes: no git worktree is created (development happens directly on the current branch in `$PROJECT_ROOT`), and the interactive User Test phase is skipped.
+
 ## When to use it
 
-- Quick bug fix or small feature — review overhead is unnecessary
+- 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
+- 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).
+**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.
+> **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:
 
@@ -49,38 +51,38 @@ bash $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress|completed|fai
 bash $HOME/.claude/scripts/phase-tracker.sh tokens <N> <in> <out>
 ```
 
-### Visual channel — Claude Code (native TaskList widget, required)
+### 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.
+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)".
+**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` section "TaskCreate ordering (strict)".
 
 ```text
-# Phase 0 startup — register one tile per phase (0..N), capture the taskId, persist it:
+# 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:
+# 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:
+# 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:
+# 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.
+`--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)".
+**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` section "TaskCreate ordering (strict)".
 
-### Visual channel — Copilot CLI / Cursor / Windsurf / plain shell
+### 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:
 
@@ -88,14 +90,15 @@ These CLIs have no TaskList widget. After every state change the agent calls ren
 bash $HOME/.claude/scripts/phase-tracker.sh render
 ```
 
-Do NOT call TaskCreate on these CLIs — the tool does not exist and the call fails.
+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)
+- Phase 1 (Analysis), Phase 2 (Planning + Approval Gate), Phase 4 (Review), and Phase 5 (User Test) are skipped (`--dev` + local/autopilot drop the interactive test gate)
+- Phase 3: develop on Fable (instead of the Sonnet TDD cycle)
+- Phase 6: commit + push + PR (the local checkout prompt is natural in local mode  -  you're already there; no worktree removal needed, code is already in `$PROJECT_ROOT`)
+- Phase 7: report + channels (same as `--dev`)
 
 ## Examples
 

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

@@ -1,26 +1,26 @@
 ---
-description: "Fast development mode: Init → Dev (Opus) → Test → Commit → Report. Analysis, planning, and review phases are skipped."
+description: "Fast development mode: Init → Dev (Fable) → Test → Commit → Report. Analysis, planning, and review phases are skipped."
 ---
 
-# multi-agent dev — Fast Development Mode (--dev)
+# 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.
+> 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/`, …)
+>   - Branch names (`feature/`, `bugfix/`, ...)
 >   - Code identifiers, file paths, log lines
->   - PR title prefix (`feat:`, `fix:`, …) — only the body honors `outputLanguage`
+>   - 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.
+A 5-phase fast pipeline: Init → Dev → Test → Commit → Report. Development runs on the Fable model (top intelligence tier).
 
 ## When to use it
 - Small changes, bug fixes, quick features
@@ -31,31 +31,31 @@ A 5-phase fast pipeline: Init → Dev → Test → Commit → Report. Developmen
 
 ```
 Phase 0: Init       → project detection, worktree, branch, identity (full picker)
-Phase 3: Dev        → direct development on Opus (TDD optional)
+Phase 3: Dev        → direct development on Fable (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.
+`--dev` skips Phase 1 (Analysis), Phase 2 (Planning + Approval Gate), and Phase 4 (Review). Phase 3 Dev runs on **Fable**. 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.
+`--dev` skips the LLM-heavy phases (Phase 1 Analysis, Phase 2 Planning + Approval, Phase 4 Review) and runs Phase 3 Dev on Fable. 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.
+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)
+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:
@@ -63,7 +63,7 @@ The agent CANNOT make these Phase 0 decisions automatically; it suggests, then w
      [N/Total] Network gate
        Detected: <host> unreachable (VPN/DNS).
        Options:
-         1. Enable VPN and retry (recommended — branch will be fresh)
+         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]
@@ -84,21 +84,21 @@ For each decision:
   Alternatives: <other options, if any>
 
   Confirm? [y/<number>/other/cancel]
-→ <waiting for user input — agent stays SILENT>
+→ <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
+- 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
+- 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 → When pushing directly to a shared branch (`iteration/develop`, `develop`, `main`), a final confirm via a native `AskUserQuestion` picker (never a typed y/n): `question` "This pushes to iteration/develop with no CI gate. Push anyway?" (rendered in `outputLanguage`); `header` "Push" (English, <=12 chars); `options`: `{ label: "Push", description: "Push directly to the shared branch with no CI gate" }`, `{ label: "Cancel", description: "Do not push; stop here" }`. Anything other than **Push** cancels.
+- Phase 7 → Channels prompt: Jira comment / Confluence / PR description / (optional) Wiki  -  multi-select
 
 ### Phase 6: PR creation contract
 
@@ -110,7 +110,7 @@ When opening a PR, the agent must:
    - **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.
+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
 
@@ -118,32 +118,32 @@ Before reporting a build failure as "pre-existing, not my problem", reproduce it
 
 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?
+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
+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 1 (Analysis → Fable 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**.
+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 **Fable**.
 
 ## Steps
 
-1. **Parse input** — same multi-agent input formats (GitHub Issue URL, Jira ID, free-text)
+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)
+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:
+3. **Phase 3: Dev**  -  on the **Fable 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:
+   - 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
@@ -155,34 +155,34 @@ Phase 0 (Init full picker), Phase 5 (User Test), Phase 6 (Commit), and Phase 7 (
    - 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)
+   - 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`.
+   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)
+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)
+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)
+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** |
+| Phases | 8 (0-7) | 5 (0, 3, 5, 6, 7)  -  1, 2, 4 skipped |
+| Phase 3 Dev model | Sonnet | **Fable** |
 | Phase 1 Analysis (explore agents) | ✅ | ❌ |
 | Phase 2 Planning + Approval Gate | ✅ | ❌ |
 | Phase 4 Review (parallel + triage) | ✅ | ❌ |
-| Phase 0 picker (account, repos, branch, …) | ✅ | ✅ (same) |
+| 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).
+**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:
 
@@ -204,38 +204,38 @@ bash $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress|completed|fai
 bash $HOME/.claude/scripts/phase-tracker.sh tokens <N> <in> <out>
 ```
 
-### Visual channel — Claude Code (native TaskList widget, required)
+### 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.
+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)".
+**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` section "TaskCreate ordering (strict)".
 
 ```text
-# Phase 0 startup — register one tile per phase (0..N), capture the taskId, persist it:
+# 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:
+# 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:
+# 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:
+# 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.
+`--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)".
+**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` section "TaskCreate ordering (strict)".
 
-### Visual channel — Copilot CLI / Cursor / Windsurf / plain shell
+### 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:
 
@@ -243,4 +243,4 @@ These CLIs have no TaskList widget. After every state change the agent calls ren
 bash $HOME/.claude/scripts/phase-tracker.sh render
 ```
 
-Do NOT call TaskCreate on these CLIs — the tool does not exist and the call fails.
+Do NOT call TaskCreate on these CLIs  -  the tool does not exist and the call fails.