@mmerterden/multi-agent-pipeline 8.6.1 → 10.0.6

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

@@ -1,9 +1,9 @@
 ---
 description: "Toggle outputLanguage (assistant explanations). promptLanguage is fixed to English. External payloads stay English."
-argument-hint: "[en|tr] — sets outputLanguage; omit for interactive picker; use 'output en|tr' for explicit form"
+argument-hint: "[en|tr]  -  sets outputLanguage; omit for interactive picker; use 'output en|tr' for explicit form"
 ---
 
-# multi-agent language — Language Preference Toggle
+# multi-agent language  -  Language Preference Toggle
 
 **Input**: $ARGUMENTS
 
@@ -11,7 +11,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 5 test prompt, Phase 6 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:** Pipeline picker UI, confirmation prompts, and error messages are authored in English to keep tooling consistent across CLIs. Mixing Turkish prompts into otherwise-English skill output looks inconsistent. Only the assistant's free-form replies follow `outputLanguage`.
@@ -24,8 +24,8 @@ Two-axis language preference for the pipeline:
 |---|---|
 | `/multi-agent:language` | Interactive: shows current outputLanguage, prompts for a new value via AskUserQuestion. |
 | `/multi-agent:language en` or `/multi-agent:language tr` | Sets `outputLanguage` to the given value. `promptLanguage` is left untouched (always `en`). |
-| `/multi-agent:language output en\|tr` | Same as the single-token form — sets only `outputLanguage`. |
-| `/multi-agent:language prompt …` | **Rejected.** Print: `promptLanguage is fixed to "en" and cannot be changed.` |
+| `/multi-agent:language output en\|tr` | Same as the single-token form  -  sets only `outputLanguage`. |
+| `/multi-agent:language prompt ...` | **Rejected.** Print: `promptLanguage is fixed to "en" and cannot be changed.` |
 
 ## Steps
 
@@ -36,7 +36,7 @@ PREFS="$HOME/.claude/multi-agent-preferences.json"
 OUTPUT_LANG=$(jq -r '.global.outputLanguage // "<unset>"' "$PREFS" 2>/dev/null || echo "<unset>")
 ```
 
-`promptLanguage` is intentionally NOT read — it is a fixed `en` and not a knob this skill exposes.
+`promptLanguage` is intentionally NOT read  -  it is a fixed `en` and not a knob this skill exposes.
 
 ### Branch on argument shape
 
@@ -44,7 +44,7 @@ OUTPUT_LANG=$(jq -r '.global.outputLanguage // "<unset>"' "$PREFS" 2>/dev/null |
    - Show current value (English UI per skill-prompt rules):
      ```
      Current outputLanguage: <value>
-     (promptLanguage is fixed to "en" — not configurable)
+     (promptLanguage is fixed to "en"  -  not configurable)
      ```
    - AskUserQuestion: "Update outputLanguage?" → `en` / `tr` / keep
    - Apply via the writer below.
@@ -63,7 +63,7 @@ If `prefs.global.promptLanguage` is not `"en"`, this skill MUST repair it back t
 
 ### Writer
 
-Validate value is in `["en", "tr"]`, then atomic write — and always force `promptLanguage = "en"`:
+Validate value is in `["en", "tr"]`, then atomic write  -  and always force `promptLanguage = "en"`:
 
 ```bash
 TMP=$(mktemp)
@@ -88,7 +88,7 @@ Render in the **new** outputLanguage:
 
 ## Cross-reference
 
-- `setup.md` Step 0 — first-run language picker (asks only outputLanguage; promptLanguage seeded as `en`)
-- `prefs.schema.json` — `global.promptLanguage` (fixed `"en"`) and `global.outputLanguage` definitions
-- `phase-5-test.md`, `phase-6-commit.md` — read promptLanguage for their interactive prompts (always English)
-- `help.md` — reads outputLanguage to render its own help text
+- `setup.md` Step 0  -  first-run language picker (asks only outputLanguage; promptLanguage seeded as `en`)
+- `prefs.schema.json`  -  `global.promptLanguage` (fixed `"en"`) and `global.outputLanguage` definitions
+- `phase-5-test.md`, `phase-6-commit.md`  -  read promptLanguage for their interactive prompts (always English)
+- `help.md`  -  reads outputLanguage to render its own help text

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

@@ -1,25 +1,25 @@
 ---
-description: "Full pipeline + local + autopilot — no worktree, no confirmations, all 8 phases run end-to-end on the current branch."
-argument-hint: '"task" — issue URL, Jira ID, free-text, or #id (for resume)'
+description: "Full pipeline + local + autopilot  -  no worktree, no confirmations; runs 7 phases (User Test skipped) end-to-end on the current branch."
+argument-hint: '"task"  -  issue URL, Jira ID, free-text, or #id (for resume)'
 allowed-tools: Agent, Bash, Read, Write, Edit, Glob, Grep, TaskCreate, TaskUpdate, TaskList, TaskGet, AskUserQuestion, WebFetch, WebSearch, Skill
 ---
 
-# multi-agent local-autopilot — Full Pipeline, Local Branch, Autonomous
+# multi-agent local-autopilot  -  Full Pipeline, Local Branch, Autonomous
 
 **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".
 
-Run the full 8-phase pipeline **without a worktree** and **with every confirmation skipped**. The `autopilot + local` combination — vs `/multi-agent:autopilot` the only difference is no worktree (work stays on the current branch); vs `/multi-agent:local` the only difference is zero interaction.
+Run the full pipeline **without a worktree** and **with every confirmation skipped**. Phase 5 (User Test) does not run (no worktree to check out from, and no interaction), so 7 phases execute. The `autopilot + local` combination  -  vs `/multi-agent:autopilot` the only difference is no worktree (work stays on the current branch); vs `/multi-agent:local` the only difference is zero interaction.
 
 ## Matrix (which one should I use?)
 
 | Command | Pipeline | Worktree | Confirmations |
 |---|---|---|---|
 | `/multi-agent "task"` | Full 8 phases | ✅ | ✅ (interactive) |
-| `/multi-agent:autopilot "task"` | Full 8 phases | ✅ | ❌ (autopilot) |
-| `/multi-agent:local "task"` | Full 8 phases | ❌ | ✅ (interactive) |
-| **`/multi-agent:local-autopilot "task"`** | **Full 8 phases** | **❌** | **❌ (autopilot)** |
+| `/multi-agent:autopilot "task"` | 7 phases (no User Test) | ✅ | ❌ (autopilot) |
+| `/multi-agent:local "task"` | 7 phases (no User Test) | ❌ | ✅ (interactive) |
+| **`/multi-agent:local-autopilot "task"`** | **7 phases (no User Test)** | **❌** | **❌ (autopilot)** |
 | `/multi-agent:dev "task"` | Init → Dev → Commit → Report | ✅ | ✅ |
 | `/multi-agent:dev-autopilot "task"` | Init → Dev → Commit → Report | ✅ | ❌ |
 | `/multi-agent:dev-local "task"` | Init → Dev → Commit → Report | ❌ | ✅ |
@@ -27,27 +27,27 @@ Run the full 8-phase pipeline **without a worktree** and **with every confirmati
 
 ## What changes
 
-**vs `/multi-agent:autopilot`**: no worktree is created; work stays on the current branch. The task runs in the same editor / IDE session — no second folder.
+**vs `/multi-agent:autopilot`**: no worktree is created; work stays on the current branch. The task runs in the same editor / IDE session  -  no second folder.
 
-**vs `/multi-agent:local`**: Phase 2 Plan Approval Gate is skipped (the safety classifier still runs), Phase 5 test prompt is skipped, Phase 6 commit / PR runs without confirmation. All 8 phases still execute — review / triage / build discipline are preserved.
+**vs `/multi-agent:local`**: Phase 2 Plan Approval Gate is skipped (the safety classifier still runs) and Phase 6 commit / PR runs without confirmation. Both modes already skip Phase 5 (User Test) because neither has a worktree, so the same seven phases execute  -  review / triage / build discipline are preserved.
 
 ## When to use it
 
 - You want full-pipeline discipline (parallel review + triage) on a small task but want to step away from the keyboard
-- Single repo + simple branch — the worktree overhead is unnecessary; autopilot + local = clean flow
+- Single repo + simple branch  -  the worktree overhead is unnecessary; autopilot + local = clean flow
 - Repro-to-fix loop: try things quickly in the local folder, then fire the pipeline forget-and-go on the same branch
 
 ## When NOT to use it
 
-- Multiple parallel tasks — you lose worktree isolation; branch collisions
-- Security-path or schema-migration changes — the Phase 2 safety classifier auto-pauses (`autopilotSafetyGate`, default on)
-- Multi-repo — `--local` is locked to a single repo
+- Multiple parallel tasks  -  you lose worktree isolation; branch collisions
+- Security-path or schema-migration changes  -  the Phase 2 safety classifier auto-pauses (`autopilotSafetyGate`, default on)
+- Multi-repo  -  `--local` is locked to a single repo
 
 ## Never skipped (even with autopilot + local)
 
 - 🔴 **Review-blocking finding** → auto fix + rebuild (max 3 retries)
 - 💥 **Build failure** → auto fix + rebuild (max 3 retries, then pause)
-- 🛡️ **Safety classifier pause** — for high-risk plans, asks once for manual confirmation even in autopilot
+- 🛡️ **Safety classifier pause**  -  for high-risk plans, asks once for manual confirmation even in autopilot
 - ⚠️ **Kill / Purge** → always asks for confirmation (destructive)
 
 ## Usage
@@ -61,21 +61,21 @@ Run the full 8-phase pipeline **without a worktree** and **with every confirmati
 
 ## Steps
 
-1. **Parse input** — standard multi-agent input formats.
-2. **Set both flags** — write `"autopilot": true` and `"local": true` into `agent-state.json`.
-3. **Launch the multi-agent pipeline** — Phase 0 worktree step is skipped (local contract), Phase 2/5/6 confirmations are skipped (autopilot contract), Phase 4 safety classifier runs.
-4. **On error** — after 3 failed retries, pause and ask the user.
+1. **Parse input**  -  standard multi-agent input formats.
+2. **Set both flags**  -  write `"autopilot": true` and `"local": true` into `agent-state.json`.
+3. **Launch the multi-agent pipeline**  -  Phase 0 worktree step is skipped (local contract), Phase 2/5/6 confirmations are skipped (autopilot contract), Phase 4 safety classifier runs.
+4. **On error**  -  after 3 failed retries, pause and ask the user.
 
 ## Delegation
 
 Orchestrator routing: the routing table in `$HOME/.claude/commands/multi-agent.md` resolves `local-autopilot` as the union of the `dev-local` + `autopilot` mode mixins. Contract details: `refs/phases/phase-0-init.md` Step 8 (local branch) + `refs/phases/phase-2-planning.md` Step 5 (autopilot gate skip + safety classifier).
 ## 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:
 
@@ -85,7 +85,7 @@ Two channels run in parallel at every phase boundary:
 ```bash
 # Phase 0, very first shell call (every CLI):
 bash $HOME/.claude/scripts/phase-tracker.sh init "$TASK_ID"
-for p in "0:Init" "1:Analysis" "2:Planning" "3:Dev" "4:Review" "5:Test" "6:Commit" "7:Report"; do
+for p in "0:Init" "1:Analysis" "2:Planning" "3:Dev" "4:Review" "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
@@ -97,38 +97,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:
-for each phase in 0:Init, 1:Analysis, 2:Planning, 3:Dev, 4:Review, 5:Test, 6:Commit, 7:Report:
+# Phase 0 startup  -  register one tile per phase (0..N), capture the taskId, persist it:
+for each phase in 0:Init, 1:Analysis, 2:Planning, 3:Dev, 4:Review, 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
 ```
 
-`--local autopilot` mode TaskCreates all 8 phases (no phase is skipped).
+`--local autopilot` mode does NOT TaskCreate phases 5  -  those are not part of the `--local autopilot` phase set (`0:Init 1:Analysis 2:Planning 3:Dev 4:Review 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 `--local autopilot` that means: Phase 0 → Phase 1 → Phase 2 → Phase 3 → Phase 4 → 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 `--local autopilot` that means: Phase 0 → Phase 1 → Phase 2 → Phase 3 → Phase 4 → 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:
 
@@ -136,4 +136,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/local.md

@@ -1,25 +1,25 @@
 ---
-description: "Full pipeline in local mode — no worktree, runs directly on the current branch."
+description: "Full pipeline in local mode  -  no worktree, runs directly on the current branch."
 allowed-tools: Agent, Bash, Read, Write, Edit, Glob, Grep, TaskCreate, TaskUpdate, TaskList, TaskGet, AskUserQuestion, WebFetch, WebSearch, Skill
 ---
 
-# multi-agent local — Full Pipeline, Local Branch
+# multi-agent local  -  Full Pipeline, Local Branch
 
 > **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 full 8-phase pipeline in normal mode (Plan Approval Gate + parallel review + triage included), running on the **current branch with no worktree**. Dedicated alias for the `multi-agent "task" --local` flag form.
+The full pipeline in normal mode (Plan Approval Gate + parallel review + triage included), running on the **current branch with no worktree**. Dedicated alias for the `multi-agent "task" --local` flag form. Phase 5 (User Test) is skipped because there is no worktree to check the change out from; the other seven phases all run.
 
 ## When to use it
 
-- You don't want a separate worktree open — keeps the editor / IDE in one folder
+- You don't want a separate worktree open  -  keeps the editor / IDE in one folder
 - You're already on the right branch and just want pipeline discipline
-- Small project or prototype — the worktree overhead is unnecessary
+- Small project or prototype  -  the worktree overhead is unnecessary
 
 ## When NOT to use it
 
-- Multiple parallel tasks at the same time — you lose worktree isolation
-- Long-iteration changes on a production repo — branch-switch friction shows up
-- Multi-repo tasks — `--local` is locked to a single repo
+- Multiple parallel tasks at the same time  -  you lose worktree isolation
+- Long-iteration changes on a production repo  -  branch-switch friction shows up
+- Multi-repo tasks  -  `--local` is locked to a single repo
 
 ## Pipeline
 
@@ -31,14 +31,13 @@ Phase 1: Analysis   → codebase scan (parallel explore agents, Opus)
 Phase 2: Planning   → task breakdown, Plan Approval Gate (approval loop)
 Phase 3: Dev        → TDD (Sonnet), build queue
 Phase 4: Review     → deterministic gates + parallel review + Opus triage
-Phase 5: Test       → optional manual test
 Phase 6: Commit     → pre-commit checkout prompt, commit + push + PR
 Phase 7: Report     → Jira / Wiki / Confluence + log + knowledge/memory
 ```
 
 ## Delegation
 
-This command routes to the orchestrator with the `--local` flag set. The Phase 0–7 contract from `refs/phases/phase-0-init.md` and the later phase docs applies as-is — only the worktree step is skipped, and `state.projects[*].worktreePath` stays `null`.
+This command routes to the orchestrator with the `--local` flag set. The Phase 0-7 contract from `refs/phases/phase-0-init.md` and the later phase docs applies as-is  -  only the worktree step is skipped, and `state.projects[*].worktreePath` stays `null`.
 
 Read the routing table in `$HOME/.claude/commands/multi-agent.md` and apply Phase 0 Step 8 in local mode (no worktree: continue on the current branch, state file under `.claude/logs/multi-agent/{project}/{taskId}/`).
 
@@ -51,9 +50,9 @@ Read the routing table in `$HOME/.claude/commands/multi-agent.md` and apply Phas
 ```
 ## 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:
 
@@ -63,7 +62,7 @@ Two channels run in parallel at every phase boundary:
 ```bash
 # Phase 0, very first shell call (every CLI):
 bash $HOME/.claude/scripts/phase-tracker.sh init "$TASK_ID"
-for p in "0:Init" "1:Analysis" "2:Planning" "3:Dev" "4:Review" "5:Test" "6:Commit" "7:Report"; do
+for p in "0:Init" "1:Analysis" "2:Planning" "3:Dev" "4:Review" "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
@@ -75,38 +74,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:
-for each phase in 0:Init, 1:Analysis, 2:Planning, 3:Dev, 4:Review, 5:Test, 6:Commit, 7:Report:
+# Phase 0 startup  -  register one tile per phase (0..N), capture the taskId, persist it:
+for each phase in 0:Init, 1:Analysis, 2:Planning, 3:Dev, 4:Review, 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
 ```
 
-`--local` mode TaskCreates all 8 phases (no phase is skipped).
+`--local` mode does NOT TaskCreate phases 5  -  those are not part of the `--local` phase set (`0:Init 1:Analysis 2:Planning 3:Dev 4:Review 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 `--local` that means: Phase 0 → Phase 1 → Phase 2 → Phase 3 → Phase 4 → 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 `--local` that means: Phase 0 → Phase 1 → Phase 2 → Phase 3 → Phase 4 → 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:
 
@@ -114,4 +113,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/log.md

@@ -1,9 +1,9 @@
 ---
 description: "Show the agent-log.md for the given task. With no ID, shows the most recent task."
-argument-hint: "[#id] — optional: task ID (e.g. #3). If omitted, the most recent task is used."
+argument-hint: "[#id]  -  optional: task ID (e.g. #3). If omitted, the most recent task is used."
 ---
 
-# multi-agent log — Task Log Viewer
+# multi-agent log  -  Task Log Viewer
 
 **Input**: $ARGUMENTS
 
@@ -11,15 +11,15 @@ Show the task's detailed agent-log.md report.
 
 ## Steps
 
-1. **Parse task ID** — extract the `#N` form from the argument.
+1. **Parse task ID**  -  extract the `#N` form from the argument.
    - No argument → find the most recent (highest-ID) worktree.
 
-2. **Find the worktree** — search the known repos:
+2. **Find the worktree**  -  search the known repos:
    ```bash
    find ~/my-ios-app/.worktrees/ ~/my-figma-app/.worktrees/ ~/my-ui-components/.worktrees/ -name "agent-state.json" -maxdepth 2 2>/dev/null
    ```
    - Pick the worktree whose `taskId` or short ID matches.
 
-3. **Read agent-log.md** — display the file.
+3. **Read agent-log.md**  -  display the file.
 
-4. **Provide a summary** — when the log is long, show only the Timeline table + Review Consensus, and give the file path for the full log.
+4. **Provide a summary**  -  when the log is long, show only the Timeline table + Review Consensus, and give the file path for the full log.

package/pipeline/commands/multi-agent/manual-test.md

@@ -2,7 +2,7 @@
 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)."
 ---
 
-# multi-agent manual-test — Phase 5 Manual Test Mode
+# multi-agent manual-test  -  Phase 5 Manual Test Mode
 
 **Input**: $ARGUMENTS
 
@@ -10,9 +10,9 @@ Lets you switch to the task branch for manual testing in Xcode before the PR is
 
 ## Steps
 
-1. **Find the task** — parse `#N` from the argument or pick the most recent task
+1. **Find the task**  -  parse `#N` from the argument or pick the most recent task
 
-2. **Check state** — the task must have completed Phase 3 or later
+2. **Check state**  -  the task must have completed Phase 3 or later
    - Phase < 3 → "No code yet, run `resume #N` first"
 
 3. **Remove the worktree and switch to the branch**:

package/pipeline/commands/multi-agent/prune-logs.md

@@ -0,0 +1,60 @@
+---
+description: "Delete per-task project logs under ~/.claude/logs/multi-agent (filter by age/project/task). Audit trail + metrics are preserved. Dry-run first; confirms before deleting."
+argument-hint: "[--older-than=<days>] [--project=<name>] [--task=<id>] [--yes]"
+---
+
+# multi-agent prune-logs  -  Clear Per-Task Project Logs
+
+Every run persists a task log dir at
+`~/.claude/logs/multi-agent/<project>/<task>/` (agent-state.json, agent-log.md,
+tracker-state.json, otel-spans.jsonl). These accumulate forever. This prunes
+whole task dirs, with optional age / project / task filters.
+
+Backed by `$HOME/.claude/scripts/prune-logs.sh`. Safe by default: it previews
+and deletes nothing until you confirm. The audit trail (`audit.jsonl` +
+rotations) and the metrics corpus (`metrics.jsonl`, `metrics-summary.md`) live
+at the log-root top level and are never removed; `.counter` files survive too.
+
+Unlike `/multi-agent:purge` (which wipes worktrees, branches, logs, and state
+together), this only removes log dirs and leaves your worktrees and branches
+untouched.
+
+## Steps
+
+1. **Preview (dry-run)**  -  run the pruner with no `--yes`, forwarding any
+   `--older-than=<days>`, `--project=<name>`, or `--task=<id>` the user gave:
+
+   ```bash
+   bash $HOME/.claude/scripts/prune-logs.sh ${ARGUMENTS}
+   ```
+
+   It lists each task log dir that matches and the space it would free.
+
+2. **Nothing to do**  -  if the output says `nothing matched`, stop and report
+   there is nothing to prune.
+
+3. **Confirm**  -  surface a native `AskUserQuestion` picker (no typed keyword),
+   in `outputLanguage`:
+   - `question`: "Delete the listed task log dirs now?" (include the count and
+     freed-size estimate, and note audit + metrics are preserved)
+   - `header`: "Prune logs" (English, <=12 chars)
+   - `options`: `{ label: "Delete logs", description: "Remove the listed task log dirs" }`,
+     `{ label: "Cancel", description: "Keep everything, change nothing" }`
+   - Anything other than **Delete logs** -> cancel and change nothing.
+
+4. **Delete**  -  on confirm, re-run with `--yes` plus the same filters:
+
+   ```bash
+   bash $HOME/.claude/scripts/prune-logs.sh --yes ${ARGUMENTS}
+   ```
+
+5. **Report**  -  echo the `══ prune-logs: removed N task log dir(s), freed ~X ══`
+   summary line.
+
+## Notes
+
+- Pruning a log dir does not affect the run's git history or its commit/PR;
+  it only removes the local state + log artifacts.
+- To also reclaim `/tmp` scratch, use `/multi-agent:garbage-collect`.
+- For a full reset (worktrees + branches + logs + state), use
+  `/multi-agent:purge`.

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

@@ -2,20 +2,20 @@
 description: "⚠️ Wipes every worktree, branch, log, and state file. Irreversible; asks for double confirmation."
 ---
 
-# multi-agent purge — Full Reset
+# multi-agent purge  -  Full Reset
 
-Reset every multi-agent state. Nuclear option — requires double confirmation.
+Reset every multi-agent state. Nuclear option  -  requires double confirmation.
 
 ## Steps
 
-1. **Scan** — find every worktree:
+1. **Scan**  -  find every worktree:
    ```bash
    find {repo}/.worktrees/ -name "agent-state.json" -maxdepth 2
    ```
 
 2. **Show the list**:
    ```
-   ⚠️ WARNING — these will be deleted:
+   ⚠️ WARNING  -  these will be deleted:
    - .worktrees/{JIRA-KEY}-12345/ (branch: feature/{JIRA-KEY}-12345-...)
    - .worktrees/{JIRA-KEY}-12345/ (branch: feature/{JIRA-KEY}-12345-...)
    - $HOME/.claude/logs/multi-agent/{project}/.counter
@@ -24,7 +24,10 @@ Reset every multi-agent state. Nuclear option — requires double confirmation.
 
 3. **First confirmation**: "This is irreversible. Are you sure?"
 
-4. **Second confirmation**: "Type 'purge' to continue"
+4. **Second confirmation** (paranoia gate)  -  a native `AskUserQuestion` picker (no typed keyword):
+   - `question`: "This is irreversible. Permanently wipe every worktree, branch, log, and state file now?" (`outputLanguage`)
+   - `header`: "Purge" (English, <=12 chars) · `options`: `{ label: "Purge permanently", description: "Delete all worktrees, branches, logs, and state" }`, `{ label: "Cancel", description: "Abort, change nothing" }`
+   - Anything other than **Purge permanently** → cancel.
 
 5. **Delete** (per worktree):
    ```bash
@@ -32,8 +35,8 @@ Reset every multi-agent state. Nuclear option — requires double confirmation.
    git branch -D {branch-name}
    ```
 
-6. **Remote branches** — ask: "Delete the remote branches too?"
+6. **Remote branches**  -  ask: "Delete the remote branches too?"
 
-7. **Reset the counter** — remove `$HOME/.claude/logs/multi-agent/{project}/.counter`
+7. **Reset the counter**  -  remove `$HOME/.claude/logs/multi-agent/{project}/.counter`
 
 8. **Confirm**: `🔥 Purge complete`

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

@@ -9,7 +9,7 @@ allowed-tools: Read, Write, Edit, Bash, Glob, Grep, Agent, AskUserQuestion, WebF
 
 Deep-analyses the current project, scores it across 10 categories, drafts every improvement, asks the user for approval, applies them, and asks about sync at the end.
 
-**Input**: $ARGUMENTS (optional — area to focus on: "security", "performance", "tests", etc.)
+**Input**: $ARGUMENTS (optional  -  area to focus on: "security", "performance", "tests", etc.)
 
 ## Flow
 
@@ -19,13 +19,13 @@ Step 1: SCAN       Walk the project structure (files, LOC, dependencies, CI, tes
 Step 2: ANALYZE    Deep analysis across 10 categories
 Step 3: SCORE      Each category /10, overall /100
 Step 4: PLAN       List every improvement + competitor idea in priority order
-Step 5: ASK        "Start the work?" — wait for user approval
+Step 5: ASK        "Start the work?"  -  wait for user approval
 Step 6: IMPLEMENT  Apply approved improvements one by one (lint, test, commit)
 Step 7: VERIFY     Confirm every test + lint passes
-Step 8: ASK SYNC   "Run multi-agent-sync?" — wait for user approval
+Step 8: ASK SYNC   "Run multi-agent-sync?"  -  wait for user approval
 ```
 
-## Step 0: RESEARCH — competitor analysis
+## Step 0: RESEARCH  -  competitor analysis
 
 Before starting work, scan for similar projects:
 
@@ -62,7 +62,7 @@ Output format:
 - Git state: branch count, last commit date, tags
 ```
 
-## Step 2: ANALYZE — 10 categories
+## Step 2: ANALYZE  -  10 categories
 
 | # | Category | What to check |
 |---|----------|-------------------|
@@ -115,11 +115,11 @@ List every improvement found:
 ```
 
 Priority levels:
-- **P0**: bugs, security holes, broken functionality — MUST fix
-- **P1**: clear quality improvement — should be done
-- **P2**: nice-to-have — if time allows
+- **P0**: bugs, security holes, broken functionality  -  MUST fix
+- **P1**: clear quality improvement  -  should be done
+- **P2**: nice-to-have  -  if time allows
 
-## Step 5: ASK — user approval
+## Step 5: ASK  -  user approval
 
 After showing the plan, ask: