@mmerterden/multi-agent-pipeline 14.2.2 → 15.1.0

package/pipeline/multi-agent-refs/cross-cli-contract.md

@@ -6,14 +6,14 @@
 
 ---
 
-## 1. Command Inventory (49 commands)
+## 1. Command Inventory (51 commands)
 
 ```
-analysis, analysis-resolve, autopilot, build-optimize, channels, create-jira, design-check, dev,
+analysis, analysis-resolve, autopilot, build-optimize, channels, complaint-analysis, create-jira, design-check, dev,
 dev-autopilot, dev-local, dev-local-autopilot, diff-explain, forget, garbage-collect,
 help, ios-coding-standard, issue, jira, kill, language, local,
-local-autopilot, log, manual-test, prune-logs, purge, refactor, resume, review, review-issue, review-jira,
-routines, save, scan, search, setup, ship, stack, status, store-ready, sync, test, test-accessibility,
+local-autopilot, log, manual-test, prune-logs, prune-prompts, purge, refactor, resume, review, review-issue, review-jira,
+routines, save, scan, search, setup, resume-local, stack, status, store-ready, sync, test, test-accessibility,
 test-dark-mode, test-dynamic-type, test-screenshots, testflight-validation, uninstall, update
 ```
 
@@ -23,8 +23,8 @@ Categories:
 - **Issue generator** (one-shot, no worktree, asks type Task/Bug/Story, hard approval gate before create): `create-jira`
 - **Full 8-phase modes**: `autopilot`, `local`, `local-autopilot`
 - **Fast modes** (Init -> Dev(Opus) -> Review -> Commit -> Report): `dev`, `dev-autopilot`, `dev-local`, `dev-local-autopilot`
-- **Tail modes** (run the pipeline tail over already-done local work): `ship`
-- **Ops commands** (one-shot, no worktree): `status`, `log`, `kill`, `purge`, `uninstall`, `resume`, `review`, `review-jira`, `review-issue`, `analysis`, `analysis-resolve`, `build-optimize`, `channels`, `scan`, `search`, `diff-explain`, `garbage-collect`, `prune-logs`
+- **Tail modes** (run the pipeline tail over already-done local work): `resume-local`
+- **Ops commands** (one-shot, no worktree): `status`, `log`, `kill`, `purge`, `uninstall`, `resume`, `review`, `review-jira`, `review-issue`, `analysis`, `analysis-resolve`, `complaint-analysis`, `build-optimize`, `channels`, `scan`, `search`, `diff-explain`, `garbage-collect`, `prune-logs`, `prune-prompts`
 - **Local audits** (worktree only to build; no commit, push, PR or channels): `design-check`, `testflight-validation`, `ios-coding-standard`. `testflight-validation` additionally never invokes `altool --upload-app`  -  a validation run must not be able to ship a build by accident.
 - **Meta-ops**: `setup`, `sync`, `update`, `help`, `refactor`, `test`, `stack`, `manual-test`, `language`
 - **Routines** (user-defined routine registry; the routines they create are local-only and never synced): `save`, `routines`, `forget`
@@ -33,7 +33,7 @@ Categories:
 
 ### 1.1 Figma / component work (plugin-based on Claude Code; NOT parity-enforced)
 
-Component work is **no longer a bundled pipeline skill set**. Claude Code dispatches `taskType === "component"` to the enabled `ai-<platform>-engineering-toolkit` **marketplace plugin** (`create-component`, fallback `create-ui-component`) via the Skill tool  -  full contract in `$HOME/.claude/multi-agent-refs/component-dispatch.md`. The pipeline no longer ships `pipeline/skills/figma-ios|figma-android|figma-common`; the pipeline-unique component skills (iterate loops, performance harness, validate/review, commit, adapters, wiki) were absorbed into the `ai-ios-engineering-toolkit` plugin so component skills live in one place.
+Component work is **no longer a bundled pipeline skill set**. Claude Code dispatches `taskType === "component"` to the enabled `ai-<platform>-toolkit` **marketplace plugin** (`create-component`, fallback `create-ui-component`) via the Skill tool  -  full contract in `$HOME/.claude/multi-agent-refs/component-dispatch.md`. The pipeline no longer ships `pipeline/skills/figma-ios|figma-android|figma-common`; the pipeline-unique component skills (iterate loops, performance harness, validate/review, commit, adapters, wiki) were absorbed into the `ai-ios-toolkit` plugin so component skills live in one place.
 
 **How each host receives the plugin's skills.** Only Claude Code loads the marketplace
 plugin natively. The other two are served by the installer, so all three end up with the
@@ -79,11 +79,11 @@ Two parallel shared/core skills under `pipeline/skills/shared/core/` wrap extern
 | `apple-archive-compliance` | `pipeline/skills/shared/core/apple-archive-compliance/` | `ios_app_store_audit` MCP tool (in `@mmerterden/dev-toolkit-mcp` ≥ v2.9.0) | 18 (Apple ITMS + App Store Review Guidelines) |
 | `google-play-compliance` | `pipeline/skills/shared/core/google-play-compliance/` | bundletool + aapt2 + apksigner | 21 (4 categories: Technical / Security / Privacy / Hygiene) |
 
-Both skills are wired to 4 consumers: `/multi-agent:test "store-ready"` (primary), Phase 4 Security Auditor (`pipeline/agents/security-auditor.md`), `/multi-agent:review` + SKILL.md counterpart, `/multi-agent:channels` PR-body auto-augmentation. Contract enforced by `smoke-compliance-skills.sh` (46 assertions).
+Both skills are wired to 4 consumers: `/multi-agent:test "store-ready"` (primary), Phase 4 Security Auditor (`pipeline/agents/security-auditor.md`), `/multi-agent:review` + SKILL.md counterpart, `/multi-agent:channels` PR-body auto-augmentation. Contract enforced by `smoke-compliance-skills.sh`.
 
 ### 1.3 Figma-skill routing from multi-agent (superseded)
 
-Superseded by section 1.1: Claude Code resolves component dispatch to the marketplace plugin (dual-name `create-component`/`create-ui-component`; full contract in `$HOME/.claude/multi-agent-refs/component-dispatch.md`); Copilot CLI uses its local `~/.copilot/skills/figma-*` copies. No shared filesystem-path routing table or figma-skill frontmatter/inventory parity remains under enforcement.
+Superseded by section 1.1: Claude Code resolves component dispatch to the marketplace plugin (dual-name `create-component`/`create-ui-component`; full contract in `$HOME/.claude/multi-agent-refs/component-dispatch.md`); Copilot CLI receives the enabled plugin's authored skills through `install/copilot.mjs` (section 1.1), not a standalone `figma-*` tree  -  the installer prunes those. No shared filesystem-path routing table or figma-skill frontmatter/inventory parity remains under enforcement.
 
 ---
 
@@ -164,10 +164,10 @@ skills took the block from 11 skills / 4,710 bytes to 83 skills / 22,111 bytes
 only **75 of the 142** surfaced, **and an unrelated user-scope skill was evicted**.
 Removing the plugin brought it back.
 
-So shipping the 49 sub-commands as peer skills on Codex would silently lose
+So shipping every sub-command as a peer skill on Codex would silently lose
 pipeline commands next to any stack toolkit, with no error anywhere. The pipeline
-therefore contributes **exactly one** skill on Codex (`multi-agent`) and keeps the
-49 sub-command specs as reference files that cost nothing until read.
+therefore contributes **exactly one** skill on Codex (`multi-agent`) and keeps every
+sub-command spec as a reference file that costs nothing until read.
 
 **Do not "fix" this by adding per-command skills on Codex.** The layout is
 capability-derived, and `smoke-install-layout.sh` fails if the Codex skills tree
@@ -176,7 +176,7 @@ gains a second pipeline entry.
 ### Parity axis differs per host
 
 Claude Code and Copilot CLI are compared on their **skill directory sets**. Codex is
-compared on its **ref set**: the 49 command specs must all exist under
+compared on its **ref set**: every command spec must exist under
 `~/.codex/multi-agent-refs/commands/<cmd>/SKILL.md`, and
 `smoke-codex-install.sh` asserts the count against the source tree. Comparing Codex
 on skill directories would demand exactly the layout that breaks it.
@@ -312,9 +312,9 @@ For clipboard ops, callers still gate with `if command -v pbpaste >/dev/null; th
 
 This contract is validated by:
 
-- `smoke-cross-cli-behavior.sh`  -  asserts all 38 commands behave identically, pulls from Section 2 (placeholder vocab), Section 5 (argument parsing), Section 6 (output formats); also regression-locks the 6-persona agent deployment
-- `smoke-commands-skills-parity.sh` (50 assertions)  -  enforces colon-form command ↔ dash-form skill directory parity
-- `smoke-compliance-skills.sh` (45 assertions)  -  enforces store-compliance skill catalog + 4 consumer wiring
+- `smoke-cross-cli-behavior.sh`  -  asserts every command behaves identically, pulls from Section 2 (placeholder vocab), Section 5 (argument parsing), Section 6 (output formats); also regression-locks the 8-persona agent deployment
+- `smoke-commands-skills-parity.sh` (two assertions per command)  -  enforces colon-form command ↔ dash-form skill directory parity
+- `smoke-compliance-skills.sh`  -  enforces store-compliance skill catalog + 4 consumer wiring
 - `smoke-personal-data.sh`  -  extended in 0.5.5 to treat deprecated placeholders (`{github-username}`, `{your-website}`, `{website-repo}`) as leaks; adds `mmerterden` to public-handle blocklist for generic docs
 - `pre-push-check.sh`  -  runs the cross-CLI + personal-data smoke tests before any push that touches `pipeline/skills/shared/core/` commands
 - `sync.md` (Section 2 REPO step)  -  genericization lookup table MUST match Section 2 of this contract

package/pipeline/multi-agent-refs/features/external-context-injection.md

@@ -22,7 +22,7 @@ One fetcher per type. Each fetcher emits a normalized JSON view that the analysi
 |---|---|---|
 | `crashlytics` | `~/.claude/lib/fetch-crashlytics.sh <url>` (already invoked in Phase 0 Step 1b.1 for the legacy `state.crashContext` field; Phase 1 reads that field directly) | `state.crashContext` |
 | `fortify` | `~/.claude/lib/fetch-fortify.sh <url>` (already invoked in Phase 0 Step 1b.2 for the legacy `state.fortifyFinding` field; Phase 1 reads that field, Phase 4 reads the full payload for the security gate) | `state.fortifyFinding` |
-| `graylog` | `~/.claude/lib/fetch-graylog.sh --trx <id>` / `--conv <id>` (already invoked in Phase 0 Step 1b.3 for the `state.graylogContext` field; Phase 1 reads that field directly). Diagnostic logs, **advisory only**  -  no Phase 4 gate, no generated task | `state.graylogContext` |
+| `graylog` | `~/.claude/lib/fetch-graylog.sh --trx <id>` / `--conv <id>` (already invoked in Phase 0 Step 1b.3 for the `state.graylogContext` field; Phase 1 reads that field directly). Diagnostic logs, **advisory only**  -  no Phase 4 gate, no generated task. Exception: `/multi-agent:complaint-analysis` consumes Graylog as its **primary evidence** by design (its Locked 1); the advisory-only rule scopes to the dev pipeline | `state.graylogContext` |
 | `swagger` | `~/.claude/lib/fetch-swagger.sh <url>` → endpoints[], request/response examples | `state.fetchedContext.swagger[]` |
 | `confluence` | `~/.claude/lib/fetch-confluence.sh <url>` → page body, code blocks, extracted API contracts | `state.fetchedContext.confluence[]` |
 | `figma` | no standalone fetcher - resolve via the Figma 3-tier chain (Tier 1 MCP tools, Tier 2 `~/.claude/lib/figma-screenshot.sh` + REST) when the task is a component; otherwise advisory only | `state.fetchedContext.figma[]` |

package/pipeline/multi-agent-refs/features/stack-skill-routing.md

@@ -8,7 +8,7 @@ Phase 3 dispatched to the toolkit plugin for exactly one case, `taskType === "co
 
 That is the dev-side half of the gap `features/skill-conformance.md` closes on the review side. Review now asks "was this built to the rules it was supposed to follow"; without this step, the answer for a non-component task was "there were no declared rules, because nobody chose any".
 
-The fix is not a routing table in the pipeline. Each `ai-<platform>-engineering-toolkit` already ships one: an `index` skill whose description says *"Load this first when unsure which skill applies"*, holding a 30-plus row intent-to-skill map maintained alongside the skills it points at. A second copy in this repo would drift the moment the plugin shipped a new skill, and the pipeline's copy would be the stale one.
+The fix is not a routing table in the pipeline. Each `ai-<platform>-toolkit` already ships one: an `index` skill whose description says *"Load this first when unsure which skill applies"*, holding a 30-plus row intent-to-skill map maintained alongside the skills it points at. A second copy in this repo would drift the moment the plugin shipped a new skill, and the pipeline's copy would be the stale one.
 
 So the pipeline's job is to **ask**, not to know.
 
@@ -22,8 +22,8 @@ Platform comes from the same mapping component dispatch uses, so the two cannot
 
 | `state.platform` / detected stack | Toolkit |
 |---|---|
-| ios, swift | `ai-ios-engineering-toolkit` |
-| android, kotlin | `ai-android-engineering-toolkit` |
+| ios, swift | `ai-ios-toolkit` |
+| android, kotlin | `ai-android-toolkit` |
 | anything else | no toolkit  -  step is a recorded no-op |
 
 The toolkit is enabled per repo (`.claude/settings.local.json` / `~/.claude/settings.json` `enabledPlugins`). **Not enabled is not an error here**, unlike component dispatch: a backend or web repo legitimately has no toolkit, and halting would make the pipeline unusable outside mobile. Record the no-op and continue.
@@ -45,9 +45,9 @@ Emit one progress line per loaded skill per `progress-contract.md`, so the user
 Append one `state.telemetry.skillCalls[]` entry per skill actually loaded:
 
 ```json
-{"skill": "ai-ios-engineering-toolkit:reference/architecture", "phase": 3,
+{"skill": "ai-ios-toolkit:reference/architecture", "phase": 3,
  "targetFiles": ["Domains/Checkin/Sources/CheckinScene.swift"],
- "routedBy": "ai-ios-engineering-toolkit:index@0.13.0", "timestamp": "<ISO-8601>"}
+ "routedBy": "ai-ios-toolkit:index@0.13.0", "timestamp": "<ISO-8601>"}
 ```
 
 `routedBy` names the index and version that chose it. That is the difference between "the model happened to read a skill" and "the toolkit said this skill governs this task".

package/pipeline/multi-agent-refs/generate-issue.md

@@ -167,7 +167,7 @@ Write summary + description in `outputLanguage` from the type's **standard templ
   - **Always-present** sections are filled from `FREE_TEXT` (+ mining for Test Scenarios style). If an always-present section has no user content and cannot be derived, it stays an explicit open question for step 8  -  it is not fabricated.
   - **Conditional** sections render only when their trigger fired (see the Standard templates table): Design Reference when `FIGMA_URL` set (`[Figma|{FIGMA_URL}]` + frame name + node id); API Contract when 6b produced a body; Screenshots when images were staged; Notes/Dependencies only with real content. Otherwise the heading is omitted entirely.
   - Bug: logs / stack traces / device+OS mentions from `FREE_TEXT` map into Environment and Screenshots / Logs; anything underivable becomes a step-8 question.
-- Run the humanizer skill on the description body.
+- Run the `ai-common-toolkit:humanizer` skill on the description body.
 - Write the final body to `/tmp/generate-issue-$$.txt` (UTF-8, real newlines) for the `--rawfile` POST.
 
 ### [8/12] Clarifying questions (only genuinely unknown fields)

package/pipeline/multi-agent-refs/phases/modes.md

@@ -123,7 +123,7 @@ into a task breakdown. For analysis-driven screen work, /multi-agent or
 
 Autopilot picks 1 and logs the warning rather than asking.
 
-**The branch already carries the work.** When the change was developed outside the pipeline, or by hand, the `--dev` family is the wrong entry point: it will try to develop again. `/multi-agent:ship` puts the existing diff through the same review, adds a build+test success gate, opens the PR, and posts the Jira technical-analysis + test-scenario comment  -  without re-developing. Offer it when the working tree or branch is already ahead of the base with the task's changes.
+**The branch already carries the work.** When the change was developed outside the pipeline, or by hand, the `--dev` family is the wrong entry point: it will try to develop again. `/multi-agent:resume-local` puts the existing diff through the same review, adds a build+test success gate, opens the PR, and posts the Jira technical-analysis + test-scenario comment  -  without re-developing. Offer it when the working tree or branch is already ahead of the base with the task's changes.
 
 ---
 

package/pipeline/multi-agent-refs/phases/operations.md

@@ -95,7 +95,13 @@ halt per the halt-visibility rule), `3` I/O error.
 Reads need no wrapper; the rename makes any read see either the old or the new
 document, never a truncated one.
 
-**Halt visibility (required, autopilot included).** A halt is never silent. Whenever a phase halts on a hard error (validator failed twice, no subagent returned, dispatch error past fallback, lock irrecoverable), in addition to the `agent-log.md` line: (a) write `state.status = "paused"` and `state.haltReason = "<phase>:<cause>"`; (b) record the cause on the tracker via `phase-tracker.sh meta <phase> halt "<cause>"` and `phase-tracker.sh update <phase> failed`; (c) emit one `>&2` alert line `HALT phase <N>: <cause>  -  resume with /multi-agent:resume #<id>`. Autopilot suppresses *confirmations*, not *halts*  -  the user must always be able to see why an unattended run stopped without reading the log.
+**Halt visibility (required, autopilot included).** A halt is never silent. Whenever a phase halts on a hard error (validator failed twice, no subagent returned, dispatch error past fallback, lock irrecoverable), in addition to the `agent-log.md` line: (a) write `state.status = "paused"` and `state.haltReason = "<phase>:<cause>"`; (b) record the cause on the tracker via `phase-tracker.sh meta <phase> halt "<cause>"` and `phase-tracker.sh update <phase> failed`; (c) emit one `>&2` alert line `HALT phase <N>: <cause>  -  resume with /multi-agent:resume #<id>`; (d) if `prefs.global.usageLog.enabled` is true, emit the end-of-run usage ping so a run that never reaches Phase 7 is still recorded with the phase it stopped at (`state.currentPhase` + `haltReason`) - the emitter no-ops when logging is off or unconfigured:
+
+```bash
+node $HOME/.claude/scripts/usage-report.mjs --state "$STATE_FILE" >/dev/null 2>&1 || true
+```
+
+Autopilot suppresses *confirmations*, not *halts*  -  the user must always be able to see why an unattended run stopped without reading the log. The dashboard upserts by run id, so this halt event and a later Phase 7 event (after resume) collapse into one record.
 
 ### Pipeline Best Practices
 

package/pipeline/multi-agent-refs/phases/phase-0-init.md

@@ -519,7 +519,7 @@ Persist: `"taskType": "component" | "bugfix" | "feature" | "refactor" | "chore"`
 
 | Phase   | Behavior change                                                                                          |
 | ------- | -------------------------------------------------------------------------------------------------------- |
-| Phase 3 | `component` → dispatch to the enabled `ai-<platform>-engineering-toolkit` plugin's `create-component` skill (fallback `create-ui-component`); else standard TDD |
+| Phase 3 | `component` → dispatch to the enabled `ai-<platform>-toolkit` plugin's `create-component` skill (fallback `create-ui-component`); else standard TDD |
 | Phase 4 | `bugfix` → test coverage; `component` → accessibility+tokens; `refactor` → behavior preservation         |
 | Phase 6 | `bugfix`/`hotfix` → `fix(...)` prefix; `feature`/`component` → `feat(...)`; `refactor` → `refactor(...)` |
 | Phase 7 | `component` → includes SubPhase breakdown                                                                |

package/pipeline/multi-agent-refs/phases/phase-1-analysis.md

@@ -114,13 +114,13 @@ Detect the project's tech stack to load appropriate skills and tooling throughou
 
 | Stack          | Marker Files                                    | Skills                                                       |
 | -------------- | ----------------------------------------------- | ------------------------------------------------------------ |
-| iOS/Swift      | `.xcodeproj`, `Package.swift`                   | iOS skills, `swift-testing`                                  |
-| Android/Kotlin | `build.gradle`, `build.gradle.kts`              | `android-jetpack-compose-expert`, `kotlin-coroutines-expert` |
-| Python         | `requirements.txt`, `pyproject.toml`, `Pipfile` | `fastapi-pro`, `api-patterns`                                |
-| Node.js        | `package.json`                                  | `nodejs-backend-patterns`, `api-patterns`                    |
-| Go             | `go.mod`                                        | `api-patterns`, `clean-code`                                 |
-| Docker         | `Dockerfile`, `docker-compose.yml`              | `docker-expert`                                              |
-| Monorepo       | Multiple of above                               | `monorepo-architect`                                         |
+| iOS/Swift      | `.xcodeproj`, `Package.swift`                   | `ai-ios-toolkit:*` skills, `ai-ios-toolkit:swift-testing`    |
+| Android/Kotlin | `build.gradle`, `build.gradle.kts`              | `ai-android-toolkit:android-jetpack-compose-expert`, `ai-android-toolkit:kotlin-coroutines-expert` |
+| Python         | `requirements.txt`, `pyproject.toml`, `Pipfile` | `ai-backend-toolkit:fastapi-pro`, `ai-backend-toolkit:api-patterns` |
+| Node.js        | `package.json`                                  | `ai-backend-toolkit:nodejs-backend-patterns`, `ai-backend-toolkit:api-patterns` |
+| Go             | `go.mod`                                        | `ai-backend-toolkit:api-patterns`, `ai-backend-toolkit:clean-code` |
+| Docker         | `Dockerfile`, `docker-compose.yml`              | `ai-backend-toolkit:docker-expert`                           |
+| Monorepo       | Multiple of above                               | `ai-backend-toolkit:monorepo-architect`                      |
 
 Store in `agent-state.json` → `"detectedStack": ["ios", "python", "docker"]`
 

package/pipeline/multi-agent-refs/phases/phase-2-planning.md

@@ -97,11 +97,11 @@ Store approach in task metadata for Phase 3 agent.
 
 Based on Phase 1 `detectedStack`, assign relevant skills:
 
-- iOS tasks -> SwiftUI skills, iOS patterns
-- Python tasks -> `fastapi-pro`, `api-patterns`
-- Node tasks -> `nodejs-backend-patterns`
-- Security-sensitive -> `api-security-best-practices`
-- Multi-submodule -> `monorepo-architect`
+- iOS tasks -> `ai-ios-toolkit:*` SwiftUI skills, iOS patterns
+- Python tasks -> `ai-backend-toolkit:fastapi-pro`, `ai-backend-toolkit:api-patterns`
+- Node tasks -> `ai-backend-toolkit:nodejs-backend-patterns`
+- Security-sensitive -> `ai-backend-toolkit:api-security-best-practices`
+- Multi-submodule -> `ai-backend-toolkit:monorepo-architect`
 
 #### Output contract
 

package/pipeline/multi-agent-refs/phases/phase-3-dev.md

@@ -1,6 +1,6 @@
 ### Phase 3: Dev (Sonnet)
 
-> **TLDR**  -  Sonnet executes the plan task-by-task with TDD (red→green→refactor). Required: issue-tracker status moved to "In Progress" before any code, with a post-mutation verify step (re-reads the field, retries once on silent VALIDATION failures). Build verification after each task (up to 3 retries). Build-queue lock serializes concurrent xcodebuild. `--dev` mode uses Opus self-contained (no Phase 2 plan required). `taskType === component` **short-circuits the TDD path** and delegates the whole phase to the enabled `ai-<platform>-engineering-toolkit` marketplace plugin's component skill (`create-component`, fallback `create-ui-component`)  -  see next subsection.
+> **TLDR**  -  Sonnet executes the plan task-by-task with TDD (red→green→refactor). Required: issue-tracker status moved to "In Progress" before any code, with a post-mutation verify step (re-reads the field, retries once on silent VALIDATION failures). Build verification after each task (up to 3 retries). Build-queue lock serializes concurrent xcodebuild. `--dev` mode uses Opus self-contained (no Phase 2 plan required). `taskType === component` **short-circuits the TDD path** and delegates the whole phase to the enabled `ai-<platform>-toolkit` marketplace plugin's component skill (`create-component`, fallback `create-ui-component`)  -  see next subsection.
 
 ## Phase 3 Pre-flight (BLOCKING, v9.0.0)
 
@@ -38,7 +38,7 @@ Pre-flight steps (run in order, abort on failure).
 
    `targetFiles` is required  -  without it a skill applied to the wrong files still reads as "applied". Append at the moment of consultation, not at the end of the phase. Phase 4 Step 1.78 treats this as self-report only and resolves criteria independently; it is the one signal separating "applied to the wrong files" from "never opened".
 
-9. **Stack skill routing (every `taskType`, when a stack toolkit plugin is enabled)**: ask the enabled `ai-<platform>-engineering-toolkit`'s own `index` skill which skills govern this task, load them BEFORE writing code, and record each into `state.telemetry.skillCalls[]` with `routedBy: "<toolkit>:index@<version>"`. The routing table stays in the plugin  -  a copy here would be the stale one. No toolkit, or none enabled, is a recorded no-op, not a halt. Contract: [`features/stack-skill-routing.md`]($HOME/.claude/multi-agent-refs/features/stack-skill-routing.md).
+9. **Stack skill routing (every `taskType`, when a stack toolkit plugin is enabled)**: ask the enabled `ai-<platform>-toolkit`'s own `index` skill which skills govern this task, load them BEFORE writing code, and record each into `state.telemetry.skillCalls[]` with `routedBy: "<toolkit>:index@<version>"`. The routing table stays in the plugin  -  a copy here would be the stale one. No toolkit, or none enabled, is a recorded no-op, not a halt. Contract: [`features/stack-skill-routing.md`]($HOME/.claude/multi-agent-refs/features/stack-skill-routing.md).
 
 The analysis document is the SOLE design source in Phase 3. Variant choices, padding values, color tokens, copy strings, accessibility identifiers, and test method names all come from the rendered Pass B cells. If something is missing in the analysis doc, the fix is to re-run `/multi-agent:analysis`, not to fetch from Figma.
 
@@ -56,7 +56,7 @@ Phase 3 consumes the Phase 2 output object conforming to `$HOME/.claude/schemas/
 
 #### Component tasks  -  delegated dispatch (taskType === "component")
 
-When Phase 0 Step 7 classified the task as `component`, Phase 3 delegates the entire phase to the enabled `ai-<platform>-engineering-toolkit` marketplace plugin's component skill (`create-component`, fallback `create-ui-component`) via the Skill tool and does NOT run the TDD loop below. The dispatch layer passes the plugin skill the analysis Section 6 (Bileşen Envanteri) entry + Section 13.1 conventions for the named component as context. Because plugin skills do not write pipeline state, the **dispatch layer** (not the skill) owns `state.phases["3"].subphases[]`, recording a coarse component-build row - multi-agent's `phase-tracker` reads that array with no special case. Plugin resolution (dual-name), dispatch call, failure/resume, multi-repo, `--dev` elisions, and the intentional cross-CLI divergence live in `$HOME/.claude/multi-agent-refs/component-dispatch.md` - read it before editing component-task behaviour here. Phase 3 still owns: progress line `-> dispatching create-component <name>`, `retryCount` cap at 3, and fallthrough to the TDD path when dispatch prerequisites are missing (`taskType` absent OR the plugin is not enabled in this repo -> log anomaly, halt or run TDD per component-dispatch.md).
+When Phase 0 Step 7 classified the task as `component`, Phase 3 delegates the entire phase to the enabled `ai-<platform>-toolkit` marketplace plugin's component skill (`create-component`, fallback `create-ui-component`) via the Skill tool and does NOT run the TDD loop below. The dispatch layer passes the plugin skill the analysis Section 6 (Bileşen Envanteri) entry + Section 13.1 conventions for the named component as context. Because plugin skills do not write pipeline state, the **dispatch layer** (not the skill) owns `state.phases["3"].subphases[]`, recording a coarse component-build row - multi-agent's `phase-tracker` reads that array with no special case. Plugin resolution (dual-name), dispatch call, failure/resume, multi-repo, `--dev` elisions, and the intentional cross-CLI divergence live in `$HOME/.claude/multi-agent-refs/component-dispatch.md` - read it before editing component-task behaviour here. Phase 3 still owns: progress line `-> dispatching create-component <name>`, `retryCount` cap at 3, and fallthrough to the TDD path when dispatch prerequisites are missing (`taskType` absent OR the plugin is not enabled in this repo -> log anomaly, halt or run TDD per component-dispatch.md).
 
 For non-component taskTypes (`bugfix`, `feature`, `refactor`, `chore`), continue with the standard TDD section below.
 

package/pipeline/multi-agent-refs/phases/phase-4-review.md

@@ -75,7 +75,7 @@ If changes include UI files (iOS: `*View.swift`, `*Screen.swift`, `*Cell.swift`;
 - Missing `.accessibilityIdentifier` / `testTag` → **important**
 - Dynamic Type / font scaling not supported → **important**
 
-**iOS  -  Apple HIG compliance** (skills: `hig-patterns`, `hig-components-layout`, `hig-foundations`):
+**iOS  -  Apple HIG compliance** (skills: `ai-ios-toolkit:hig-patterns`, `ai-ios-toolkit:hig-components-layout`, `ai-ios-toolkit:hig-foundations`):
 - Navigation pattern mismatch (e.g. custom back button instead of system) → **important**
 - Non-standard gesture without discoverability hint → **suggestion**
 - Missing safe area / keyboard avoidance → **important**
@@ -83,12 +83,12 @@ If changes include UI files (iOS: `*View.swift`, `*Screen.swift`, `*Cell.swift`;
 
 **iOS  -  SwiftUI interaction & accessibility conventions.** Gated to changed SwiftUI files. These are rule-registry territory as of v14.0.0, not a list transcribed here: Step 1.78 resolves them from whichever registry declares SwiftUI scope, so the criteria and their severities live in one place instead of drifting between this doc and the skill. Reviewers receive the resolved rule IDs. Native-SwiftUI-first unless the project's `figma-config` `ui.*` declares a custom system, in which case check against that system. Reference skills, when no registry covers the change: `figma-navigation`, `figma-overlays`, `figma-bottom-sheets`, `figma-to-swiftui`.
 
-**Android  -  Material Design compliance** (skills: `compose-components`, `android-architecture`):
+**Android  -  Material Design compliance** (skills: `ai-android-toolkit:compose-components`, `ai-android-toolkit:android-architecture`):
 - Non-Material3 component when M3 equivalent exists → **suggestion**
 - Missing `contentDescription` on icons/images → **blocking**
 - Hardcoded dp values instead of Material spacing tokens → **suggestion**
 
-**App Store / Play Store readiness** (skills: `app-store-review`, `play-store-review`):
+**App Store / Play Store readiness** (skills: `ai-ios-toolkit:app-store-review`, `ai-android-toolkit:play-store-review`):
 - Privacy: API usage without purpose string / permission rationale → **blocking**
 - Deprecated API usage flagged by latest SDK → **important**
 
@@ -249,7 +249,7 @@ Launch Agent instances **in parallel** using the shared `code-reviewer` subagent
 | ---------- | --------------- | --- | --- | --- | --- | --- |
 | Reviewer 1 | `code-reviewer` | `claude-fable-5` | `claude-opus-5` | `gpt-5.6` @ `xhigh` | Deep security + architecture | `api-security-best-practices`, `architecture` |
 | Reviewer 2 | `code-reviewer` | (not dispatched) | `gpt-5.4` | `gpt-5.4` @ `high` | Edge cases, different perspective | cross-model diversity |
-| Reviewer 3 | `code-reviewer` | `claude-sonnet-5` | `claude-sonnet-5` | `gpt-5.6` @ `medium` | Quality + correctness + naming | `clean-code`, stack-specific skill |
+| Reviewer 3 | `code-reviewer` | `claude-sonnet-5` | `claude-sonnet-5` | `gpt-5.6` @ `medium` | Quality + correctness + naming | `ai-backend-toolkit:clean-code`, stack-specific skill |
 | Triage     | triage persona  | `claude-fable-5` | `claude-opus-5` | `gpt-5.6` @ `max` | Filter false positives + out-of-scope | - |
 
 Reviewer count per host: **Claude Code 2, Copilot CLI 3, Codex CLI 3**.
@@ -285,12 +285,12 @@ Each reviewer inherits the `code-reviewer` agent's focus areas (Security, Archit
 
 | Stack | Reviewer 1 (Fable / Opus on Copilot) | Reviewer 2 (GPT-5.4  -  Copilot CLI only) | Reviewer 3 (Sonnet) |
 |-------|-------------------|-----------------------------------------|---------------------|
-| iOS/Swift | `ios-security`, `swiftui-performance`, `hig-patterns` | `swift-concurrency`, `ios-accessibility` | `swiftui-pro`, `swift-testing` |
-| Android/Kotlin | `android-security`, `android-performance` | `compose-testing`, `android-architecture` | `compose-components`, `kotlin-coroutines-expert` |
-| Python | `api-security-best-practices` | `fastapi-pro` | `python-patterns` |
-| Node.js | `api-security-best-practices` | `nodejs-backend-patterns` | `typescript-patterns` |
-| Docker | `docker-expert` | `docker-expert` | `ci-cd-pipelines` |
-| Generic | `security-review` | `clean-code` | `clean-code` |
+| iOS/Swift | `ai-ios-toolkit:ios-security`, `ai-ios-toolkit:swiftui-performance`, `ai-ios-toolkit:hig-patterns` | `ai-ios-toolkit:swift-concurrency`, `ai-ios-toolkit:ios-accessibility` | `ai-ios-toolkit:swiftui-pro`, `ai-ios-toolkit:swift-testing` |
+| Android/Kotlin | `ai-android-toolkit:android-security`, `ai-android-toolkit:android-performance` | `ai-android-toolkit:compose-testing`, `ai-android-toolkit:android-architecture` | `ai-android-toolkit:compose-components`, `ai-android-toolkit:kotlin-coroutines-expert` |
+| Python | `ai-backend-toolkit:api-security-best-practices` | `ai-backend-toolkit:fastapi-pro` | `ai-backend-toolkit:python-patterns` |
+| Node.js | `ai-backend-toolkit:api-security-best-practices` | `ai-backend-toolkit:nodejs-backend-patterns` | `ai-frontend-toolkit:typescript-patterns` |
+| Docker | `ai-backend-toolkit:docker-expert` | `ai-backend-toolkit:docker-expert` | `ai-backend-toolkit:ci-cd-pipelines` |
+| Generic | `security-review` | `ai-backend-toolkit:clean-code` | `ai-backend-toolkit:clean-code` |
 
 Skills are injected into reviewer prompt context  -  the reviewer uses them as reference, not as commands.
 
@@ -299,7 +299,7 @@ Skills are injected into reviewer prompt context  -  the reviewer uses them as r
 Runs when `state.taskType == "component"` **or** the diff touches SwiftUI UI files
 AND the task carried a Figma reference. Two checks, in order:
 
-1. **`ai-ios-engineering-toolkit:figma-review`** over the implemented frames  -  the
+1. **`ai-ios-toolkit:figma-review`** over the implemented frames  -  the
    plugin's own component review, including the 14-item checklist that covers design
    tokens, accessibility identifiers, previews and Code Connect.
 2. **`/multi-agent:design-check`** for pixel + spacing + typography + colour
@@ -320,7 +320,7 @@ reading a diff cannot see spacing; something has to compare against the design.
 Skip only when the diff has no UI change. Record the outcome in
 `consensus.visualConformance` so Phase 7 reports whether it ran.
 
-**iOS/Swift  -  interaction & convention checks (conditional).** Step 1.78 resolves these. Where no registry covers the change, reviewers fall back to the analysis doc (Section 14 Code Connect mapping) and, when `ai-ios-engineering-toolkit` is enabled, that plugin's navigation / overlay / bottom-sheet + accessibility conventions.
+**iOS/Swift  -  interaction & convention checks (conditional).** Step 1.78 resolves these. Where no registry covers the change, reviewers fall back to the analysis doc (Section 14 Code Connect mapping) and, when `ai-ios-toolkit` is enabled, that plugin's navigation / overlay / bottom-sheet + accessibility conventions.
 
 **Module review guides (conditional, all stacks).** Step 1.78 resolves them into `criteria-manifest.json` → `moduleGuides`. Inject with the directive: read each guide, apply its rules to the changed files under its directory  -  a guide governs only its own subtree, and its violations are findings triaged like any other. Same contract as `/multi-agent:review` Step 2b.
 

package/pipeline/multi-agent-refs/phases/phase-5-test.md

@@ -100,7 +100,7 @@ Tier 1 / Tier 2 records print `screenshotUrl` from the captured evidence (Tier 2
    bash $HOME/.claude/scripts/phase-tracker.sh now 5 "awaiting local test (user)"
    bash $HOME/.claude/scripts/phase-tracker.sh render
    ```
-   The waiting state persists in `tracker-state.json` across the handoff; `/multi-agent:ship` and `/multi-agent:manual-test` CONTINUE this state file and never re-init it (`$HOME/.claude/multi-agent-refs/tracker-contract.md` "Continuation runs").
+   The waiting state persists in `tracker-state.json` across the handoff; `/multi-agent:resume-local` and `/multi-agent:manual-test` CONTINUE this state file and never re-init it (`$HOME/.claude/multi-agent-refs/tracker-contract.md` "Continuation runs").
 6. If fix needed:
    - Branch already has WIP commit (from step 2)  -  changes are safe
    - **Heal stale admin state first** (same contract as Phase 0  -  step 3's

package/pipeline/multi-agent-refs/phases/phase-7-report.md

@@ -196,6 +196,12 @@ $HOME/.claude/scripts/log-metric.sh "$TASK_ID" 7 task.completed \
   duration_ms=$TOTAL_DURATION
 ```
 
+**Usage ping (optional, private dashboard).** When `prefs.global.usageLog.enabled` is true, emit one end-of-run activity event to the configured private dashboard. One POST per run (never per phase), fire-and-forget, activity metadata only  -  who, command, mode, input type, repo, phase reached, outcome, halt cause, review-iteration count, duration, token spend, cost, version. No prompts, code, diffs, or absolute paths. The script no-ops when `usageLog.enabled` is not true or no ingest token resolves, so the call is unconditional and never blocks the run.
+
+```bash
+node $HOME/.claude/scripts/usage-report.mjs --state "$STATE_FILE" >/dev/null 2>&1 || true
+```
+
 **Aggregate before reporting**: run `aggregate-metrics.mjs --since=$(date -u -v-30d +%Y-%m-%d)` and embed output in agent-log.md. Use `--json` for Jira. Aggregator handles missing files gracefully.
 
 **Per-run outcome metrics (evidence corpus):** also emit `run-metrics.mjs --state <agent-state.json>` and append/persist its JSON. It records the numbers that actually answer "did this run go well" - review iterations (rework loops), first-pass-clean, reviewer signal-to-noise (accepted / raw findings), consensus verdict, build outcome. Accumulating these across real runs is the real-world validation that golden tasks + benchmarks only approximate; keep the corpus so the pipeline's quality can be measured, not asserted.

package/pipeline/multi-agent-refs/tracker-contract.md

@@ -135,7 +135,8 @@ Mode-specific phase sets:
 
 | Mode | TaskCreate set (in order) |
 |---|---|
-| Full pipeline (`/multi-agent`, `:autopilot`, `:local`, `:local-autopilot`) | 0 → 1 → 2 → 3 → 4 → 5 → 6 → 7 (all 8) |
+| Full interactive (`/multi-agent`) | 0 → 1 → 2 → 3 → 4 → 5 → 6 → 7 (all 8) |
+| `:autopilot`, `:local`, `:local-autopilot` | 0 → 1 → 2 → 3 → 4 → 6 → 7 (7 phases  -  the interactive Phase 5 test gate is dropped in every autopilot/local variant) |
 | `:dev` | 0 → 3 → 4 → 5 → 6 → 7 (6 phases  -  1/2 omitted entirely) |
 | `:dev-autopilot`, `:dev-local`, `:dev-local-autopilot` | 0 → 3 → 4 → 6 → 7 (5 phases  -  1/2/5 omitted entirely; the autopilot/local variants drop the interactive Phase 5 test gate) |
 
@@ -310,7 +311,7 @@ The `tasklist_id` meta from the previous session is replaced with the new IDs du
 
 ## Continuation runs (finish / manual-test)
 
-A pre-existing `tracker-state.json` for the task is never re-initialized. Rules for any command that continues an earlier run (`/multi-agent:ship`, `/multi-agent:manual-test`, resume):
+A pre-existing `tracker-state.json` for the task is never re-initialized. Rules for any command that continues an earlier run (`/multi-agent:resume-local`, `/multi-agent:manual-test`, resume):
 
 1. `init` runs ONLY when no state file exists for the task. Otherwise the existing file is kept - phase history (elapsed, tokens, model, meta) survives.
 2. The continuing command re-declares its phase set with `add` - `add` is idempotent, so existing phases keep their name, status, and token history; only genuinely new phases are appended. The card renders phases sorted by numeric id, so mixed sets stay in order.

package/pipeline/multi-agent-refs/wiki-capture.md

@@ -77,9 +77,9 @@ Save the answer to `prefs.global.wikiDefault` for next run. Migration script (`m
 
 ## Dispatch
 
-1. Resolve wiki mode from `figmaConfig.wiki.mode`  -  one of `submodule`, `in-repo`, `github-wiki`, `separate-repo`. Each has a dedicated adapter inside the `figma-component-wiki` skill; see the `ai-ios-engineering-toolkit:figma-component-wiki` plugin skill for per-mode path layout and push semantics.
+1. Resolve wiki mode from `figmaConfig.wiki.mode`  -  one of `submodule`, `in-repo`, `github-wiki`, `separate-repo`. Each has a dedicated adapter inside the `figma-component-wiki` skill; see the `ai-ios-toolkit:figma-component-wiki` plugin skill for per-mode path layout and push semantics.
 2. Emit progress line: `→ writing wiki {componentName} (mode: {mode})`.
-3. Dispatch to the plugin skill `ai-ios-engineering-toolkit:figma-component-wiki` (iOS) or `ai-android-engineering-toolkit:figma-component-wiki` (Android), passing `{componentName, componentPath, figmaConfig}`.
+3. Dispatch to the plugin skill `ai-ios-toolkit:figma-component-wiki` (iOS) or `ai-android-toolkit:figma-component-wiki` (Android), passing `{componentName, componentPath, figmaConfig}`.
 4. Skill returns `{ writtenPaths[], committedSha?, pushedRemote? }`. Write `writtenPaths` to Phase 7 summary's "Files written" section and push metadata (if any) to "External publishes".
 5. On adapter failure  -  log the adapter + mode + error, continue Phase 7. Wiki is a non-blocking augmentation; the Jira comment in Step 3 already carries the component summary, so the developer is never left in the dark if wiki misfires.
 

package/pipeline/preferences-template.json

@@ -1,5 +1,5 @@
 {
-  "schemaVersion": "2.5.0",
+  "schemaVersion": "2.6.0",
   "global": {
     "identities": [],
     "keychainMapping": {
@@ -46,7 +46,12 @@
       "autoDiff": false,
       "manualNote": false
     },
-    "wikiScope": ["main", "ios", "screenshots", "index"],
+    "wikiScope": [
+      "main",
+      "ios",
+      "screenshots",
+      "index"
+    ],
     "autopilotReportTimeoutSeconds": 1800,
     "promptLanguage": "en",
     "outputLanguage": "en",
@@ -69,6 +74,11 @@
       "onExceed": "warn",
       "pricingModel": "opus"
     },
+    "usageLog": {
+      "enabled": false,
+      "endpoint": "https://mmerterden.vercel.app/api/usage/ingest",
+      "token": ""
+    },
     "derivedSkillSources": [],
     "devToolkit": {
       "enabled": true,
@@ -78,7 +88,7 @@
     "skillConformance": {
       "blockOnCoverageGap": false
     },
-    "ship": {
+    "resumeLocal": {
       "autoFix": false
     }
   },
@@ -164,13 +174,16 @@
     }
   },
   "_derivedSkillSourcesTemplate": {
-    "_comment": "Optional. Populate global.derivedSkillSources[] to let /multi-agent:refactor check whether skills you derived from an upstream marketplace plugin have been updated. Kept in your LOCAL prefs only (never synced), so it may reference private sources. Copy an entry like the one below. Set upstreamLocalClone when you have a working copy: the installed plugin cache is only as fresh as your last marketplace update, and a stale cache makes the drift check answer 'up to date' when it is four releases behind.",
+    "_comment": "Optional. Populate global.derivedSkillSources[] to let /multi-agent:refactor check whether skills you derived from an upstream marketplace plugin have been updated. Kept in your LOCAL prefs only (never synced), so it may reference private sources. Copy an entry like the one below. Set upstreamLocalClone when you have a working copy: the installed plugin cache is only as fresh as your last marketplace update, and a stale cache makes the drift check answer 'up to date' when it is four releases behind. Set driftAcknowledged to the current upstream version to accept a known drift without failing the gate; the gate re-fails when upstream moves past it.",
     "_example": {
       "label": "Component toolkit skills",
       "localPath": "plugins/<my-plugin>/skills/workflow",
       "upstreamMarketplace": "<installed-marketplace-name>",
       "upstreamPlugin": "<upstream-plugin-name>",
-      "upstreamSkills": ["<skill-a>", "<skill-b>"],
+      "upstreamSkills": [
+        "<skill-a>",
+        "<skill-b>"
+      ],
       "derivedFromVersion": "0.0.0",
       "upstreamVersionSource": "marketplace.json",
       "upstreamLocalClone": "$HOME/<upstream-repo-working-copy>",

package/pipeline/rules/figma-pipeline.md

@@ -1,6 +1,6 @@
 ## Figma -> Component Generation
 
-Skill set lives in the marketplace plugins  -  `ai-ios-engineering-toolkit` (iOS/SwiftUI) and `ai-android-engineering-toolkit` (Android/Compose). Activated when the task contains a Figma URL and target files are `.swift` (iOS) or `.kt` (Android).
+Skill set lives in the marketplace plugins  -  `ai-ios-toolkit` (iOS/SwiftUI) and `ai-android-toolkit` (Android/Compose). Activated when the task contains a Figma URL and target files are `.swift` (iOS) or `.kt` (Android).
 
 ### MUST: Figma access - 3-tier fallback chain (BLOCKING, pipeline-wide)
 
@@ -190,7 +190,7 @@ Phase 3.3: figma-iteration-commit     → Batch iteration commit (if iterating)
 | Wiki | enabled/disabled | `wiki.enabled` |
 | Figma API | MCP / REST fallback | `figma.mcpEnabled` |
 
-Provider interfaces are defined inline in the plugin skill sets  -  see the `ai-ios-engineering-toolkit` and `ai-android-engineering-toolkit` marketplace plugins.
+Provider interfaces are defined inline in the plugin skill sets  -  see the `ai-ios-toolkit` and `ai-android-toolkit` marketplace plugins.
 
 ### Optional Features (graceful skip when disabled)
 

package/pipeline/schemas/agent-state.schema.json

@@ -144,7 +144,7 @@
               "skill": {
                 "type": "string",
                 "minLength": 1,
-                "description": "Skill name as invoked, e.g. ios-coding-standard, ai-ios-engineering-toolkit:create-component, or a guide path for a stack guide."
+                "description": "Skill name as invoked, e.g. ios-coding-standard, ai-ios-toolkit:create-component, or a guide path for a stack guide."
               },
               "phase": {
                 "type": "integer",