@mmerterden/multi-agent-pipeline 8.6.0

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

@@ -0,0 +1,94 @@
+---
+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"
+---
+
+# multi-agent language — Language Preference Toggle
+
+**Input**: $ARGUMENTS
+
+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 |
+| `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`.
+
+**Always English regardless of either field**: commit messages, PR titles/bodies, Jira comments, wiki pages, reviewer/triage system prompts, agent-log.md payloads, skill-picker / confirmation / error UI exposed by the CLI host.
+
+## Invocations
+
+| Form | Behavior |
+|---|---|
+| `/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.` |
+
+## Steps
+
+### Read current state
+
+```bash
+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.
+
+### Branch on argument shape
+
+1. **No argument** → interactive picker:
+   - Show current value (English UI per skill-prompt rules):
+     ```
+     Current outputLanguage: <value>
+     (promptLanguage is fixed to "en" — not configurable)
+     ```
+   - AskUserQuestion: "Update outputLanguage?" → `en` / `tr` / keep
+   - Apply via the writer below.
+
+2. **Single token (`en` | `tr`)** → set `outputLanguage` to that value. Do NOT touch `promptLanguage`.
+
+3. **Two tokens starting with `output` (`output en|tr`)** → equivalent to the single-token form.
+
+4. **Two tokens starting with `prompt`** → reject: print `promptLanguage is fixed to "en" and cannot be changed.` and exit non-zero.
+
+5. **Anything else** → print usage and exit non-zero.
+
+### Self-heal promptLanguage
+
+If `prefs.global.promptLanguage` is not `"en"`, this skill MUST repair it back to `"en"` as part of every successful invocation. This protects against legacy preferences from earlier skill versions that allowed Turkish prompts.
+
+### Writer
+
+Validate value is in `["en", "tr"]`, then atomic write — and always force `promptLanguage = "en"`:
+
+```bash
+TMP=$(mktemp)
+jq --arg ol "$NEW_OUTPUT" '
+  .global.promptLanguage = "en"
+  | .global.outputLanguage = (if $ol == "" then .global.outputLanguage else $ol end)
+' "$PREFS" > "$TMP" && mv "$TMP" "$PREFS"
+```
+
+### Confirmation echo
+
+Render in the **new** outputLanguage:
+
+- `en`: `outputLanguage=<Y>. promptLanguage stays "en". External payloads remain English.`
+- `tr`: `outputLanguage=<Y>. promptLanguage "en" sabit. Dış çıktılar İngilizce kalır.`
+
+## Validation
+
+- Reject any value that is not `en` or `tr`. Print: `Invalid language. Use "en" or "tr".`
+- If `$PREFS` does not exist, instruct the user to run `/multi-agent:setup` first.
+- If `jq` is missing, fall back to direct file write only when both values are provided as args (skip interactive mode).
+
+## 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

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

@@ -0,0 +1,139 @@
+---
+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)'
+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
+
+**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.
+
+## 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:dev "task"` | Init → Dev → Commit → Report | ✅ | ✅ |
+| `/multi-agent:dev-autopilot "task"` | Init → Dev → Commit → Report | ✅ | ❌ |
+| `/multi-agent:dev-local "task"` | Init → Dev → Commit → Report | ❌ | ✅ |
+| `/multi-agent:dev-local-autopilot "task"` | Init → Dev → Commit → Report | ❌ | ❌ (fastest) |
+
+## 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: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.
+
+## 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
+- 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
+
+## 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
+- ⚠️ **Kill / Purge** → always asks for confirmation (destructive)
+
+## Usage
+
+```bash
+/multi-agent:local-autopilot "{JIRA-KEY}-12345"
+/multi-agent:local-autopilot https://github.com/org/repo/issues/316
+/multi-agent:local-autopilot "LoginView dark mode fix"
+/multi-agent:local-autopilot "#3"          # resume a stopped task in local-autopilot mode
+```
+
+## 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.
+
+## 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).
+
+> **Autopilot mode:** user confirmations are skipped. The tracker is still mandatory — autopilot agent calls cannot skip it; skipping breaks `smoke-tracker-contract.sh`.
+
+> **Local mode:** no worktree is created, work happens on the current branch. Phase 0 Init still calls `init` — the `--local` flag is stored in tracker-state.json, and `:resume` restores the correct CWD.
+
+Two channels run in parallel at every phase boundary:
+
+1. **State channel** (every CLI, identical): `phase-tracker.sh` writes to `tracker-state.json`. Drives `:resume`, `:log`, `:status`.
+2. **Visual channel** (CLI-specific): native widget on Claude Code, ANSI render on every other CLI. Without it the user sees no phase progress.
+
+```bash
+# Phase 0, very first shell call (every CLI):
+bash $HOME/.claude/scripts/phase-tracker.sh init "$TASK_ID"
+for p in "0:Init" "1:Analysis" "2:Planning" "3:Dev" "4:Review" "5:Test" "6:Commit" "7:Report"; do
+  bash $HOME/.claude/scripts/phase-tracker.sh add "${p%%:*}" "${p#*:}"
+done
+bash $HOME/.claude/scripts/phase-tracker.sh update 0 in_progress
+
+# Every phase boundary (every CLI):
+bash $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress|completed|failed|skipped
+
+# After every LLM call (every CLI):
+bash $HOME/.claude/scripts/phase-tracker.sh tokens <N> <in> <out>
+```
+
+### Visual channel — Claude Code (native TaskList widget, required)
+
+In Claude Code the agent MUST also drive the native TaskList widget so the user sees a sticky phase tile stack — this is the only progress signal Claude Code surfaces. Skipping these calls is the #1 source of "I don't see any phases" complaints.
+
+**TaskCreate ordering (strict)**: All TaskCreate calls fire in strict phase-number order BEFORE any TaskUpdate is applied. The native widget renders by creation order, not by phase number — out-of-order calls produce visually scrambled tile stacks (e.g. `1 ✓ · 2 ✓ · 4 ✓ · 0 ▶ · 3 ☐`) even when the underlying state is correct. Pre-marking phases as completed/skipped before Phase 0 starts is FORBIDDEN — register the tile in order, then flip status via TaskUpdate when the phase actually short-circuits. Full contract in `refs/tracker-contract.md` § "TaskCreate ordering (strict)".
+
+```text
+# Phase 0 startup — register one tile per phase (0..N), capture the taskId, persist it:
+for each phase in 0:Init, 1:Analysis, 2:Planning, 3:Dev, 4:Review, 5:Test, 6:Commit, 7:Report:
+  TaskCreate({ subject: "Phase <N>: <Name>", activeForm: "<doing-form>" })
+    -> returns taskId
+  bash $HOME/.claude/scripts/phase-tracker.sh meta <N> tasklist_id "<taskId>"
+
+# Phase entry — flip the tile to in_progress alongside the state update:
+TaskUpdate({ taskId: <saved>, status: "in_progress" })
+bash $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress
+
+# Active sub-step inside a phase — update activeForm so the spinner header reflects what's happening now:
+TaskUpdate({ taskId: <saved>, activeForm: "Editing TopBarView.swift" })
+
+# Phase exit — flip to completed/failed/skipped on both channels:
+TaskUpdate({ taskId: <saved>, status: "completed" })
+bash $HOME/.claude/scripts/phase-tracker.sh update <N> completed
+```
+
+`--local autopilot` mode TaskCreates all 8 phases (no phase is skipped).
+
+#### 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)".
+
+### Visual channel — Copilot CLI / Cursor / Windsurf / plain shell
+
+These CLIs have no TaskList widget. After every state change the agent calls render, which prints a bordered ANSI card as the last tool result so the user sees an updated phase table:
+
+```bash
+bash $HOME/.claude/scripts/phase-tracker.sh render
+```
+
+Do NOT call TaskCreate on these CLIs — the tool does not exist and the call fails.

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

@@ -0,0 +1,117 @@
+---
+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
+
+> **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.
+
+## When to use it
+
+- 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
+
+## 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
+
+## Pipeline
+
+Same phase count and order as the normal pipeline:
+
+```
+Phase 0: Init       → project detection, branch check, state (NO worktree)
+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`.
+
+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}/`).
+
+## Examples
+
+```bash
+/multi-agent:local "PROJ-12345"                                # Jira
+/multi-agent:local "#42"                                        # GitHub issue
+/multi-agent:local "LoginView dark mode fix"                    # Free-text
+```
+## Required: Phase Tracker Contract
+
+**The phase tracker is mandatory** — the agent cannot skip it. Full spec: [`refs/tracker-contract.md`](./refs/tracker-contract.md).
+
+> **Local mode:** no worktree is created, work happens on the current branch. Phase 0 Init still calls `init` — the `--local` flag is stored in tracker-state.json, and `:resume` restores the correct CWD.
+
+Two channels run in parallel at every phase boundary:
+
+1. **State channel** (every CLI, identical): `phase-tracker.sh` writes to `tracker-state.json`. Drives `:resume`, `:log`, `:status`.
+2. **Visual channel** (CLI-specific): native widget on Claude Code, ANSI render on every other CLI. Without it the user sees no phase progress.
+
+```bash
+# Phase 0, very first shell call (every CLI):
+bash $HOME/.claude/scripts/phase-tracker.sh init "$TASK_ID"
+for p in "0:Init" "1:Analysis" "2:Planning" "3:Dev" "4:Review" "5:Test" "6:Commit" "7:Report"; do
+  bash $HOME/.claude/scripts/phase-tracker.sh add "${p%%:*}" "${p#*:}"
+done
+bash $HOME/.claude/scripts/phase-tracker.sh update 0 in_progress
+
+# Every phase boundary (every CLI):
+bash $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress|completed|failed|skipped
+
+# After every LLM call (every CLI):
+bash $HOME/.claude/scripts/phase-tracker.sh tokens <N> <in> <out>
+```
+
+### Visual channel — Claude Code (native TaskList widget, required)
+
+In Claude Code the agent MUST also drive the native TaskList widget so the user sees a sticky phase tile stack — this is the only progress signal Claude Code surfaces. Skipping these calls is the #1 source of "I don't see any phases" complaints.
+
+**TaskCreate ordering (strict)**: All TaskCreate calls fire in strict phase-number order BEFORE any TaskUpdate is applied. The native widget renders by creation order, not by phase number — out-of-order calls produce visually scrambled tile stacks (e.g. `1 ✓ · 2 ✓ · 4 ✓ · 0 ▶ · 3 ☐`) even when the underlying state is correct. Pre-marking phases as completed/skipped before Phase 0 starts is FORBIDDEN — register the tile in order, then flip status via TaskUpdate when the phase actually short-circuits. Full contract in `refs/tracker-contract.md` § "TaskCreate ordering (strict)".
+
+```text
+# Phase 0 startup — register one tile per phase (0..N), capture the taskId, persist it:
+for each phase in 0:Init, 1:Analysis, 2:Planning, 3:Dev, 4:Review, 5:Test, 6:Commit, 7:Report:
+  TaskCreate({ subject: "Phase <N>: <Name>", activeForm: "<doing-form>" })
+    -> returns taskId
+  bash $HOME/.claude/scripts/phase-tracker.sh meta <N> tasklist_id "<taskId>"
+
+# Phase entry — flip the tile to in_progress alongside the state update:
+TaskUpdate({ taskId: <saved>, status: "in_progress" })
+bash $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress
+
+# Active sub-step inside a phase — update activeForm so the spinner header reflects what's happening now:
+TaskUpdate({ taskId: <saved>, activeForm: "Editing TopBarView.swift" })
+
+# Phase exit — flip to completed/failed/skipped on both channels:
+TaskUpdate({ taskId: <saved>, status: "completed" })
+bash $HOME/.claude/scripts/phase-tracker.sh update <N> completed
+```
+
+`--local` mode TaskCreates all 8 phases (no phase is skipped).
+
+#### 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)".
+
+### Visual channel — Copilot CLI / Cursor / Windsurf / plain shell
+
+These CLIs have no TaskList widget. After every state change the agent calls render, which prints a bordered ANSI card as the last tool result so the user sees an updated phase table:
+
+```bash
+bash $HOME/.claude/scripts/phase-tracker.sh render
+```
+
+Do NOT call TaskCreate on these CLIs — the tool does not exist and the call fails.

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

@@ -0,0 +1,25 @@
+---
+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."
+---
+
+# multi-agent log — Task Log Viewer
+
+**Input**: $ARGUMENTS
+
+Show the task's detailed agent-log.md report.
+
+## Steps
+
+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:
+   ```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.
+
+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

@@ -0,0 +1,43 @@
+---
+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
+
+**Input**: $ARGUMENTS
+
+Lets you switch to the task branch for manual testing in Xcode before the PR is opened.
+
+## Steps
+
+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
+   - Phase < 3 → "No code yet, run `resume #N` first"
+
+3. **Remove the worktree and switch to the branch**:
+   ```bash
+   cd {project-root}
+   git worktree remove .worktrees/{JIRA-KEY}-{id} 2>/dev/null
+   git checkout {branch-name}
+   ```
+
+4. **Tell the user how to test**:
+   ```
+   🧪 Switched to branch: {branch-name}
+
+   To test:
+     • SourceTree → review commits and diff
+     • Xcode → open .xcworkspace → Cmd+B → Cmd+U
+     • Manual test on the simulator
+
+   Reply:
+     ✅ "ok" → continue to Phase 6 (commit)
+     ❌ "fix: ..." → recreate the worktree and apply the fix
+   ```
+
+5. **Wait for the user's reply**
+
+6. **Branch on the answer**:
+   - **OK** → recreate the worktree, continue to Phase 6
+   - **Fix needed** → recreate the worktree, apply the fix

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

@@ -0,0 +1,39 @@
+---
+description: "⚠️ Wipes every worktree, branch, log, and state file. Irreversible; asks for double confirmation."
+---
+
+# multi-agent purge — Full Reset
+
+Reset every multi-agent state. Nuclear option — requires double confirmation.
+
+## Steps
+
+1. **Scan** — find every worktree:
+   ```bash
+   find {repo}/.worktrees/ -name "agent-state.json" -maxdepth 2
+   ```
+
+2. **Show the list**:
+   ```
+   ⚠️ 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
+   Total: N worktrees, N branches
+   ```
+
+3. **First confirmation**: "This is irreversible. Are you sure?"
+
+4. **Second confirmation**: "Type 'purge' to continue"
+
+5. **Delete** (per worktree):
+   ```bash
+   git worktree remove .worktrees/{JIRA-KEY}-{id} --force
+   git branch -D {branch-name}
+   ```
+
+6. **Remote branches** — ask: "Delete the remote branches too?"
+
+7. **Reset the counter** — remove `$HOME/.claude/logs/multi-agent/{project}/.counter`
+
+8. **Confirm**: `🔥 Purge complete`

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

@@ -0,0 +1,188 @@
+---
+description: "Analyse the project, score it, draft an improvement plan, take approval, develop, then ask whether to sync."
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep, Agent, AskUserQuestion, WebFetch
+---
+
+# Multi-Agent Refactor
+
+**One command. Analyse → Score → Plan → Approval → Develop → Sync.**
+
+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.)
+
+## Flow
+
+```
+Step 0: RESEARCH   Search GitHub + Reddit for competing projects, gather good ideas
+Step 1: SCAN       Walk the project structure (files, LOC, dependencies, CI, tests)
+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 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 0: RESEARCH — competitor analysis
+
+Before starting work, scan for similar projects:
+
+1. **GitHub Search**: `multi-agent pipeline AI development` + `Claude Code pipeline` + `AI coding agent`
+   - find repos with stars:>10
+   - read their READMEs
+   - extract their distinct features
+2. **Reddit Search**: multi-agent discussions in `r/ClaudeAI`, `r/ChatGPT`, `r/LocalLLaMA`
+3. **For each competitor, record**:
+   - distinct features we DO NOT have
+   - ideas worth adopting
+   - things they do better than us
+   - things we do better than them
+4. **Add to the plan**: roll the high-impact + low-effort ideas into the PLAN step (P1 priority)
+
+Output format:
+```
+| Source | Idea | Effort | Impact | In plan? |
+|--------|-------|--------|------|--------------|
+| ralph-loop | Symlink distribution | Low | High | Yes |
+| atelier | Persistent Brain | High | Very High | No (roadmap) |
+```
+
+## Step 1: SCAN
+
+```
+- file count, LOC (cloc or wc -l)
+- package.json / Package.swift / build.gradle analizi
+- dependency count (runtime vs dev)
+- Is there a CI/CD pipeline? (.github/workflows/, fastlane/, Makefile)
+- Is there test infrastructure? How many tests? Coverage?
+- Is linter/formatter config in place?
+- Do README, LICENSE, SECURITY.md, CHANGELOG.md exist?
+- Git state: branch count, last commit date, tags
+```
+
+## Step 2: ANALYZE — 10 categories
+
+| # | Category | What to check |
+|---|----------|-------------------|
+| 1 | **Architecture** | Layer separation, modularity, SOLID, dependency direction |
+| 2 | **Code Quality** | Naming, magic numbers, dead code, complexity, DRY |
+| 3 | **Security** | Hardcoded secrets, input validation, Keychain, ATS, ATT |
+| 4 | **Tests** | Coverage, test pyramid, edge cases, mock/stub quality |
+| 5 | **CI/CD** | Build matrix, lint job, release automation, artifact caching |
+| 6 | **Docs** | README quality, JSDoc / Swift docs, API docs, CHANGELOG |
+| 7 | **Performance** | Bundle size, lazy loading, memory leaks, unnecessary re-renders |
+| 8 | **Accessibility** | a11y labels, tap targets, VoiceOver, Dynamic Type |
+| 9 | **Dependency Management** | Outdated deps, vulnerability scan, lockfile, version pinning |
+| 10 | **DevEx** | Onboarding time, script ergonomics, error messages, debug tooling |
+
+## Step 3: SCORE
+
+Her kategori 10 uzerinden puanlanir. Output format:
+
+```
++---------------------+-------+
+| Category            | Score |
++---------------------+-------+
+| Architecture        | 9/10  |
+| Code Quality        | 8/10  |
+| Security            | 9/10  |
+| Tests               | 7/10  |
+| CI/CD               | 8/10  |
+| Docs                | 7/10  |
+| Performance         | 9/10  |
+| Accessibility       | 6/10  |
+| Dependency Mgmt     | 8/10  |
+| DevEx               | 9/10  |
++---------------------+-------+
+| TOTAL               | 80/100|
++---------------------+-------+
+```
+
+## Step 4: PLAN
+
+List every improvement found:
+
+```
+| # | Priority | Category | Improvement | Impact |
+|---|---------|----------|-------------|------|
+| 1 | P0 | Security | Remove hardcoded API key | Critical |
+| 2 | P0 | Tests | Missing edge-case tests | High |
+| 3 | P1 | CI/CD | Add Node matrix | Medium |
+| 4 | P1 | Docs | Functions missing JSDoc | Medium |
+| 5 | P2 | DevEx | npm script naming | Low |
+```
+
+Priority levels:
+- **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
+
+After showing the plan, ask:
+
+> "Found X improvements (P0: N, P1: M, P2: K). Should I start the work?"
+
+Options:
+- "Yes, do all"
+- "Only P0"
+- "P0 + P1 only"
+- (the user may pick specific items)
+
+**NEVER start the work without approval.**
+
+## Step 6: IMPLEMENT
+
+Apply the approved improvements one by one:
+
+1. For each improvement:
+   - apply the change
+   - run the relevant tests
+   - on success, move to the next
+   - On failure, roll back and notify the user
+2. After all changes are done:
+   - run the full lint + test suite
+   - on success, commit
+
+Commit format: `refactor(scope): {short description}`
+
+## Step 7: VERIFY
+
+```bash
+# Lint
+npm run lint 2>/dev/null || swift build 2>/dev/null
+
+# Test
+npm test 2>/dev/null || swift test 2>/dev/null || xcodebuild test 2>/dev/null
+
+# Result
+echo "Lint: PASS/FAIL"
+echo "Test: PASS/FAIL (X/Y passed)"
+```
+
+## Step 8: ASK SYNC
+
+After every improvement is applied, ask:
+
+> "Work is complete. Should I run multi-agent-sync?"
+
+Options:
+- "Yes" → run the `/sync` command (full ecosystem sync)
+- "No" → emit a report and stop
+- "Commit + push only" → push the current repo without sync
+
+## Focus filter
+
+If $ARGUMENTS is set, focus on that category only:
+
+| Input | Focus |
+|-------|------|
+| `security` | Security analysis only |
+| `tests` | Test coverage and quality only |
+| `performance` | Performance optimisation only |
+| `docs` | Docs only |
+| `ci` | CI/CD pipeline only |
+| `deps` | Dependency updates only |
+| (empty) | All 10 categories (default) |