@mmerterden/multi-agent-pipeline 17.6.0 → 19.0.0

package/pipeline/skills/shared/core/multi-agent-help/SKILL.md

@@ -59,30 +59,31 @@ How It Works (Phase 0  -  Interactive Flow):
 Pipeline (after Phase 0):
 
   Phase 0: Init      -> The 8 steps above
-  Phase 1: Analysis  -> Stack detection + codebase scan (Sonnet)
-  Phase 2: Planning  -> Task breakdown + architecture review + Plan Approval Gate
-  Phase 3: Dev       -> TDD: test -> code -> build (Sonnet) + build queue
-  Phase 4: Review    -> Deterministic gates + parallel AI review + Fable triage
+  Phase 1: Plan      -> Stack detection + codebase scan, then task breakdown,
+                        architecture review and the Plan Approval Gate (Opus)
+  Phase 2: Dev       -> TDD: test -> code -> build (Sonnet) + build queue, then the
+                        Verify exit gate: build, lint, tests, secrets
+                        (the build runs ONCE per run; its log carries into Review)
+  Phase 3: Review    -> Parallel AI review + Fable triage, then the optional user test
                         (Claude Code: Fable + Opus + Sonnet · Copilot CLI: GPT-5.4 + Opus + Sonnet)
-  Phase 5: Test      -> Optional: switch to branch, test in Xcode
-  Phase 6: Commit    -> Commit -> push -> PR + issue body update (never auto-closes)
-  Phase 7: Report    -> Channels dispatcher (PR · Jira · Confluence · Wiki, multi-select)
+  Phase 4: Commit    -> Commit -> push -> PR + issue body update (never auto-closes)
+  Phase 5: Report    -> Channels dispatcher (PR · Jira · Confluence · Wiki, multi-select)
                         + internal capture (agent-log · knowledge · memory)
 
-  Autopilot always pauses at the Phase 7 channels menu (30-min timeout → session ends).
+  Autopilot always pauses at the Phase 5 channels menu (30-min timeout → session ends).
 
 ------------------------------------------------------------
 
 Modes:
 
   Depth is asked at Phase 0 Step 7.5, not passed as a flag:
-    Full   Analysis -> Plan -> Dev(Sonnet) -> Review -> Test -> Commit -> Report
-    Short  Dev(Opus, self-contained) -> Review -> Test -> Commit -> Report
+    Full   Plan -> Dev(Sonnet) -> Review -> Commit -> Report
+    Short  Dev(Opus, self-contained) -> Review -> Commit -> Report
   Recommended from taskType. Review is never skipped either way.
 
   --local              No worktree  -  works directly on local branch
   autopilot            Skip all confirmations, including the depth question, so
-                       it always runs Full (EXCEPT Phase 7 channels menu)
+                       it always runs Full (EXCEPT Phase 5 channels menu)
 
 Dedicated dash commands (Copilot):
   multi-agent-local, multi-agent-autopilot, multi-agent-local-autopilot
@@ -147,7 +148,7 @@ UI Testing (standalone):
   and lives at /multi-agent:store-ready. The old /multi-agent:test "store-ready"
   tag still works and hands off there.
 
-Manual Test (Phase 5 standalone  -  Xcode hint flow):
+Manual Test (Phase 3 user-test step, standalone  -  Xcode hint flow):
 
   /multi-agent:manual-test [#N]      Checkout task branch, print Xcode/SourceTree hints.
                                      (Renamed from :test in v5.7.4.)
@@ -232,30 +233,31 @@ Nasıl Çalışır (Phase 0  -  İnteraktif Akış):
 Pipeline (Phase 0'dan sonra):
 
   Phase 0: Init      -> Yukarıdaki 8 adım
-  Phase 1: Analysis  -> Stack tespiti + codebase taraması (Sonnet)
-  Phase 2: Planning  -> Task kırılımı + mimari inceleme + Plan Onay Kapısı
-  Phase 3: Dev       -> TDD: test -> kod -> build (Sonnet) + build queue
-  Phase 4: Review    -> Deterministik kapılar + paralel AI review + Fable triage
+  Phase 1: Plan      -> Stack tespiti + codebase taraması, ardından task kırılımı,
+                        mimari inceleme ve Plan Onay Kapısı (Opus)
+  Phase 2: Dev       -> TDD: test -> kod -> build (Sonnet) + build queue, sonra
+                        Verify çıkış kapısı: build, lint, test, sır taraması
+                        (build koşu başına BİR kez çalışır, log'u Review'a devreder)
+  Phase 3: Review    -> Paralel AI review + Fable triage, sonra opsiyonel kullanıcı testi
                         (Claude Code: Fable + Opus + Sonnet · Copilot CLI: GPT-5.4 + Opus + Sonnet)
-  Phase 5: Test      -> Opsiyonel: branch'e geç, Xcode'da test
-  Phase 6: Commit    -> Commit -> push -> PR + issue body güncelleme (hiç auto-close yok)
-  Phase 7: Report    -> Channels dispatcher (PR · Jira · Confluence · Wiki, multi-select)
+  Phase 4: Commit    -> Commit -> push -> PR + issue body güncelleme (hiç auto-close yok)
+  Phase 5: Report    -> Channels dispatcher (PR · Jira · Confluence · Wiki, multi-select)
                         + internal capture (agent-log · knowledge · memory)
 
-  Autopilot Phase 7 channels menüsünde HER ZAMAN durur (30 dk timeout → session biter).
+  Autopilot Phase 5 channels menüsünde HER ZAMAN durur (30 dk timeout → session biter).
 
 ------------------------------------------------------------
 
 Modlar:
 
   Derinlik Faz 0 Adım 7.5'te sorulur, bayrakla geçilmez:
-    Tam    Analiz -> Plan -> Dev(Sonnet) -> Review -> Test -> Commit -> Report
-    Kısa   Dev(Opus, kendi kendine yeten) -> Review -> Test -> Commit -> Report
+    Tam    Plan -> Dev(Sonnet) -> Review -> Commit -> Report
+    Kısa   Dev(Opus, kendi kendine yeten) -> Review -> Commit -> Report
   taskType'a göre önerilir. Review iki durumda da atlanmaz.
 
   --local              Worktree yok  -  doğrudan local branch'te çalışır
   autopilot            Derinlik sorusu dahil tüm onayları atlar, bu yüzden her
-                       zaman Tam koşar (İSTİSNA: Phase 7 channels menüsü)
+                       zaman Tam koşar (İSTİSNA: Phase 5 channels menüsü)
 
 Dedicated dash komutlar (Copilot):
   multi-agent-local, multi-agent-autopilot, multi-agent-local-autopilot

package/pipeline/skills/shared/core/multi-agent-language/SKILL.md

@@ -14,7 +14,7 @@ Two-axis language preference for the pipeline:
 
 | Field | Controls | Stored at | Mutability |
 |---|---|---|---|
-| `promptLanguage` | Interactive prompts during a pipeline run (account picker, project picker, dev-context picker, base-branch picker, branch-name picker, maturity ack, channels picker, Phase 5 test prompt, Phase 6 local-checkout prompt) | `prefs.global.promptLanguage` | **Fixed to `en`**  -  never toggled by this skill |
+| `promptLanguage` | Interactive prompts during a pipeline run (account picker, project picker, dev-context picker, base-branch picker, branch-name picker, maturity ack, channels picker, Phase 3 test prompt, Phase 4 local-checkout prompt) | `prefs.global.promptLanguage` | **Fixed to `en`**  -  never toggled by this skill |
 | `outputLanguage` | Assistant's explanations, status updates, error messages, and pipeline-generated reports rendered to the user (NOT external payloads) | `prefs.global.outputLanguage` | Toggled by this skill |
 
 **Why promptLanguage is fixed:** it governs the picker's structural chrome only  -  the `AskUserQuestion` `header` chip, host error UI, and internal contract identifiers. The chip stays English because it is capped at 12 characters and most Turkish equivalents overflow it. Everything a user actually reads follows `outputLanguage`: the picker `question`, each option's `label`, and each option's `description`, per the canonical per-field matrix in `multi-agent-refs/rules.md`. A picker whose question or buttons are English on a Turkish run is a bug, not the contract. The host's own **Other** row is injected by the CLI and stays English on every run; nothing in the pipeline can localize it.
@@ -83,5 +83,5 @@ Render in the new outputLanguage:
 
 - `multi-agent-setup`  -  first-run language picker (asks only outputLanguage; promptLanguage seeded as `en`)
 - `prefs.schema.json`  -  `global.promptLanguage` (fixed `"en"`) and `global.outputLanguage`
-- Phase 5 / Phase 6  -  interactive prompts follow the per-field matrix: `question` + `label` + `description` in `outputLanguage`, `header` English
+- Phase 5 / Phase 4  -  interactive prompts follow the per-field matrix: `question` + `label` + `description` in `outputLanguage`, `header` English
 - `multi-agent-help`  -  reads outputLanguage for its own copy

package/pipeline/skills/shared/core/multi-agent-local/SKILL.md

@@ -7,7 +7,7 @@ user-invocable: true
 
 # multi-agent local  -  Full Pipeline, Local Branch
 
-Runs the full 8-phase pipeline (normal mode  -  including the Plan Approval Gate + parallel review + triage) on the current branch **without creating a worktree**. The dedicated equivalent of the `multi-agent "task" --local` flag form.
+Runs the full 6-phase pipeline (normal mode  -  including the Plan Approval Gate + parallel review + triage) on the current branch **without creating a worktree**. The dedicated equivalent of the `multi-agent "task" --local` flag form.
 
 ## When to use it
 
@@ -22,7 +22,7 @@ Runs the full 8-phase pipeline (normal mode  -  including the Plan Approval Gate
 
 ## Pipeline
 
-The same 8 phases as the normal pipeline: Init → Analysis → Planning → Dev → Review → Test → Commit → Report. Only Phase 0 Step 8 (workspace creation) continues on the current branch instead of a worktree; the `state.projects[*].worktreePath` field stays `null`.
+The same 6 phases as the normal pipeline: Init → Analysis → Planning → Dev → Review → Test → Commit → Report. Only Phase 0 Step 8 (workspace creation) continues on the current branch instead of a worktree; the `state.projects[*].worktreePath` field stays `null`.
 
 ## Delegation
 

package/pipeline/skills/shared/core/multi-agent-local-autopilot/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: multi-agent-local-autopilot
 language: en
-description: "Full pipeline + local + autopilot  -  no worktree, no confirmations, all 8 phases run end-to-end on the current branch. Use when the full pipeline should run on the current branch with no worktree and no prompts."
+description: "Full pipeline + local + autopilot  -  no worktree, no confirmations, all 6 phases run end-to-end on the current branch. Use when the full pipeline should run on the current branch with no worktree and no prompts."
 user-invocable: true
 argument-hint: '"task"  -  issue URL, Jira ID, free-text, or #id (for resume)'
 ---
@@ -10,16 +10,16 @@ argument-hint: '"task"  -  issue URL, Jira ID, free-text, or #id (for resume)'
 
 **Input**: $ARGUMENTS
 
-Runs the full 8-phase pipeline **without creating a worktree** + **skipping all confirmations**. The `autopilot + local` combination. Byte-identical behavior to `/multi-agent:local-autopilot` (Claude Code colon-form).
+Runs the full 6-phase pipeline **without creating a worktree** + **skipping all confirmations**. The `autopilot + local` combination. Byte-identical behavior to `/multi-agent:local-autopilot` (Claude Code colon-form).
 
 ## Matrix (which one should I use?)
 
 | Command | Pipeline | Worktree | Confirmation |
 |---|---|---|---|
-| `multi-agent "task"` | Full 8 phases | ✅ | ✅ (interactive) |
-| `multi-agent-autopilot "task"` | Full 8 phases | ✅ | ❌ |
-| `multi-agent-local "task"` | Full 8 phases | ❌ | ✅ |
-| **`multi-agent-local-autopilot "task"`** | **Full 8 phases** | **❌** | **❌** |
+| `multi-agent "task"` | Full 6 phases | ✅ | ✅ (interactive) |
+| `multi-agent-autopilot "task"` | Full 6 phases | ✅ | ❌ |
+| `multi-agent-local "task"` | Full 6 phases | ❌ | ✅ |
+| **`multi-agent-local-autopilot "task"`** | **Full 6 phases** | **❌** | **❌** |
 
 Depth is a separate axis, asked at Phase 0 Step 7.5 rather than encoded in the command name: Full runs every phase above, Short runs Dev → Review → Test → Commit → Report. The two autopilot rows never ask and always run Full.
 
@@ -27,7 +27,7 @@ Depth is a separate axis, asked at Phase 0 Step 7.5 rather than encoded in the c
 
 - The Phase 0 Step 6 worktree step is skipped (local contract)
 - The Phase 2 Plan Approval Gate is skipped (autopilot contract)  -  `state.autopilot === true`
-- The Phase 5 test prompt is skipped, Phase 6 commit/PR does not wait for confirmation
+- The Phase 3 test prompt is skipped, Phase 4 commit/PR does not wait for confirmation
 - **v7.0.0+**: The Phase 2 safety classifier (`classify-plan-safety.mjs`) always runs; if the score is ≥ 50 it asks for a single manual confirmation even in autopilot (`prefs.global.autopilotSafetyGate`, default on)
 
 ## What is NEVER skipped
@@ -48,7 +48,7 @@ multi-agent-local-autopilot "#3"
 
 ## Delegation
 
-The orchestrator skill (`multi-agent/SKILL.md`) takes the `--local` + `"autopilot": true` state flags together. Contract: `refs/phases/phase-0-init.md` Step 6 (local branch) + `refs/phases/phase-2-planning.md` Step 5 (gate skip) + Step 5c (safety classifier, v7.0.0+).
+The orchestrator skill (`multi-agent/SKILL.md`) takes the `--local` + `"autopilot": true` state flags together. Contract: `refs/phases/phase-0-init.md` Step 6 (local branch) + `refs/phases/phase-1-plan.md` Step 5 (gate skip) + Step 5c (safety classifier, v7.0.0+).
 
 ## Required: outward-facing payload contracts
 

package/pipeline/skills/shared/core/multi-agent-manual-test/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: multi-agent-manual-test
 language: en
-description: "Switch to the active task's branch and prepare it for manual testing in Xcode. Phase 5 standalone (the UI Bug Hunter lives at multi-agent-test). Use when a finished change needs trying by hand on a device or simulator."
+description: "Switch to the active task's branch and prepare it for manual testing in Xcode. Phase 3 user-test step, standalone (the UI Bug Hunter lives at multi-agent-test). Use when a finished change needs trying by hand on a device or simulator."
 user-invocable: true
 argument-hint: "[#id]  -  optional: task ID. Defaults to the latest task if omitted"
 ---
 
-# multi-agent manual-test  -  Phase 5 Manual Test Mode
+# multi-agent manual-test  -  Phase 3 Manual Test Mode
 
 **Input**: $ARGUMENTS
 
@@ -16,8 +16,8 @@ Lets you switch to the task branch for manual testing in Xcode before the PR is
 
 1. **Find the task**  -  parse `#N` from the argument or find the most recent task
 
-2. **Check the state**  -  the task must have completed Phase 3+
-   - Phase < 3 → "No code has been written yet, run `resume #N` first"
+2. **Check the state**  -  the task must have completed Phase 2 (Dev) or later
+   - Phase < 2 → "No code has been written yet, run `resume #N` first"
 
 3. **Remove the worktree and switch to the branch**:
    ```bash
@@ -36,7 +36,7 @@ Lets you switch to the task branch for manual testing in Xcode before the PR is
      • Manual test in the Simulator
 
    Result:
-     ✅ "ok" → proceeds to Phase 6 (commit)
+     ✅ "ok" → proceeds to Phase 4 (commit)
      ❌ "fix: ..." → the worktree is recreated and the fix is applied
    ```
 
@@ -52,5 +52,5 @@ Lets you switch to the task branch for manual testing in Xcode before the PR is
      node $HOME/.claude/scripts/evidence-gate.mjs --claim manual --status passed \
        --evidence "$WORKTREE/.pipeline/manual-test.json"
      ```
-     Exit 1 means the "ok" is not accepted: name the criterion that lacks evidence and wait for the next reply. Exit 0 → recreate the worktree, proceed to Phase 6. Full contract: `$HOME/.claude/multi-agent-refs/phases/phase-5-test.md` step 5.
+     Exit 1 means the "ok" is not accepted: name the criterion that lacks evidence and wait for the next reply. Exit 0 → recreate the worktree, proceed to Phase 4. Full contract: `$HOME/.claude/multi-agent-refs/phases/phase-3-review.md` step 5.
    - **Fix needed** → recreate the worktree, apply the fix

package/pipeline/skills/shared/core/multi-agent-model/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: multi-agent-model
+language: en
+description: "Turn the top model rung on or off and keep the cost ledger's pricing in step with it. Use when asked to enable or disable Fable, or which model the pipeline dispatches."
+user-invocable: true
+argument-hint: "[on | off]  -  no argument reports the current state"
+---
+
+# multi-agent model  -  which rung the pipeline dispatches on
+
+The ladder is `fable -> opus -> sonnet -> haiku` and it does not change here.
+What changes is whether the top rung is in play at all, which is
+`prefs.global.modelFallback.fableEnabled` and ships `false`.
+
+```bash
+bash "$HOME/.claude/lib/model-rung.sh" ${ARGUMENTS}
+```
+
+## Why this command exists
+
+The switch existed before the command did. It could only be flipped by editing
+preferences by hand, and `model-fallback.md` said so in a line most people never
+reached. That is a knob with no handle.
+
+It also never travelled alone. `prefs.global.costBudget.pricingModel` defaults to
+`fable` so the estimate stays an upper bound; with the rung off, that default
+prices every call above what it can cost, trips the budget ceiling early, and
+triggers a downgrade nobody needed. The documentation asked the user to set both.
+This command sets both, together:
+
+| `fableEnabled` | `costBudget.pricingModel` |
+|---|---|
+| `true` | `fable` |
+| `false` | `opus` |
+
+Flipping one without the other is the defect this closes, so the pair moves as
+one write or not at all.
+
+## What it reports with no argument
+
+The current rung, the pricing model, and **what the switch means on this host** -
+because it does not mean the same thing on all three:
+
+| Host | What `off` does | Why |
+|---|---|---|
+| Claude Code | every `preferredModel: fable` persona (architects, reviewer 1, triage) starts on `opus` | the only host where the rung is Fable 5 |
+| Copilot CLI | nothing | Fable 5 is not offered there; its personas never sat on this rung |
+| Codex CLI | nothing, deliberately | the `fable` rung there means `gpt-5.6 @ xhigh`, a different model on a different account - switching it from a knob named after an Anthropic model would surprise a Codex user |
+
+So on two of the three hosts this command is a **status report**, not a switch,
+and it says which one it is rather than claiming a change it did not make.
+
+## The consequence it prints when turning the rung off
+
+Phase 3's reviewer panel collapses from three models to two. Reviewer 1 lands on
+`opus`, which Reviewer 2 already holds, and dispatching one model twice is not
+cross-model review. `consensus.reviewerCount` records `2`, and the `unverified`
+verdict rule matters more rather than less - two Anthropic models agreeing on a
+judgment call was already weak evidence and there is now one fewer of them.
+Triage also runs on `opus`, making it the same model as Reviewer 1; the Phase 3
+Step 3 anonymisation requirement covers that case and is not optional here.
+
+This is printed at the moment of the change, not left in a doc.
+
+## Related
+
+- `/multi-agent:route-on` - policy-driven rung selection per persona or phase, a
+  separate feature that also ships off. This command decides whether a rung
+  EXISTS; that one decides which rung a given call picks.
+- Full fallback contract, including the three failure triggers this switch is
+  deliberately not one of: `$HOME/.claude/multi-agent-refs/features/model-fallback.md`

package/pipeline/skills/shared/core/multi-agent-refactor/SKILL.md

@@ -112,7 +112,7 @@ Procedure:
 
 ## Step 0c: DEV-TOOLKIT  -  current MCP practice for the companion toolkit
 
-The pipeline's hands on devices and browsers are MCP tools served by a companion repo (`multi-agent-toolkit-mcp`): Phase 5 test, `manual-test`, `design-check` and `apple-archive-compliance` all call them, and several pipeline skills declare a minimum toolkit version (see `cross-cli-contract.md`). That repo therefore has to track the MCP field, not just its own README. This step researches what current practice is and audits the toolkit against it.
+The pipeline's hands on devices and browsers are MCP tools served by a companion repo (`multi-agent-toolkit-mcp`): Phase 3 test, `manual-test`, `design-check` and `apple-archive-compliance` all call them, and several pipeline skills declare a minimum toolkit version (see `cross-cli-contract.md`). That repo therefore has to track the MCP field, not just its own README. This step researches what current practice is and audits the toolkit against it.
 
 Full procedure  -  resolution (configuration first, never a hardcoded path; skip when nothing resolves or `enabled` is false), the 5 research axes, the audit command block, and the band-E output table + rules  -  lives in `$HOME/.claude/multi-agent-refs/refactor/toolkit-research.md`. Read it before running this step.
 
@@ -147,8 +147,8 @@ Output (plan band F):
 ```
 | # | Error tag | Occurrences | Users | Usual phase | Versions | Root cause (file) | Fix | In plan? |
 |---|-----------|-------------|-------|-------------|----------|-------------------|-----|----------|
-| 1 | 4:reviewer-json-invalid | 12 | 3 | 4 | 14.x-15.x | reviewer prompt lets prose leak | tighten schema instruction in phase-4-review.md | Yes (P0) |
-| 2 | phase-3-failed | 5 | 2 | 3 | 15.0.x | build step misses a stack toolchain | add preflight in phase-3-dev.md | Yes (P1) |
+| 1 | 4:reviewer-json-invalid | 12 | 3 | 4 | 14.x-15.x | reviewer prompt lets prose leak | tighten schema instruction in phase-3-review.md | Yes (P0) |
+| 2 | phase-3-failed | 5 | 2 | 3 | 15.0.x | build step misses a stack toolchain | add preflight in phase-2-dev.md | Yes (P1) |
 ```
 
 Rules for this band:

package/pipeline/skills/shared/core/multi-agent-resume/SKILL.md

@@ -23,7 +23,7 @@ Resume a paused or failed task from the last successful phase.
 
 3. **Load context**  -  Read the findings of previous phases from `agent-log.md`:
    - Phase 1 analysis → use in Phase 2+
-   - Phase 2 plan → use in Phase 3+
+   - Phase 1 plan → use in Phase 2+
    - Phase 3 code → already present in the worktree
 
 4. **Continue the pipeline**  -  Start from where it left off (same pipeline as the main multi-agent command)

package/pipeline/skills/shared/core/multi-agent-resume-local/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: multi-agent-resume-local
 language: en
-description: "Continue already-done LOCAL work through the pipeline tail: Review → Build+Test → Commit/PR → Report (technical analysis + Jira test-scenario comment). No dev phase. Use when local work is already done and only review, build, commit and reporting remain."
+description: "Continue already-done LOCAL work through the pipeline tail: Review (with its build gate) → Commit/PR → Report (technical analysis + Jira test-scenario comment). No dev phase. Use when local work is already done and only review, build, commit and reporting remain."
 user-invocable: true
 ---
 
@@ -13,13 +13,13 @@ You already wrote (and maybe hand-tested) the change on the current branch, or c
 
 ```
 Phase 0: Init          → project/branch detect, resolve base + diff (work already done), Jira id, state (NO worktree)
-Phase 4: Review        → deterministic gates + parallel review + Fable triage
-Phase 5: Build+Test    → stack-aware build + run existing tests; SUCCESS required (automated gate, not the interactive user-test)
-Phase 6: Commit        → commit remaining changes + push + open PR if none exists
-Phase 7: Report        → technical analysis + Jira comment with test scenarios (channels: Jira / PR / Confluence / Wiki)
+Phase 3: Review        → the Verify gate first (stack-aware build + existing tests; SUCCESS required), then
+                         parallel review (Fable + Opus + Sonnet) + Fable triage
+Phase 4: Commit        → commit remaining changes + push + open PR if none exists
+Phase 5: Report        → technical analysis + Jira comment with test scenarios (channels: Jira / PR / Confluence / Wiki)
 ```
 
-Phases 1-3 (Analysis / Planning / Dev) are skipped by design  -  the branch's local diff IS the input.
+Phases 1-2 (Plan / Dev) are skipped by design  -  the branch's local diff IS the Phase 2 output. The build that Dev's exit gate would have run happens inside Review instead, because there is no Dev run to inherit a log from.
 
 ## When to use it
 
@@ -35,7 +35,7 @@ Phases 1-3 (Analysis / Planning / Dev) are skipped by design  -  the branch's lo
 
 ```bash
 multi-agent resume-local                   # current branch vs base; Jira id from branch name
-multi-agent resume-local PROJ-12345      # explicit Jira id for the Phase 7 comment
+multi-agent resume-local PROJ-12345      # explicit Jira id for the Phase 5 comment
 multi-agent resume-local --base develop     # override base branch for the diff
 multi-agent resume-local autopilot          # no gate prompts: auto-fix, auto-PR, auto-comment
 ```

package/pipeline/skills/shared/core/multi-agent-route-off/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: multi-agent-route-off
+language: en
+description: "Disable model routing and keep its rules, so turning it back on does not re-ask for the same configuration. Use when asked to turn model routing off."
+user-invocable: true
+argument-hint: "(no arguments)"
+---
+
+# multi-agent route-off  -  disarm routing, keep the configuration
+
+```bash
+bash "$HOME/.claude/lib/route-state.sh" off
+```
+
+Sets `prefs.global.modelRouting.enabled` to `false`. Dispatch returns to the
+plain ladder immediately: every persona takes its `preferredModel`, and the
+`modelFallback` rules are the only thing that can move it.
+
+## The rules are not deleted
+
+`strategy`, `scope`, `rules[]` and `budgetCeilingUsd` all survive. `route-on`
+brings back exactly what was configured, without asking again.
+
+This is the same contract `autopilot-off` follows with its repo selection, for
+the same reason: a command named after a toggle that quietly discards
+configuration is a destructive action in disguise. To actually remove the rules,
+replace them with an empty array:
+
+```bash
+echo '[]' > /tmp/none.json
+bash "$HOME/.claude/lib/route-state.sh" set-rules /tmp/none.json
+```
+
+## What stays behind
+
+Routing decisions already written to the cost ledger stay there. They are a
+record of what happened on past runs, and deleting them would make a run's cost
+unexplainable after the fact - which is the one thing the ledger exists to
+prevent.

package/pipeline/skills/shared/core/multi-agent-route-on/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: multi-agent-route-on
+language: en
+description: "Enable policy-driven model routing: pick a strategy, a scope, and the rules that say which rung a call lands on. Use when asked to turn model routing on."
+user-invocable: true
+argument-hint: "[--strategy=manual|task-fit|cost-ceiling] [--scope=subagent,bulk-read,research]"
+---
+
+# multi-agent route-on  -  arm model routing
+
+```bash
+bash "$HOME/.claude/lib/route-state.sh" on ${ARGUMENTS}
+```
+
+Routing ships **off**. This is the command that turns it on, and it writes to
+`prefs.global.modelRouting`, validated against the repo's `schemas/route-config.schema.json`.
+
+## What a rule is
+
+```json
+{ "when": { "persona": "code-reviewer" }, "prefer": ["opus", "sonnet"] }
+{ "when": { "phase": 2 },                 "prefer": ["sonnet", "haiku"] }
+```
+
+Ordered, first match wins. `when` matches on `persona`, `phase` (0..5) or
+`taskKind`; `prefer` lists rungs in descending preference.
+
+**Rung names are the contract; model ids are not.** `opus` is a rung here and a
+model id in `cost-table.json`, and the second can change without anyone editing
+a rule. Writing `claude-opus-5` into a rule pins a decision to a string that will
+go stale.
+
+Set rules with:
+
+```bash
+bash "$HOME/.claude/lib/route-state.sh" set-rules path/to/rules.json
+```
+
+## Strategies
+
+| Strategy | What it does |
+|---|---|
+| `manual` | only the explicit rules apply, nothing is inferred. The default, because a router that guesses is a router nobody can predict |
+| `task-fit` | a rule may match on `taskKind`, and the cheapest rung clearing it is chosen |
+| `cost-ceiling` | rungs downgrade as the run approaches `budgetCeilingUsd` |
+
+## Scope, and the value that is not in it
+
+`scope` names the call sites routing may act on: `subagent`, `bulk-read`,
+`research`. Every one of them is a call **this pipeline makes itself**.
+
+There is no `host-session` value, and that absence is enforced by that schema
+rather than written as advice. Routing a host session means rewriting the CLI's
+base URL to point at a local gateway - which sends the user's *entire* session
+through a third layer, including work that has nothing to do with this pipeline,
+breaks the subscription's auth model, and silently changes which model answered.
+Passing `--scope=host-session` is refused with that reason, not ignored.
+
+## The limit this command prints every time
+
+On Claude Code a subagent cannot be dispatched to a non-Anthropic model: subagent
+dispatch belongs to the host, not to us. So Phase 1, 2 and 3 personas stay inside
+the Anthropic ladder no matter what the rules say, and external providers apply
+only at `bulk-read` and `research`, where the pipeline makes the HTTP call.
+
+This is printed by `route-status` on every invocation instead of living in a doc,
+because the question it answers - "routing is on, why is the reviewer still on
+Opus" - otherwise arrives days later as a bug report.
+
+## Related
+
+- `/multi-agent:route-off` - disables routing and **keeps** the rules
+- `/multi-agent:route-status` - what is active, and what it costs
+- `/multi-agent:model` - whether the top rung exists at all. That is a different
+  question: this command decides which rung a call picks, that one decides
+  whether the top one is in play

package/pipeline/skills/shared/core/multi-agent-route-status/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: multi-agent-route-status
+language: en
+description: "Report model routing: whether it is armed, which rule applies where, which rung the last dispatches took, and what this run has cost. Use when asked which model is being used or why."
+user-invocable: true
+argument-hint: "(no arguments)"
+---
+
+# multi-agent route-status  -  what is actually routing
+
+```bash
+bash "$HOME/.claude/lib/route-state.sh" status
+```
+
+Reports the stored policy, then the part that matters more: **what it can and
+cannot reach.**
+
+## Three states, told apart
+
+| Output | Meaning |
+|---|---|
+| `routing: false`, rules present | configured and disarmed. `route-on` restores it as-is; nothing is lost |
+| `routing: true`, `rules: 0` | armed with nothing to match. Not an error - a configuration state, and the most common "I turned it on and nothing changed" |
+| `routing: true` with rules listed | live. Each rule is printed as `when <key>=<value> -> rung > rung` |
+
+A disabled router with rules is deliberately not reported as "off" alone: that
+reads as "unconfigured" and sends the user through `route-on`'s questions a
+second time.
+
+## The limit, printed every time
+
+On Claude Code a subagent cannot be sent to a non-Anthropic model. Subagent
+dispatch belongs to the host; the pipeline asks for a persona and the host
+decides what answers. So Phase 1, 2 and 3 personas stay inside the Anthropic
+ladder whatever the rules say, and an external provider is only reachable where
+the pipeline makes the HTTP call itself - `bulk-read.sh` and `research_ask`.
+
+This paragraph is output, not documentation, because the alternative is the
+question arriving later as "routing is on but the reviewer is still on Opus, is
+it broken". It is not broken; it is the seam.
+
+## Where decisions are recorded
+
+With `recordDecisions: true` (the default) every routing decision is written to
+the cost ledger: which rule matched, which rung it chose, and why. That is what
+makes a run's cost explainable after it finished - a router whose choices are not
+recorded cannot be audited, and the cost question always arrives after the run,
+never during it.
+
+Per-run cost and the model breakdown come from the same ledger:
+
+```bash
+node "$HOME/.claude/scripts/token-budget-report.mjs" --json
+```
+
+## Related
+
+- `/multi-agent:route-on` / `/multi-agent:route-off` - arm and disarm
+- `/multi-agent:model` - whether the top rung exists at all

package/pipeline/skills/shared/core/multi-agent-setup/SKILL.md

@@ -223,7 +223,7 @@ Re-run scan from Step 1. Show final status:
 All tokens present. Pipeline ready to use.
 
 Optional per-project features (configured on first use, nothing to do now):
-  • Phase 7 Report Step 2 Wiki  -  auto-generates component wiki pages + Figma
+  • Phase 5 Report Step 2 Wiki  -  auto-generates component wiki pages + Figma
     screenshots. Activates when (a) task is a component AND (b) a Figma token
     is in Keychain. Four adapters supported: submodule / in-repo / github-wiki
     / separate-repo. First run asks: use auto-detected path, use a custom

package/pipeline/skills/shared/core/multi-agent-status/SKILL.md

@@ -11,27 +11,51 @@ Show every active and completed task as a table.
 
 ## Steps
 
-1. **Detect project**  -  Find the repo root from cwd (if none, look at all known repos):
-   - `~/my-ui-components/.worktrees/`
-   - `~/my-figma-app/.worktrees/`
-   - `~/my-ios-app/.worktrees/`
+1. **Ask the producer, do not go looking.** One command answers the whole
+   question:
 
-2. **Scan worktrees**  -  Read the `agent-state.json` file in each worktree directory:
    ```bash
-   find {repo}/.worktrees/ -name "agent-state.json" -maxdepth 2
+   node "$HOME/.claude/scripts/runs-index.mjs"          # grouped table
+   node "$HOME/.claude/scripts/runs-index.mjs" --json   # the same records
    ```
 
-3. **Parse state**  -  For each task:
-   - `taskId`, `branch`, `currentPhase`, `status`, `startedAt`, `autopilot`
+   `runs-index.mjs` resolves through `lib/run-paths.sh` / `scripts/_run-paths.mjs`,
+   so it sees both directory layouts (`<project>/<id>/` and the flat `<id>/`),
+   the salvaged `artifacts/` copy Phase 4 leaves behind, and every spelling of a
+   task id - and it counts a run that exists in both layouts once. Do NOT
+   re-scan the tree by hand: the earlier instruction here listed three
+   hard-coded `.worktrees/` paths and a single `find` depth, and on a real
+   install that combination missed a quarter of the runs and double-counted
+   others. It also scanned worktrees for `agent-state.json`, which Phase 0 has
+   never written there ("never inside the worktree", `phases/phase-0-init.md`).
 
-4. **Show as a table**:
+2. **Fields per run** (already in the output): `taskId`, `project`, `branch`,
+   `currentPhase`, `status`, `startedAt`, `worktreePath`, `prUrl`, `autopilot`,
+   `phases[]`, `tokens`, `estUsd`, `group`, plus `duplicateOf` when the run also
+   exists in the other layout and `salvaged` when its state is the Phase 4 copy.
+
+3. **Groups are computed, not judged.** Report the `group` the producer
+   returns rather than re-deriving it.
+
+   | Group | Test | Action offered |
+   |---|---|---|
+   | `waiting` - Waiting on you | `status == "awaiting_input"`, or a `pr.url`, or phase >= 4 | `resume #N` - the work landed, it needs your answer |
+   | `stopped` - Stopped mid-development | anything else past phase 0 | `resume #N` or `kill #N` |
+   | `question` - Left at a question | phase 0 | `garbage-collect --abandoned` - nothing was built |
+   | `unknown` - Status not recorded | no `status` field | say so; offer nothing |
+
+   A run with no `status` is **not** placed in an actionable group. Unknown is
+   not a finding, and calling it dead is the same false claim in the other
+   direction.
+
+4. **Show as a table**, grouped per step 3:
    ```
    🤖 Multi-Agent Tasks
 
    | ID | Jira/Task | Branch | Phase | Status | Duration |
    |----|-----------|--------|-------|--------|----------|
-   | #1 | PROJ-133139 | feature/PROJ-133139-... | 7/7 DONE | ✅ Complete | 12m |
-   | #3 | PROJ-133408 | feature/PROJ-133408-... | 7/7 DONE | ✅ Complete | 8m |
+   | #1 | PROJ-133139 | feature/PROJ-133139-... | 5/5 DONE | ✅ Complete | 12m |
+   | #3 | PROJ-133408 | feature/PROJ-133408-... | 5/5 DONE | ✅ Complete | 8m |
 
    💡 log #1 | resume #N | kill #N
    ```

package/pipeline/skills/shared/core/multi-agent-steer/SKILL.md

@@ -43,7 +43,7 @@ is being replaced.
    | `paused` / `failed` | Say the task is not running, and that `/multi-agent:resume #N` will re-enter with the instruction applied at that phase's entry. Queue it. |
    | `complete` | Refuse. Nothing will read it. Point at `/multi-agent` for a follow-up run. |
 
-   `currentPhase` is 7 and status is `in_progress` → warn that Phase 7 is the
+   `currentPhase` is 7 and status is `in_progress` → warn that Phase 5 is the
    last one, so an instruction queued now may never be consumed.
 
 3. **Read the instruction**  -  from the argument, or ask for it when the
@@ -54,7 +54,7 @@ is being replaced.
 4. **Show what will be queued, and ask**:
 
    ```
-   Steer #3 ({JIRA-KEY}-12345, Phase 3 Dev, in_progress)
+   Steer #3 ({JIRA-KEY}-12345, Phase 2 Dev, in_progress)
 
      "the field is called web, not frontend"