@mmerterden/multi-agent-pipeline 19.1.4 → 20.1.0

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

@@ -1,142 +0,0 @@
----
-description: "Full pipeline + local + autopilot  -  no worktree, no confirmations; runs all 6 phases 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-tr: "Tam pipeline + lokal + autopilot - worktree yok, onay yok; 6 fazı mevcut branch üzerinde uçtan uca koşar (kullanıcı testi Review'ın içinde, autopilot'ta atlanır)."
-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` renders its `question`, option `label`s and option `description`s in `outputLanguage`; only `header` stays English (<=12-char chip); external payload bodies follow `outputLanguage` too (identifiers, commit messages, branch names stay English). Full contract: `$HOME/.claude/multi-agent-refs/rules.md` "Language Application".
-
-Run the full pipeline **without a worktree** and **with every confirmation skipped**. All six phases execute. The user test inside Phase 3 Review is skipped  -  there is no worktree to check out from and no interaction to have  -  but it stopped being a phase of its own in v19.0.0, so nothing is dropped from the set. 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"` | 6 phases, user test offered | ✅ | ✅ (interactive) |
-| `/multi-agent:autopilot "task"` | 6 phases, user test skipped | ✅ | ❌ (autopilot) |
-| `/multi-agent:local "task"` | 6 phases, user test offered | ❌ | ✅ (interactive) |
-| **`/multi-agent:local-autopilot "task"`** | **6 phases, user test skipped** | **❌** | **❌ (autopilot)** |
-
-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.
-
-## 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) and Phase 4 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
-- 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/SKILL.md` resolves `local-autopilot` as the union of the `local` + `autopilot` mode mixins. Contract details: `$HOME/.claude/multi-agent-refs/phases/phase-0-init.md` Step 6 (local branch) + `$HOME/.claude/multi-agent-refs/phases/phase-1-plan.md` Step 5 (autopilot gate skip + safety classifier).
-## Required: outward-facing payload contracts
-
-Before writing anything outward-facing  -  PR body, Jira comment, Confluence page, closing report  -  load `$HOME/.claude/multi-agent-refs/payload-contracts.md`. It names the canonical section set for each payload, the markup dialect per surface (PR body is Markdown, Jira is wiki markup  -  mixing them is a defect), and the token/duration numbers the closing report must carry. Improvising a payload shape from memory is the most common failure of the short modes.
-
-## Required: Phase Tracker Contract
-
-**The phase tracker is mandatory**  -  the agent cannot skip it. Full spec: [`$HOME/.claude/multi-agent-refs/tracker-contract.md`]($HOME/.claude/multi-agent-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:Plan" "2:Dev" "3:Review" "4:Commit" "5: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> [cached]
-```
-
-### 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 in a registration batch fire in strict phase-number order BEFORE any TaskUpdate in that batch, and a later batch only ever appends phases numbered above everything already registered. 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 `$HOME/.claude/multi-agent-refs/tracker-contract.md` section "TaskCreate ordering (strict)".
-
-```text
-# Register one tile per phase, capture the taskId, persist it:
-for each phase in 0:Init, 1:Plan, 2:Dev, 3:Review, 4:Commit, 5: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 6 phases (no phase is skipped).
-
-#### TaskCreate ordering (strict)
-
-**All TaskCreate calls in a batch 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. The native widget renders by creation order, not by phase number  -  out-of-order calls produce visually scrambled tile stacks. Full ordering contract in `$HOME/.claude/multi-agent-refs/tracker-contract.md` section "TaskCreate ordering (strict)".
-
-### Visual channel  -  Copilot CLI / 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/resume-local/SKILL.md

@@ -1,114 +0,0 @@
----
-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."
-description-tr: "Halihazırda bitmiş LOKAL işi pipeline kuyruğundan geçirir: Review (build kapısıyla) → Commit/PR → Report (teknik analiz + Jira test-senaryosu yorumu). Dev fazı yok."
-allowed-tools: Agent, Bash, Read, Write, Edit, Glob, Grep, TaskCreate, TaskUpdate, TaskList, TaskGet, AskUserQuestion, WebFetch, WebSearch, Skill
----
-
-# multi-agent resume-local  -  Take Existing Branch Work Through the Pipeline Tail
-
-> **Language (read FIRST)**: Before any status output, read `prefs.global.outputLanguage` and render every conversational line in it. `AskUserQuestion` renders its `question`, option `label`s and option `description`s in `outputLanguage`; only `header` stays English (<=12-char chip); external payload bodies follow `outputLanguage` too (identifiers, commit messages, branch names stay English). Full contract: `$HOME/.claude/multi-agent-refs/rules.md` "Language Application".
-
-You already did the work locally  -  wrote code on the current branch and maybe tested it by hand, or committed it outside the pipeline entirely. (As of v14.0.0 a Short run reviews its own output, so this command is for work that had no pipeline run behind it, not a patch for a mode that skipped review.) `/multi-agent:resume-local` picks up from there and runs the **pipeline tail** over that existing local work in one command: parallel review, a build + test success gate, commit/push + PR, then the technical analysis and a **Jira comment with test scenarios**. It does NOT re-develop  -  Analysis / Planning / Dev (phases 1-3) are intentionally skipped; the diff already on the branch IS the input.
-
-## When to use it
-
-- You ran `:local` and answered Short (which skips Review + Test) and now want the full quality tail on the same branch.
-- You hand-coded or hand-tested a change and want review + build/test + PR + Jira write-up without re-running dev.
-- You want the "reviewed, built, tested, PR'd, documented on Jira" finish with a single command.
-
-## When NOT to use it
-
-- You haven't written the change yet  -  use `/multi-agent` or `/multi-agent:local`.
-- You only want the review, nothing else  -  use `/multi-agent:review`. Only the report/channels  -  `/multi-agent:channels`. Only device UI testing  -  `/multi-agent:test` / `/multi-agent:manual-test`.
-
-## Input
-
-```bash
-/multi-agent:resume-local                       # current branch vs its base; resolve Jira id from branch name
-/multi-agent:resume-local PROJ-12345          # bind to an explicit Jira id for the Phase 5 comment
-/multi-agent:resume-local --base develop         # override the base branch for the diff
-/multi-agent:resume-local autopilot              # no gate prompts: auto-fix blocking findings, auto-PR, auto-comment
-```
-
-## Pipeline
-
-```
-Phase 0: Init          → project/branch detect, resolve base + diff (work-already-done), Jira id, state (NO worktree)
-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 local changes + push + open PR if none exists
-Phase 5: Report        → technical analysis + Jira comment with test scenarios (channels: Jira / PR / Confluence / Wiki)
-```
-
-Phases 1-2 (Plan / Dev) are skipped by design  -  `ship` treats the current branch's local changes as the Phase 2 output.
-
-**Why Review runs the build gate here.** Verify is Phase 2 Dev's exit gate since v19.0.0, and this mode has no Dev: the work arrived already written. The gate still has to run, so Review runs it before dispatching reviewers, which is what Review Stage 1 did before the consolidation. Reviewing a branch whose build was never checked is the failure this ordering prevents.
-
-## Phase 0  -  Context resolution (finish-specific)
-
-1. **Project + branch:** detect project (cwd), current branch (`git branch --show-current`). No worktree; work stays on the current branch.
-2. **Base + diff:** resolve base branch in order: `--base <arg>` → `figma-config.project.baseBranch` → `develop` → the branch's upstream/merge-base. The **work under review** is `git diff <base>...HEAD` PLUS uncommitted working-tree changes (`git status`). Abort with a clear message if the diff is empty (`ERR: no local work to finish on <branch> vs <base>`).
-3. **Task binding:** Jira id from the `--`/positional arg, else parse the branch name (`bugfix/PROJ-XXXX` / `feature/PROJ-XXXX`); `taskType` inferred from the diff (bugfix/feature/refactor/chore) for the report wording. GitHub issue `#N` from branch/arg when present.
-4. **Prior state (optional):** if an `agent-state.json` / tracker-state exists for this branch (left by a prior `:local` run), load its analysis summary + Jira/issue binding to enrich the report; otherwise synthesize a minimal state over the diff. Never require a prior full-pipeline run.
-5. Persist state under `.claude/logs/multi-agent/{project}/{taskId}/` (same as `--local`).
-
-## Phase execution (reuse the existing phase contracts)
-
-- **Phase 3 Review** - run per `$HOME/.claude/multi-agent-refs/phases/phase-3-review.md` against the resolved diff: deterministic gates (Step 1.x), stack-specific parallel reviewers (Fable + Opus + Sonnet on Claude Code; GPT + Opus + Sonnet on Copilot CLI), Fable triage → `triage.accepted`. Blocking/important accepted findings:
-  - interactive: present them and ask (`AskUserQuestion`) whether to fix now (loop back through a minimal Phase-3-style TDD fix) or proceed;
-  - `autopilot` (or `prefs.global.resumeLocal.autoFix == true`): auto-fix accepted blocking/important findings, then re-review the fix, before advancing.
-- **Phase 3 Verify gate** - the **automated success gate** (this is what "build+test success" means here; the interactive device user-test is `/multi-agent:manual-test`). Stack-aware: build via `figma-config.build` (iOS scheme / Android gradle / detected backend/web build) and run the existing test suite if present (`swift test` / `xcodebuild test` / `./gradlew test` / `pytest` / `npm test` / `vitest`). Require success to advance; on failure, surface logs and (interactive) stop or (autopilot) attempt a bounded fix loop. **If the repo has no tests, report "no tests present" - never fabricate test results.**
-- **Phase 4 Commit/PR** - per `$HOME/.claude/multi-agent-refs/phases/phase-4-commit.md`: stage + commit any remaining local changes with a conventional message (`{type}(scope): desc [{JIRA_KEY}-{id}]`), push, and open a PR **only if one does not already exist** for the branch. PR body per `$HOME/.claude/multi-agent-refs/rules.md "External System Outputs"` and `$HOME/.claude/rules/git-conventions.md` - `Ref: #N` / `Related: #N`, never `Closes/Fixes/Resolves`; NO AI/bot attribution anywhere.
-- **Phase 5 Report** - per `$HOME/.claude/multi-agent-refs/phases/phase-5-report.md` + `channels.md`: produce the **technical analysis** and **test scenarios**, then post to the configured channels. Default content for `ship`: a Jira **comment** carrying the technical analysis + the test scenarios (and, when the PR was opened, the PR description). Every body runs through the humanizer; bot/tool/AI signatures are FORBIDDEN in comments.
-
-## Modes
-
-- **interactive** (default): stops at the Phase 4 gate when there are blocking/important findings; asks before committing/PR when appropriate.
-- **`autopilot`**: no prompts  -  auto-fix accepted blocking/important findings, auto-commit/push/PR, auto-post the Jira comment. Mirrors `local-autopilot`.
-
-## Required: outward-facing payload contracts
-
-Before writing anything outward-facing  -  PR body, Jira comment, Confluence page, closing report  -  load `$HOME/.claude/multi-agent-refs/payload-contracts.md`. It names the canonical section set for each payload, the markup dialect per surface (PR body is Markdown, Jira is wiki markup  -  mixing them is a defect), and the token/duration numbers the closing report must carry. Improvising a payload shape from memory is the most common failure of the short modes.
-
-## Required: Phase Tracker Contract
-
-**The phase tracker is required.** Full spec: [`$HOME/.claude/multi-agent-refs/tracker-contract.md`]($HOME/.claude/multi-agent-refs/tracker-contract.md). `ship` registers its active phase set  -  `0:Init 3:Review 4:Commit 5:Report`  -  but NEVER resets a tracker that an earlier run already built (load-or-continue; contract section "Continuation runs"):
-
-```bash
-# Phase 0, first shell call (every CLI). init ONLY when no prior state exists -
-# a task handed off from the user test inside Phase 3 ("awaiting local test")
-# keeps its full phase 0-2 history (elapsed, tokens, USD).
-STATE="$HOME/.claude/logs/multi-agent/${TASK_ID}/tracker-state.json"
-if [ ! -f "$STATE" ]; then
-  bash $HOME/.claude/scripts/phase-tracker.sh init "$TASK_ID"
-fi
-for p in "0:Init" "3:Review" "4:Commit" "5:Report"; do
-  bash $HOME/.claude/scripts/phase-tracker.sh add "${p%%:*}" "${p#*:}"   # idempotent: existing phases keep their history
-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> [cached]
-```
-
-**Continuation path (prior state existed):** (1) if Phase 3 was left `in_progress` with `Now: awaiting local test (user)`, mark it `update 3 completed` + `meta 3 Result "local test done (user)"` before finish's own work (finish re-opens it with `update 3 in_progress` when its Verify gate runs; elapsed keeps the original `started_at`, which is expected); (2) print ONE line in `outputLanguage` summarizing the inherited history, e.g. `Continuing PROJ-12345: phases 0-3 finished earlier (12m, 38.4k tok, ~$0.74)` (USD via `phase-tracker.sh cost total`); (3) `render`.
-
-### Visual channel  -  Claude Code (native TaskList widget, required)
-
-Fresh state: register one tile per phase in strict phase-number order (`0 → 4 → 5 → 6 → 7`) BEFORE any TaskUpdate, capture each `taskId`, persist via `phase-tracker.sh meta <N> tasklist_id "<taskId>"`, then flip status with `TaskUpdate` at each boundary. Out-of-order TaskCreate scrambles the tile stack. Full contract: `$HOME/.claude/multi-agent-refs/tracker-contract.md` "TaskCreate ordering (strict)".
-
-Continuation: rebuild the FULL TaskList from the state file (completed 0-3 tiles included) in phase order before any `TaskUpdate`, refreshing every `tasklist_id` meta  -  same as the contract's "Resume behaviour".
-
-### Visual channel  -  Copilot CLI / plain shell
-
-No TaskList widget. After every state change call `bash $HOME/.claude/scripts/phase-tracker.sh render` (prints the bordered ANSI phase table as the last tool result). Do NOT call TaskCreate on these CLIs.
-
-## Examples
-
-```bash
-/multi-agent:local "PROJ-12345"         # develop locally, then answer Short at the depth question
-# ... you inspect / hand-test the change ...
-/multi-agent:resume-local                        # now: review + build/test + PR + Jira analysis & test scenarios
-```

package/pipeline/commands/security-review.md

@@ -1,6 +0,0 @@
----
-description: Deep security audit on iOS project code
-allowed-tools: Read, Glob, Grep, Agent, Bash(git:*), Bash(grep:*)
----
-
-Alias for Phase 4 Reviewer 1 (Opus + security-auditor agent). Invocation: `/multi-agent:review` then select security focus; or invoke directly via Agent tool with subagent_type=security-auditor.

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

@@ -1,41 +0,0 @@
----
-name: multi-agent-local
-language: en
-description: "Full pipeline in local mode  -  no worktree, runs directly on the current branch. Use when the full pipeline should run on the current branch without creating a worktree."
-user-invocable: true
----
-
-# multi-agent local  -  Full Pipeline, Local Branch
-
-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
-
-- You do not want an extra open worktree  -  if an editor/IDE is open in the same folder, it is not disrupted
-- You are already on the correct branch and just want to apply the pipeline discipline
-- Small project / prototype  -  worktree overhead is unnecessary
-
-## When NOT to use it
-
-- Multiple tasks in parallel at the same time  -  worktree isolation is lost
-- Multi-repo task  -  `--local` locks to a single repo
-
-## Pipeline
-
-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
-
-Delegates to the orchestrator skill (`multi-agent/SKILL.md`) with the `--local` flag. The Phase 0 Step 6 worktree step is skipped; all other phase contracts apply as is (Plan Approval Gate, three-reviewer review, triage, secret scan, PR creation).
-
-## Examples
-
-```bash
-multi-agent-local "PROJ-12345"                                 # Jira
-multi-agent-local "#42"                                        # GitHub issue
-multi-agent-local "LoginView dark mode fix"                    # Free-text
-```
-
-## Required: outward-facing payload contracts
-
-Before writing anything outward-facing  -  PR body, Jira comment, Confluence page, closing report  -  load `$HOME/.claude/multi-agent-refs/payload-contracts.md`. It names the canonical section set for each payload, the markup dialect per surface (PR body is Markdown, Jira is wiki markup  -  mixing them is a defect), and the token/duration numbers the closing report must carry. Improvising a payload shape from memory is the most common failure of the short modes.

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

@@ -1,55 +0,0 @@
----
-name: multi-agent-local-autopilot
-language: en
-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)'
----
-
-# multi-agent-local-autopilot  -  Full Pipeline, Local Branch, Autonomous
-
-**Input**: $ARGUMENTS
-
-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 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.
-
-## What changes
-
-- 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 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
-
-- 🔴 Review blocking → Automatic fix + rebuild (max 3 retries)
-- 💥 Build fail → Automatic fix + rebuild (max 3 retries, then pause)
-- 🛡️ Safety classifier pause → manual confirmation when a high-risk plan is detected
-- ⚠️ Kill/Purge → Always asks for confirmation (destructive)
-
-## Examples
-
-```bash
-multi-agent-local-autopilot "PROJ-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"
-```
-
-## 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-1-plan.md` Step 5 (gate skip) + Step 5c (safety classifier, v7.0.0+).
-
-## Required: outward-facing payload contracts
-
-Before writing anything outward-facing  -  PR body, Jira comment, Confluence page, closing report  -  load `$HOME/.claude/multi-agent-refs/payload-contracts.md`. It names the canonical section set for each payload, the markup dialect per surface (PR body is Markdown, Jira is wiki markup  -  mixing them is a defect), and the token/duration numbers the closing report must carry. Improvising a payload shape from memory is the most common failure of the short modes.

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

@@ -1,51 +0,0 @@
----
-name: multi-agent-resume-local
-language: en
-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
----
-
-# multi-agent resume-local  -  Take Existing Branch Work Through the Pipeline Tail
-
-You already wrote (and maybe hand-tested) the change on the current branch, or committed it outside the pipeline entirely. `ship` picks up from there and runs the **pipeline tail** over that existing work in one command, without re-developing. (As of v14.0.0 a Short run reviews its own output, so this is for work with no pipeline run behind it.)
-
-## Pipeline
-
-```
-Phase 0: Init          → project/branch detect, resolve base + diff (work already done), Jira id, state (NO worktree)
-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-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
-
-- After a `:local` run answered Short (which skips Review + Test) to run the full quality tail on the same branch.
-- After hand-coding / hand-testing a change, to get review + build/test + PR + Jira write-up without re-running dev.
-
-## When NOT to use it
-
-- Change not written yet → `multi-agent` / `multi-agent:local`.
-- Only the review → `multi-agent:review`; only report/channels → `multi-agent:channels`; only device UI test → `multi-agent:test` / `multi-agent:manual-test`.
-
-## Input
-
-```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 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
-```
-
-## Notes
-
-- Build+Test is the automated success gate (not the interactive device user-test  -  that is `multi-agent:manual-test`). If the repo has no tests, it reports "no tests present"  -  never fabricates results.
-- Commit/PR follows house rules: conventional message, `Ref: #N` (never Closes/Fixes), NO AI/bot attribution. PR opened only if one does not already exist.
-- Full phase contract lives in the Claude Code command `commands/multi-agent/ship/SKILL.md`; this skill is the Copilot-CLI counterpart.
-
-## Required: outward-facing payload contracts
-
-Before writing anything outward-facing  -  PR body, Jira comment, Confluence page, closing report  -  load `$HOME/.claude/multi-agent-refs/payload-contracts.md`. It names the canonical section set for each payload, the markup dialect per surface (PR body is Markdown, Jira is wiki markup  -  mixing them is a defect), and the token/duration numbers the closing report must carry. Improvising a payload shape from memory is the most common failure of the short modes.