@mmerterden/multi-agent-pipeline 19.1.4 → 20.1.0

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

@@ -1,31 +1,67 @@
 ---
 name: multi-agent-resume
 language: en
-description: "Resume a stopped or failed task from the phase where it left off. Use when a task stopped or failed and should carry on from where it left off."
+description: "Pick up unfinished work: a pipeline run that stopped mid-phase, or work already written on the current branch that never went through the pipeline. Use when a task stopped or failed, or when hand-written local work needs review, build, PR and reporting."
 user-invocable: true
-argument-hint: "[#id]  -  optional: task ID (e.g. #2). If omitted, the most recent paused task is used."
+argument-hint: "[#id | PROJ-12345] [--base <branch>] [autopilot]  -  no argument: pick from the list"
 ---
 
-# multi-agent resume  -  Resume Paused Task
+# multi-agent resume  -  Continue Unfinished Work
 
 **Input**: $ARGUMENTS
 
-Resume a paused or failed task from the last successful phase.
+Unfinished work arrives from two directions, and which one applies is a property of the repository, not of how the command was typed:
+
+- **A tracked run stopped.** It has an `agent-state.json`, a phase it was inside, and possibly a worktree. It resumes from where it stopped.
+- **Work exists on the current branch with no run behind it.** Nothing to resume, so the **pipeline tail** runs over the diff. Plan and Dev never run; the diff is the Dev output.
+
+Step 1 finds both and asks, so the user does not have to know which case they are in before asking the question.
+
+## Input
+
+```bash
+multi-agent resume                    # list everything resumable, pick one
+multi-agent resume #2                 # a tracked run by task number
+multi-agent resume PROJ-12345         # a tracked run by Jira id, or bind the tail to that id
+multi-agent resume --base develop     # tail path: override the base branch for the diff
+multi-agent resume autopilot          # no gate prompts: auto-fix, auto-PR, auto-comment
+```
 
 ## Steps
 
-1. **Find task**  -  Parse `#N` from the argument, or find the most recent worktree with `status != "done"`
+1. **Build the resumable list, then ask.** Source A: every `agent-state.json` under `$HOME/.claude/logs/multi-agent/{project}/` with `status != "done"`, each row showing task id, the phase it stopped inside, its workspace (worktree path, or `local`), age, and `haltReason` when set. Source B: the current branch, when `git diff <base>...HEAD` plus working-tree changes is non-empty **and** no Source A run owns that branch. An argument naming a run selects it directly; an argument naming nothing resumable is an error, never a silent fall-through to the tail. Nothing in either source: `ERR: nothing to resume` - do not ask.
+
+   Ask per `$HOME/.claude/multi-agent-refs/picker-contract.md` (Copilot CLI: `$HOME/.claude/lib/ask-choice.sh`). Breadcrumb `Step 1/1: which unfinished work to pick up` above the picker, in `outputLanguage`; labels carry the task id and branch name verbatim, and the run branches on which row was selected rather than on the label text. A single row is still a question and needs a genuine second option: **Show every run** (drops the `status != "done"` filter) when the only row is a stopped run, **Pick a stopped run instead** when the only row is the branch diff.
+
+2. **Tracked run  -  read and validate state.** `validate-state.mjs` first; on non-zero exit do NOT guess a phase. Read `currentPhase`, `status`, `haltReason`, `circuitBreaker`, `autopilot`. Heal a stale worktree lock before continuing  -  unless `worktreeRemovedAt` is set, in which case the artefacts live under `artifactsPath` and the worktree must not be recreated.
+
+3. **Tracked run  -  load context** from durable artifacts, never from conversation memory: the latest `## Handoff` block in `agent-log.md` first, per-phase findings as the fallback, `git log --oneline -10` to ground what was actually committed.
+
+4. **Tracked run  -  rebuild the phase tiles** from `tracker-state.json`, never re-initialized. Copilot CLI: a single `phase-tracker.sh render`.
+
+5. **Tracked run  -  continue.** Read `state.waitingFor` FIRST: when it names a step (`maturity`, `user-channels-choice`, `local-test`), the run re-enters THAT step. `currentPhase + 1` is the fallback, not the rule. Clear `waitingFor` in the same write that records the answer.
+
+6. **Untracked branch work  -  resolve context.** Base branch: `--base` → `figma-config.project.baseBranch` → `develop` → upstream/merge-base. Jira id from the argument or the branch name. State under `$HOME/.claude/logs/multi-agent/{project}/{taskId}/`. No worktree is created.
+
+7. **Untracked branch work  -  run the tail.**
+
+```
+Phase 0: Init          → project/branch detect, base + diff, Jira id, state (NO worktree)
+Phase 3: Review        → the Verify gate first (stack-aware build + existing tests; SUCCESS required), then
+                         parallel review (GPT + Opus + Sonnet) + 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)
+```
+
+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.
 
-2. **Read state**  -  Parse `agent-state.json`:
-   - `currentPhase`  -  last completed phase
-   - `status`  -  `paused` | `failed` | `in_progress`
-   - `autopilot`  -  preserve the mode
+## Notes
 
-3. **Load context**  -  Read the findings of previous phases from `agent-log.md`:
-   - Phase 1 analysis → use in Phase 2+
-   - Phase 1 plan → use in Phase 2+
-   - Phase 3 code → already present in the worktree
+- Build+Test is the automated success gate (the interactive device user-test is `multi-agent:manual-test`). If the repo has no tests, it reports "no tests present"  -  never fabricates results.
+- `autopilot` (or `prefs.global.resume.autoFix == true`) auto-fixes triage-accepted blocking/important findings and re-reviews the fix before advancing.
+- 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/resume/SKILL.md`; this skill is the Copilot-CLI counterpart.
 
-4. **Continue the pipeline**  -  Start from where it left off (same pipeline as the main multi-agent command)
+## Required: outward-facing payload contracts
 
-5. **Log**: `🔄 Resumed PROJ-{id} from Phase {N}`
+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 a run that starts in the middle.

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

@@ -3,7 +3,7 @@ name: multi-agent-scan
 language: en
 description: "Skill security scan: walks local skill directories against a tiered pattern catalog. Use when local skill directories need checking for unsafe or unexpected content."
 user-invocable: true
-argument-hint: "[--strict] [--target <path>]  -  optional: --strict enables CI failure mode, --target picks a custom directory"
+argument-hint: "[--strict] [--root PATH]  -  optional: --strict enables strict exit codes, --root picks a custom directory"
 ---
 
 # multi-agent-scan
@@ -55,7 +55,7 @@ multi-agent-scan --root ~/.copilot/skills
 ## Integration
 
 - **install.js** pre-deploy hook (automatic, warn-only high-threshold)
-- **CI** `.github/workflows/smoke.yml` step (strict)
+- **Smoke suite** `smoke-skill-scan.sh` runs it in strict mode under `npm test`
 - **Standalone** this skill
 
 Cross-CLI parity: `/multi-agent:scan` on Claude Code, `multi-agent-scan` on Copilot CLI. Same source script, same behavior.

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

@@ -0,0 +1,29 @@
+---
+name: multi-agent-security-review
+language: en
+description: "Run a standalone defensive, static security review of a diff, branch or repo: run-scoped threat model, reviewer-shaped findings joined to OWASP + CWE with CVSS scoring, evidence and before/after fixes, plus an offline dependency inventory. No live target, no payloads. Use when reviewing code for security outside a full pipeline run, auditing dependencies, or preparing a branch for a security sign-off."
+user-invocable: true
+argument-hint: "[#N | repo#N | PR-URL | branch | path]  -  a PR, a local branch, or a path to scope the review. If omitted: the current branch diff against its base."
+---
+
+# multi-agent security-review  -  standalone defensive static review
+
+**Input**: `$ARGUMENTS`
+
+The same security audit Phase 3 runs at Step 2.7, invoked on its own. Defensive and static: reads code, config and dependency manifests; never runs the target, fires a payload, or reaches a live host.
+
+## Scope
+
+Resolve from `$ARGUMENTS`, same shapes as `/multi-agent:review`: `#N` / `repo#N` / PR URL → that PR's diff; a branch → its diff against base; a path → files under it; omitted → the current branch diff. Cap the diff as Phase 3 Step 1.9 does.
+
+## Steps
+
+1. **Threat model** - produce `.pipeline/threat-model.md` (four sections) if absent, else read it; mirror to `state.threatModel`. Contract: `threat-model.md`.
+2. **Method** - load `ai-common-toolkit:security-review` for the OWASP walk (Web/API Top 10 2021, Mobile Top 10 2024) + CWE join. This command orchestrates, it does not re-derive the method.
+3. **Findings** - dispatch the `security-auditor`; it returns a `reviewer-output.schema.json` object whose `findings[]` carry the `security` envelope (`security-finding.schema.json`). Score every vector with the toolkit `security_cvss_score`; validate with `validate-reviewer.mjs` (one rework then halt).
+4. **Dependencies** - run `security_dep_inventory` on the lockfiles; hand the inventory to `ai-analyst-toolkit:evidence-registry` for known CVEs when it is registered. A vulnerable dependency is an `A06:2021` finding with the advisory CWE + CVE. This command contacts nothing itself.
+5. **Report** - write `.pipeline/security-findings.json` and a human summary (count by severity; each blocking/important finding with OWASP id, CWE, CVSS band, evidence, before/after fix). An empty list with `approved: true` is a clean review.
+
+## Boundaries
+
+Inside a run the same audit is Phase 3 Step 2.7 (`features/security-audit.md`), triggered by the `security_path` signal; this is the standalone entry point. Not the `store-ready` device pass, not a secret scanner (`pre-commit-check.sh` covers secrets). No writes to Jira / GitHub / Confluence. Autopilot reviews the current branch, writes the report, opens no PR.

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

@@ -32,8 +32,8 @@ Run all steps automatically:
 ```
 Step 0: DOCTOR      node $HOME/.claude/scripts/doctor.mjs  -  exit 2 or 4 STOPS the sync
 Step 1: DETECT      Compare timestamps, find stale targets
-Step 2: COPILOT     Claude Code -> Copilot CLI (instructions + 60 sub-command skills)
-Step 2b: CODEX      Claude Code -> Codex CLI (1 router skill + 60 specs as refs + 8 agent TOML)
+Step 2: COPILOT     Claude Code -> Copilot CLI (instructions + 58 sub-command skills)
+Step 2b: CODEX      Claude Code -> Codex CLI (1 router skill + 57 specs as refs + 8 agent TOML)
 Step 3: REPO        Claude Code -> pipeline repo (genericized, personal data scrub)
 Step 3d: DEV-TOOLKIT Companion MCP server -> detect movement, ship gates, commit + publish
 Step 4: WEBSITE     Version + phase/model counts -> {website-host} (i18n + projects.ts)
@@ -63,7 +63,7 @@ If nothing is stale -> report "All targets up to date" and stop.
    - `copilot-instructions.md`: general development instructions + pipeline summary section
    - `multi-agent-pipeline/pipeline/`: generic open-source version (NO personal data)
 3. **Sync shared sections** (Claude <-> Copilot):
-   - Pipeline entries table (base / :local / :autopilot / :local-autopilot) + the Full-or-Short depth question
+   - Pipeline entries table (base / :autopilot)
    - Project detection (URL-based + cwd-based)
    - Figma pipeline flow
    - Git conventions (author, branch, commit format)
@@ -228,18 +228,18 @@ When invoked with the `release` argument:
 |-------------|-------------|
 | `~/.claude/commands/multi-agent/{cmd}/SKILL.md` | `~/.copilot/skills/multi-agent-{cmd}/SKILL.md` |
 
-**60 commands are synced** (canonical inventory  -  must match `cross-cli-contract.md` section 1; drift = contract violation):
+**58 commands are synced** (canonical inventory  -  must match `cross-cli-contract.md` section 1; drift = contract violation):
 
 ```
 analysis, analysis-jira, analysis-resolve, autopilot, autopilot-off,
 autopilot-on, autopilot-status, build-optimize, channels, complaint-analysis,
 create-jira, design-check, diff-explain, doctor, feedback, forget,
 garbage-collect, graph, help, ios-coding-standard, issue, jira, kill,
-language, local, local-autopilot, log, manual-test, model, prune-logs,
-prune-prompts, purge, refactor, resume, resume-local, review,
+language, log, manual-test, model, prune-logs,
+prune-prompts, purge, refactor, resume, review,
 review-analysis, review-issue, review-jira, route-off, route-on,
 route-status, routines, save, scan, search,
-setup, stack, status, steer, store-ready, sync, test, test-accessibility,
+security-review, setup, stack, status, steer, store-ready, sync, test, test-accessibility,
 test-dark-mode, test-dynamic-type, test-screenshots, testflight-validation,
 uninstall, update
 ```

package/pipeline/skills/shared/external/security-review/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: security-review
+description: "Run a defensive, static security review of a diff or a repo: build a run-scoped threat model, find vulnerabilities joined to OWASP + CWE with CVSS scoring and evidence, and emit reviewer-shaped findings with before/after fixes. Use when reviewing code for security, auditing a dependency set, preparing a release for a security sign-off, or when a diff touches auth, crypto, input handling, networking or secrets."
+risk: low
+source: multi-agent-pipeline
+date_added: "2026-09-21"
+---
+
+# Security Review (defensive, static)
+
+## Overview
+
+A static, read-only security review. It reads code, configuration and dependency manifests and reports vulnerabilities the way the pipeline can act on them: each finding joined to an OWASP category and a CWE, scored with CVSS 3.1, backed by evidence and its counterevidence, and paired with a before/after fix. It never runs the target, fires a payload, or reaches a live host - the posture is defensive and offline. The output is reviewer-shaped, so a blocking finding merges into triage and blocks the commit like any other blocker.
+
+This is stack-neutral. The same method covers a Swift or Kotlin mobile diff, a TypeScript / Python / Go / Java backend, and a web front-end. What changes per stack is the OWASP catalog (Mobile Top 10 for apps, Web/API Top 10 for services and sites) and the sink vocabulary, not the method.
+
+## When to Use This Skill
+
+- Reviewing a diff whose paths touch authentication, authorization, crypto, input handling, networking, deserialization, file access or secrets.
+- Auditing a dependency set for known-vulnerable packages before a release.
+- Preparing a branch for a security sign-off, or answering "is this change safe to ship".
+- Any run where `/multi-agent:security-review` is invoked, or Phase 3 fires the `security_path` signal.
+
+## How It Works
+
+### Step 1: Build the run-scoped threat model
+
+Before any finding, establish the four-section threat model for THIS change and write it to `.pipeline/threat-model.md` (contract: `threat-model.md` in the pipeline refs). Attacker, trust boundaries, attack surface, severity calibration. Every finding's severity is calibrated against it, and a `blocking` finding must trace to a named assumption in it. A diff with no plausible attacker gets a short model and findings that cap at `suggestion`.
+
+### Step 2: Map the surface to a standard
+
+Join every candidate finding to a checkable standard, never a bare opinion:
+
+- **Web / API** - OWASP Top 10 2021 (`references/owasp-web-api-top10-2021.md`), with the CWE most associated with each category.
+- **Mobile** - OWASP Mobile Top 10 2024 (`references/owasp-mobile-top10-2024.md`).
+
+Walk the checklist against the changed surface only. A finding outside the touched surface is out of scope unless the diff made it reachable, and then you say how.
+
+### Step 3: Score with CVSS, and keep the number honest
+
+For each finding, write a CVSS 3.1 base vector and compute the score with the `security_cvss_score` toolkit tool - never by hand, so the score cannot drift from the vector. The band sets the reviewer severity: critical or high -> `blocking`, medium -> `important`, low or none -> `suggestion`.
+
+Every finding carries:
+
+- **evidence** - what in the code proves it, cited by `file:line`. No evidence, no finding.
+- **counterevidence** - what would disprove it, or the condition that makes it a false positive. Blank asserts there is none.
+- **confidence** - `high|medium|low`. Low does not mean silent; it means report with the counterevidence.
+- **severityChangeConditions** - the assumption the score rests on, so a reader disputes the assumption, not the number.
+
+### Step 4: Inventory dependencies (offline)
+
+Run `security_dep_inventory` on the lockfiles in scope to get a normalized `{ecosystem, name, version}` list. Hand that list to a known-CVE lookup (the analyst toolkit's evidence-registry) as a separate step - this skill contacts nothing itself. A vulnerable dependency is `A06:2021` with the advisory's CWE and CVE, on the manifest file at line 0.
+
+### Step 5: Emit reviewer-shaped findings
+
+Emit one object conforming to `reviewer-output.schema.json`, each finding also conforming to `security-finding.schema.json` (the `security` block). Include the before/after fix as `security.remediationDiff`, and `security.fixVerification` naming the empirical check a human or a later dynamic pass would run - static review cannot fire the exploit itself. `approved` is `false` if any finding is `blocking`.
+
+An empty findings list with `approved: true` is the right answer for a clean diff. Do not invent findings to look thorough, and do not raise a theoretical risk with no path from the threat model's attacker above `suggestion`.
+
+## What This Skill Does Not Do
+
+- No live target, no payloads, no exploitation, no proxy, no browser-driven attack. Defensive and static only.
+- No secret scanning of its own: the pipeline already has that surface (`pre-commit-check.sh` / the egress gate, held in parity against `secret-patterns.json`). Call it; do not hand-roll a fourth list.
+- No store-policy audit: that is the separate `store-ready` device pass under `/multi-agent:test`.

package/pipeline/skills/shared/external/security-review/references/owasp-mobile-top10-2024.md

@@ -0,0 +1,53 @@
+# OWASP Mobile Top 10 2024 - review checklist with CWE mapping
+
+The category id (`M1:2024` .. `M10:2024`) goes in a finding's `security.owaspCategory`; the CWE that names the actual weakness goes in `security.cwe`. For the fuller mobile catalog that ties these to MASVS / MASTG and the store-compliance rules, the swift-security compliance mapping is the deeper reference; this is the review checklist.
+
+## M1:2024 - Improper Credential Usage
+
+Check: hardcoded API keys / passwords / tokens, credentials in source or resource files, credentials in logs, a secret shipped in the binary.
+CWEs: CWE-798 (hardcoded credentials), CWE-259, CWE-522.
+
+## M2:2024 - Inadequate Supply Chain Security
+
+Check: a dependency at a version with a known advisory, an unpinned SDK, a build step pulling an unverified artifact. This is the `security_dep_inventory` -> CVE path (`A06:2021`'s mobile analog).
+CWEs: CWE-1104, plus the advisory's CWE.
+
+## M3:2024 - Insecure Authentication/Authorization
+
+Check: auth decided client-side, a token accepted without verification, missing authorization on a sensitive action, biometric gate that only hides UI without protecting data.
+CWEs: CWE-287, CWE-306 (missing authentication), CWE-862, CWE-863.
+
+## M4:2024 - Insufficient Input/Output Validation
+
+Check: untrusted input into a SQL/content-provider query, a WebView `evaluateJavascript` / `postMessage` handler trusting page content, deep-link parameters used without validation, format-string or path built from input.
+CWEs: CWE-20, CWE-79 (WebView XSS), CWE-89, CWE-22.
+
+## M5:2024 - Insecure Communication
+
+Check: HTTP instead of HTTPS, disabled ATS / cleartext-traffic permitted, `TrustManager` that accepts all certs, missing certificate pinning on a sensitive endpoint, ignored TLS errors.
+CWEs: CWE-319 (cleartext), CWE-295 (improper certificate validation).
+
+## M6:2024 - Inadequate Privacy Controls
+
+Check: PII collected without need, location/contacts/identifiers sent off-device without disclosure, tracking before consent, PII in logs or analytics events.
+CWEs: CWE-359, CWE-200, CWE-532.
+
+## M7:2024 - Insufficient Binary Protections
+
+Check: no tamper/integrity check where the threat model needs one, debug symbols or verbose logging left in a release build, an easily-reversible secret embedded in the binary. Judge against the threat model - most apps do not need anti-reversing, and a `blocking` here needs a named attacker.
+CWEs: CWE-656, CWE-489 (debug code left in).
+
+## M8:2024 - Security Misconfiguration
+
+Check: an exported Android component with no permission, `android:debuggable=true` or `allowBackup=true` on sensitive data, an overly-broad entitlement, a permissive `network_security_config`, default or weak settings.
+CWEs: CWE-16, CWE-276 (incorrect default permissions), CWE-926 (improper export).
+
+## M9:2024 - Insecure Data Storage
+
+Check: sensitive data in `UserDefaults` / `SharedPreferences` / plist / plain files instead of the Keychain / Keystore, a database without encryption, a cache holding secrets, pasteboard leakage.
+CWEs: CWE-312 (cleartext storage), CWE-922 (insecure storage of sensitive info).
+
+## M10:2024 - Insufficient Cryptography
+
+Check: weak or deprecated algorithm (MD5/SHA1 for integrity, DES/ECB), a hardcoded key/IV, a home-rolled cipher, a predictable random source for a security purpose.
+CWEs: CWE-327 (broken/risky algorithm), CWE-326, CWE-330 (insufficient randomness), CWE-338.

package/pipeline/skills/shared/external/security-review/references/owasp-web-api-top10-2021.md

@@ -0,0 +1,56 @@
+# OWASP Top 10 2021 (Web / API) - review checklist with CWE mapping
+
+The category id (`A01:2021` .. `A10:2021`) goes in a finding's `security.owaspCategory`; the CWE most associated with the specific weakness goes in `security.cwe`. One weakness per finding. The CWEs listed per category are the common ones, not the whole set - pick the one that names the actual defect.
+
+## A01:2021 - Broken Access Control
+
+Check: missing authorization on a route or action, IDOR (object id from the request trusted without an ownership check), path traversal, forced browsing, CORS misconfiguration allowing credentialed cross-origin reads, privilege escalation through a mass-assignable field.
+CWEs: CWE-284, CWE-285, CWE-639 (IDOR), CWE-862 (missing authorization), CWE-863 (incorrect authorization), CWE-22 (path traversal), CWE-352 (CSRF).
+Evidence to cite: the handler that reads an id from input and queries without a `where owner = current_user` predicate; a route with no auth middleware.
+
+## A02:2021 - Cryptographic Failures
+
+Check: secrets or PII sent or stored in clear, weak or deprecated algorithms (MD5, SHA1 for passwords, DES, ECB), hardcoded keys, missing TLS, disabled certificate validation, predictable IVs/nonces, passwords hashed without a slow KDF (bcrypt/scrypt/argon2).
+CWEs: CWE-311 (missing encryption), CWE-319 (cleartext transmission), CWE-327 (broken/risky algorithm), CWE-326 (inadequate strength), CWE-798 (hardcoded credentials), CWE-916 (weak password hash).
+
+## A03:2021 - Injection
+
+Check: SQL/NoSQL/ORM query built by string concatenation of untrusted input, OS command built from input, LDAP/XPath injection, unsanitized input reflected into HTML (XSS), template injection, header injection.
+CWEs: CWE-89 (SQL), CWE-78 (OS command), CWE-79 (XSS), CWE-90 (LDAP), CWE-94 (code injection), CWE-943 (NoSQL/query).
+Evidence: the untrusted source and the sink on the same path, with no parameterization or encoding between.
+
+## A04:2021 - Insecure Design
+
+Check: a missing control the design needed - no rate limit on a credential endpoint, no anti-automation on a costly action, trust placed in a client-supplied value that decides server behaviour, a workflow that can be replayed.
+CWEs: CWE-73, CWE-183, CWE-209 (info leak by design), CWE-256, CWE-501 (trust boundary violation), CWE-522.
+
+## A05:2021 - Security Misconfiguration
+
+Check: debug or verbose errors in production, default credentials, an unnecessary feature or port enabled, permissive CORS, missing security headers (CSP, HSTS, X-Content-Type-Options), directory listing, an overly-permissive cloud bucket or IAM policy in config.
+CWEs: CWE-16, CWE-611 (XXE), CWE-732 (incorrect permissions), CWE-1032, CWE-756.
+
+## A06:2021 - Vulnerable and Outdated Components
+
+Check: a dependency at a version with a known advisory. This is the `security_dep_inventory` -> CVE-lookup path. Carry the `cve` and the advisory's CWE; put the finding on the manifest at line 0.
+CWEs: CWE-1104, plus the advisory's own CWE.
+
+## A07:2021 - Identification and Authentication Failures
+
+Check: credential stuffing possible (no throttle/lockout), weak password policy, session id in the URL, session not rotated on login, missing or weak MFA, JWT with `alg:none` accepted or signature not verified, long-lived non-revocable tokens.
+CWEs: CWE-287 (improper auth), CWE-297, CWE-384 (session fixation), CWE-521 (weak password), CWE-613 (insufficient expiration), CWE-347 (improper signature verification).
+
+## A08:2021 - Software and Data Integrity Failures
+
+Check: insecure deserialization of untrusted data, an update or plugin loaded without signature verification, a CI/CD step pulling an unpinned or unverified artifact, client-side data trusted without integrity check.
+CWEs: CWE-502 (deserialization), CWE-345, CWE-494 (download without integrity check), CWE-829.
+
+## A09:2021 - Security Logging and Monitoring Failures
+
+Check: security-relevant events not logged (auth failures, access-control denials, high-value actions), logs containing secrets or PII, no alerting path. Note it as a `suggestion`/`important` gap, rarely `blocking` on its own.
+CWEs: CWE-778 (insufficient logging), CWE-532 (secrets in logs), CWE-223.
+
+## A10:2021 - Server-Side Request Forgery (SSRF)
+
+Check: the server fetches a URL built from user input without an allowlist, letting a caller reach internal services, cloud metadata endpoints, or the loopback interface.
+CWEs: CWE-918.
+Evidence: the input-derived URL reaching an HTTP client with no host allowlist or scheme restriction.

package/pipeline/skills/skills-index.md

@@ -3,7 +3,7 @@
 > Auto-generated by `pipeline/scripts/build-skills-index.mjs`  -  do not hand-edit.
 > Regenerate with `node pipeline/scripts/build-skills-index.mjs`.
 
-**216 skills** across 2 groups.
+**213 skills** across 2 groups.
 
 | Group | Name | Platform | Description |
 |-------|------|----------|-------------|
@@ -117,17 +117,14 @@
 | core | `multi-agent-jira` |  -  | List open Jira issues, pick one, and launch the multi-agent pipeline. Use when a Jira issue should be picked up and started without knowing  |
 | core | `multi-agent-kill` |  -  | Stop the given task, then remove its worktree and branch. Asks for confirmation. Use when a running or stuck task should be stopped and its  |
 | core | `multi-agent-language` |  -  | Toggle outputLanguage (assistant explanations, picker questions, PR/Jira/Confluence bodies). promptLanguage is fixed to English; commit mess |
-| core | `multi-agent-local` |  -  | Full pipeline in local mode  -  no worktree, runs directly on the current branch. Use when the full pipeline should run on the current branc |
-| core | `multi-agent-local-autopilot` |  -  | Full pipeline + local + autopilot  -  no worktree, no confirmations, all 6 phases run end-to-end on the current branch. Use when the full pi |
 | core | `multi-agent-log` |  -  | Show the agent-log.md for the given task. With no ID, shows the most recent task. Use when asked what a task did, or to read its log. |
-| core | `multi-agent-manual-test` |  -  | 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-te |
+| core | `multi-agent-manual-test` |  -  | Switch to the active task's branch and prepare it for manual testing in Xcode. Phase 3 user-test step, standalone (the UI Bug Hunter lives a |
 | core | `multi-agent-model` |  -  | Turn the top model rung on or off and keep the cost ledger's pricing in step with it. Use when asked to enable or disable Fable, or which mo |
 | core | `multi-agent-prune-logs` |  -  | Delete per-task project logs under ~/.claude/logs/multi-agent (filter by age/project/task). Audit trail + metrics are preserved. Dry-run fir |
 | core | `multi-agent-prune-prompts` |  -  | Zero-base prompt review: measure the always-on instruction footprint, classify every rule block, propose keep/trial-removal/delete; applies  |
 | core | `multi-agent-purge` |  -  | ⚠️ Wipes every worktree, branch, log, and state file. Irreversible; asks for double confirmation. Use when every worktree, branch, log and s |
 | core | `multi-agent-refactor` |  -  | Analyse the project: extract adapted best-practices, hunt real bugs + improvement areas, check upstream drift of derived skills, research th |
-| core | `multi-agent-resume` |  -  | Resume a stopped or failed task from the phase where it left off. Use when a task stopped or failed and should carry on from where it left o |
-| core | `multi-agent-resume-local` |  -  | Continue already-done LOCAL work through the pipeline tail: Review (with its build gate) → Commit/PR → Report (technical analysis + Jira tes |
+| core | `multi-agent-resume` |  -  | Pick up unfinished work: a pipeline run that stopped mid-phase, or work already written on the current branch that never went through the pi |
 | core | `multi-agent-review` |  -  | Run parallel review on a branch diff or a Pull Request: 3 models on Claude Code (Fable + Opus + Sonnet), 3 models on Copilot CLI (GPT + Opus |
 | core | `multi-agent-review-analysis` |  -  | Review a written analysis document instead of a diff: resolve it from a path, a Confluence page or a Jira issue, run the deterministic gates |
 | core | `multi-agent-review-issue` |  -  | Assess whether a GitHub issue is ready for multi-agent development: fetch it, grade scope / acceptance criteria / repro / design / API / sta |

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

@@ -1,132 +0,0 @@
----
-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."
-description-tr: "Tam pipeline lokal modda - worktree yok, doğrudan mevcut branch üzerinde çalışır."
-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` 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".
-
-The full pipeline in normal mode (Plan Approval Gate + parallel review + triage included), running on the **current branch with no worktree**. Dedicated alias for the `multi-agent "task" --local` flag form. Phase 5 (User Test) is skipped because there is no worktree to check the change out from; the other seven phases all run.
-
-## When to use it
-
-- You don't want a separate worktree open  -  keeps the editor / IDE in one folder
-- You'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: Plan (analysis)   → codebase scan (parallel explore agents, Opus)
-Phase 1: Plan   → task breakdown, Plan Approval Gate (approval loop)
-Phase 2: Dev        → TDD (Sonnet), build queue
-Phase 3: Review     → deterministic gates + parallel review + Fable triage
-Phase 4: Commit     → pre-commit checkout prompt, commit + push + PR
-Phase 5: 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 `$HOME/.claude/multi-agent-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/SKILL.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: 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).
-
-> **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"
-bash $HOME/.claude/scripts/phase-tracker.sh add 0 "Init"
-bash $HOME/.claude/scripts/phase-tracker.sh tiles
-bash $HOME/.claude/scripts/phase-tracker.sh update 0 in_progress
-
-# Phase 0 Step 7.5, immediately after the depth answer - the first moment this
-# mode knows its phase set. Full:
-for p in "1:Plan" "2:Dev" "3:Review" "4:Commit" "5:Report"; do
-  bash $HOME/.claude/scripts/phase-tracker.sh add "${p%%:*}" "${p#*:}"
-done
-# Short (Analysis and Planning are not run, so they get no tile at all):
-for p in "2:Dev" "3:Review" "4:Commit" "5:Report"; do
-  bash $HOME/.claude/scripts/phase-tracker.sh add "${p%%:*}" "${p#*:}"
-done
-# Then the widget, narrowed to the phases that do not have a tile yet:
-bash $HOME/.claude/scripts/phase-tracker.sh tiles --new
-
-# 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. This mode registers in two batches (Step -1, then Step 7.5), so `tiles --new` narrows the second one and the Phase 0 tile is never created twice. 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 at Step -1, then 1:Plan, 2:Dev, 3:Review, 4:Commit, 5:Report (Full) or 2:Dev, 3:Review, 4:Commit, 5:Report (Short) at Step 7.5:
-  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 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` that means: Phase 0 at Step -1, then the rest in ascending order at Step 7.5 (Phase 0 → Phase 1 → Phase 2 → Phase 3 → Phase 4 → Phase 5 minus whatever the depth answer drops). 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.