@hegemonart/get-design-done 1.57.1 → 1.57.3

package/dist/claude-code/.claude/skills/next/SKILL.md

@@ -1,68 +0,0 @@
----
-name: gdd-next
-description: "Routes to the next pipeline stage based on current STATE.md position"
-tools: Read, Write, mcp__gdd_status, mcp__gdd_phase_current, mcp__gdd_plans_list
-disable-model-invocation: true
----
-
-# Get Design Done - Next
-
-**Role:** Lightweight router. Read `.design/STATE.md` and recommend the next command.
-
----
-
-## Logic
-
-Two paths - MCP preferred when available, file-read fallback otherwise.
-
-### MCP path (preferred)
-
-When `mcp__gdd_phase_current` is exposed (Phase 27.7+, registered via `npx @hegemonart/get-design-done --register-mcp`):
-
-1. Call `mcp__gdd_status` (no args) → `{phase, branch, last_decisions, last_completed_plans, blocker_count}`. Gives cycle + branch context for the output block in one call.
-2. Call `mcp__gdd_phase_current` (no args) → `{phase, stage, task_progress, status}`. Use `stage` to drive the routing table below.
-3. (Optional) Call `mcp__gdd_plans_list` (no args) → current phase plans + status, to identify the next incomplete plan and refine the recommendation.
-4. If `mcp__gdd_status` returns a "STATE.md missing" error, print: "No STATE.md found. Run `/gdd:new-project` to initialize, or `@get-design-done brief` to start the pipeline." and stop. Otherwise, skip to the routing table.
-
-Two to three MCP calls = full routing decision (~3s, ~32k tokens - Storybloq benchmark).
-
-### File-read path (fallback)
-
-When MCP tools are not available, fall back to the legacy flow:
-
-1. Check if `.design/STATE.md` exists.
-   - **No STATE.md** → Print: "No STATE.md found. Run `/gdd:new-project` to initialize, or `@get-design-done brief` to start the pipeline."
-2. If STATE.md exists, parse frontmatter `stage:` field. Proceed to the routing table.
-
-This path loads the same context in 1–2 file reads (~20s, ~46.5k tokens - file-reading baseline).
-
-## Routing table
-
-Map the `stage` (from either path above) to the next recommended command:
-
-| Current `stage:` | Recommendation |
-|---|---|
-| `brief` | Run `@get-design-done explore` to scan and interview |
-| `explore` | Run `@get-design-done plan` to create design plan |
-| `plan` | Run `@get-design-done design` to execute design tasks |
-| `design` | Run `@get-design-done verify` to audit and verify |
-| `verify` | Pipeline complete. Run `/gdd:new-cycle` for next cycle or `/gdd:ship` to create PR |
-
-## Output
-
-Print the recommendation as a single formatted block:
-
-```
-━━━ Next step ━━━
-Current stage: <stage>
-Status: <status>
-→ <recommendation>
-━━━━━━━━━━━━━━━━━━
-```
-
-## Do Not
-
-- Do not modify STATE.md.
-- Do not invoke the next stage automatically - only recommend.
-
-## NEXT COMPLETE

package/dist/claude-code/.claude/skills/note/SKILL.md

@@ -1,48 +0,0 @@
----
-name: gdd-note
-description: "Zero-friction idea capture during any stage. Appends to .design/NOTES.md. Subcommands: add, list, promote."
-argument-hint: "<add|list|promote> [text|line-number]"
-tools: Read, Write
-disable-model-invocation: true
----
-
-# /gdd:note
-
-**Role:** Ephemeral design notes. Zero ceremony - no priority, no due date. Backing store: `.design/NOTES.md`.
-
-## File format
-
-```markdown
-# Design Notes
-
-- [2026-04-18 04:55] Consider revisiting the card border-radius after Phase 7 ships
-- [2026-04-18 05:10] [promoted → todo] Try a glassmorphism treatment for the sidebar
-```
-
-## Subcommands
-
-### add [text]
-Create `.design/NOTES.md` with header if missing. Append one line:
-```
-- [YYYY-MM-DD HH:MM] <text>
-```
-If text omitted, append a blank timestamped entry for the user to fill later:
-```
-- [YYYY-MM-DD HH:MM] 
-```
-
-### list
-Read `.design/NOTES.md`. Print each note line with its line number for use with `promote`.
-
-### promote [line-number]
-Read the note at that line. Delegate to `/gdd:todo add` by writing a new P2 entry into `.design/TODO.md` directly (format: `- [ ] [YYYY-MM-DD] <text>` under `## P2 — Normal`). Rewrite the original note line in NOTES.md with `[promoted → todo]` prefix before the text:
-```
-- [2026-04-18 05:10] [promoted → todo] <original text>
-```
-
-## Constraints
-
-- Never overwrite prior notes on `add`.
-- Preserve exact line order on `promote`.
-
-## NOTE COMPLETE

package/dist/claude-code/.claude/skills/openrouter-status/SKILL.md

@@ -1,86 +0,0 @@
----
-name: gdd-openrouter-status
-description: "Read-only OpenRouter catalog + tier-mapping diagnostic - surfaces catalog freshness (fetched_at vs the 24h TTL), the last-fetch timestamp, the resolved opus/sonnet/haiku → model mappings (via the Phase-33.6 adapter), and a per-tier preview. Use when investigating which OpenRouter model a tier resolves to, or whether the catalog cache is fresh/stale. Phase 33.6 (v1.33.6) diagnostic - /gdd:openrouter-status."
-argument-hint: "[--refresh]"
-tools: Read, Bash
-disable-model-invocation: true
----
-
-# gdd-openrouter-status
-
-## Role
-
-You are a deterministic, read-only diagnostic skill. You do **not** spawn agents and you do **not** modify the catalog cache. You read `.design/cache/openrouter-models.json` (the Phase-33.6-01 catalog cache) via `scripts/lib/openrouter/catalog-fetcher.cjs#readCatalog`, resolve the `opus`/`sonnet`/`haiku` tiers via `scripts/lib/tier-resolver-openrouter.cjs#resolve`, and emit a single Markdown status block. Read-only - to refresh the catalog you pass `--refresh` (a single opt-in fetch gated on `OPENROUTER_API_KEY`); there is no other mutation. See `connections/openrouter.md` for setup and `reference/openrouter-tier-mapping.md` for the resolution heuristic.
-
-This is `disable-model-invocation: true` (mirroring `skills/cache-manager/SKILL.md`): the skill is user-invoked only - the model must not auto-spawn it. It never makes a model call.
-
-## Invocation Contract
-
-- **Input**: optional `--refresh`. When absent, the skill is purely read-only (cache + resolve). When `--refresh` is set AND `OPENROUTER_API_KEY` is present, it calls the Phase-33.6-01 fetcher once to refresh the cache before reading; when `--refresh` is set but no key is present, it prints the empty-state/no-key message and does NOT fetch.
-- **Output**: a Markdown OpenRouter-status block to stdout. The block is the entire output.
-
-## Procedure
-
-### 1. (Optional) refresh
-
-If `--refresh` is set and `OPENROUTER_API_KEY` is present, run a single fetch to refresh the cache:
-
-```bash
-node -e "require('./scripts/lib/openrouter/catalog-fetcher.cjs').fetchCatalog().then(()=>{}).catch(()=>{})"
-```
-
-This is the ONLY mutation the skill performs, and only on explicit `--refresh`. The fetch never throws (D-08); a failure degrades to the existing cache.
-
-### 2. Read the catalog cache
-
-Read `.design/cache/openrouter-models.json` via `readCatalog`. Missing or empty → emit the empty-state message and stop:
-
-```
-## OpenRouter Status
-
-No OpenRouter catalog yet — set OPENROUTER_API_KEY and run a cycle, or `/gdd:openrouter-status --refresh`.
-
-Tier resolution is currently falling back to the native provider (graceful degrade — D-08).
-```
-
-### 3. Compute freshness
-
-Read `fetched_at` from the cache object and compare against the 24h TTL (D-02): `age = now - fetched_at`. `age < 24h` → **fresh**; otherwise → **stale** (a stale catalog still resolves - the adapter uses the last good cache).
-
-### 4. Resolve the tiers
-
-For each of `opus`, `sonnet`, `haiku`, resolve via the adapter (it reads `.design/config.json#openrouter_tier_overrides` and applies the heuristic over the cached catalog):
-
-```bash
-node -e "const r=require('./scripts/lib/tier-resolver-openrouter.cjs');for(const t of ['opus','sonnet','haiku'])console.log(t, '->', r.resolve(t) || '(null → native fallback)')"
-```
-
-A `null` for a tier means OpenRouter has no pick → the native provider resolves that tier (D-08). Note any tier that resolved from an explicit `openrouter_tier_overrides` pin vs the heuristic.
-
-### 5. Print the status block
-
-```
-## OpenRouter Status
-
-Catalog source: <source URL from cache>
-Last fetched:   <fetched_at>  (<fresh | stale> — TTL 24h)
-Models in catalog: <count>
-
-| Tier   | Resolved model id                | Source             |
-|--------|----------------------------------|--------------------|
-| opus   | <id or (null → native fallback)> | <override | heuristic> |
-| sonnet | <id or (null → native fallback)> | <override | heuristic> |
-| haiku  | <id or (null → native fallback)> | <override | heuristic> |
-
-> Resolution: override (`.design/config.json#openrouter_tier_overrides`) wins, else the closed-vs-open + pricing heuristic over the catalog.
-> A null resolution means tier resolution falls back to the native provider (D-08).
-> Read-only — this skill never modifies the cache; use `--refresh` to re-fetch (needs OPENROUTER_API_KEY).
-```
-
-## Completion marker
-
-End the output with:
-
-```
-## OPENROUTER-STATUS COMPLETE
-```

package/dist/claude-code/.claude/skills/optimize/SKILL.md

@@ -1,97 +0,0 @@
----
-name: optimize
-description: "Reads .design/telemetry/costs.jsonl + .design/agent-metrics.json, runs rule-based analysis, writes .design/OPTIMIZE-RECOMMENDATIONS.md. Pure advisory - no auto-apply. User reviews + decides."
-argument-hint: "[--refresh] [--min-spawns=N]"
-user-invocable: true
-tools: Read, Bash, Grep, Write
----
-
-# /gdd:optimize - Optimization Advisor
-
-## Role
-
-Read the telemetry ledger (`.design/telemetry/costs.jsonl`) and per-agent aggregate (`.design/agent-metrics.json`), apply a fixed set of rule-based heuristics, and emit recommendations to `.design/OPTIMIZE-RECOMMENDATIONS.md`. Never modify agent files, budget config, or cache state. Output is a markdown table of proposals the user reviews manually, mirroring Phase 11 `/gdd:apply-reflections`. **Advisory only**: never edits `agents/*.md`, `.design/budget.json`, `.design/cache-manifest.json`. Never makes model calls - every rule is deterministic. See `./reference/heuristics.md` §"Optimization rules" for the full rule catalog.
-
-## Refresh Step
-
-Before analysis, invoke the aggregator:
-
-```bash
-node --experimental-strip-types scripts/aggregate-agent-metrics.ts
-```
-
-Idempotent. If `--refresh` absent and `.design/agent-metrics.json` generated within 60s, skip.
-
-## Inputs
-
-- `.design/telemetry/costs.jsonl` - append-only; tolerant of malformed lines.
-- `.design/agent-metrics.json` - per-agent aggregate; source of truth for `cache_hit_rate`, `lazy_skip_rate`, `total_cost_usd`, `total_spawns`.
-- `agents/*.md` - frontmatter cross-reference for tier override churn + typical-duration drift.
-- `.design/budget.json` - `tier_overrides` table (optional).
-
-## Optional Arguments
-
-- `--refresh` - force aggregator refresh even if metrics file is fresh.
-- `--min-spawns=N` - only emit recommendations for agents with ≥ N spawns (default 5).
-
-## Rules
-
-Rule-based analysis. Full thresholds + emission templates in `./reference/heuristics.md` §"Optimization rules"; here, the short rule catalog:
-
-- **R1 - Low cache hit rate.** IF `total_spawns >= --min-spawns` AND `cache_hit_rate < 0.20` → propose batching + investigate shared-preamble ordering.
-- **R2 - Expensive + rarely lazy-skipped.** IF `total_cost_usd > 0.50` AND `lazy_skip_rate < 0.10` → propose adding a lazy gate at `agents/{agent}-gate.md` (Plan 10.1-04 pattern).
-- **R3 - Tier override churn.** IF measured `tier` differs from frontmatter `default-tier` for multiple rows → propose updating frontmatter or removing budget.json override.
-- **R4 - Typical duration drift.** IF measured `typical_duration_seconds` differs from frontmatter by > 50% → propose frontmatter update. (v1 only computes wall-clock duration if both spawn + complete rows have matching correlation IDs; otherwise flag "insufficient data".)
-
-## Output Format
-
-Write `.design/OPTIMIZE-RECOMMENDATIONS.md`:
-
-```markdown
-# Optimization Recommendations
-
-**Generated:** {ISO-8601 timestamp}
-**Telemetry rows analyzed:** {N}
-**Agents analyzed:** {M}
-**Min spawns threshold:** {--min-spawns value}
-
-> Advisory only. No changes have been applied. Review each proposal and apply manually via the suggested action.
-
-## Proposals
-
-| Rule | Agent | Current | Proposed | Rationale |
-|------|-------|---------|----------|-----------|
-| R1 | ... | ... | ... | ... |
-
-## Summary
-
-- R1 matches: {count}
-- R2 matches: {count}
-- R3 matches: {count}
-- R4 matches: {count}
-
-## OPTIMIZE COMPLETE
-```
-
-The `## OPTIMIZE COMPLETE` marker is the completion sentinel.
-
-## No Auto-Apply
-
-This skill **never modifies** `agents/*.md`, `.design/budget.json`, `.design/cache-manifest.json`, or any other configuration. **Never auto-applies** proposals. If the user wants to act, they do so manually. Discipline mirrors `/gdd:apply-reflections` from Phase 11.
-
-## Integration with Phase 11 Reflector
-
-The Phase 11 reflector (`agents/design-reflector.md`) reads both `costs.jsonl` and `agent-metrics.json` on its own cadence. `/gdd:optimize` is user-facing; the reflector is automation-facing. Outputs land in different files (`.design/OPTIMIZE-RECOMMENDATIONS.md` vs `.design/reflections/*.md`) and never collide.
-
-## Non-Goals
-
-- Does not make model calls (rule-based, deterministic).
-- Does not modify config.
-- Does not propose changes outside the four rules - future rules added by future phases.
-- Does not learn from history - Phase 11 reflector territory.
-
-## Failure Modes
-
-- Missing `.design/telemetry/costs.jsonl` → emit `No telemetry data yet — run /gdd:* commands to accumulate data, then retry.` + `## OPTIMIZE COMPLETE`.
-- Missing `.design/agent-metrics.json` after refresh → emit `Aggregator failed — check node --experimental-strip-types scripts/aggregate-agent-metrics.ts output manually.`
-- Zero rules matched → write `No recommendations — all agents within healthy thresholds.` + `## OPTIMIZE COMPLETE`.

package/dist/claude-code/.claude/skills/override/SKILL.md

@@ -1,86 +0,0 @@
----
-name: gdd-override
-description: "Escalation surface for a risk-blocked action or a fact-force gate. Use when the Phase 56 risk gate blocked a writer action (suggested_action=block) and a reviewer has signed off, or when the first-write fact-force gate is holding a file you have legitimately reviewed. Activates for requests involving overriding a blocked edit, approving a high-risk change, or clearing a fact-force hold on a path."
-argument-hint: "<finding-id | factforce <path>> [--approver <who>] [--reason <text>]"
-user-invocable: true
-tools: Read, Write, Bash, Grep, Glob
----
-
-# /gdd:override
-
-A risk-blocked action is hard: the Phase 56 risk gate routes `suggested_action=block`
-to `override` (see `scripts/lib/risk/route.cjs`), and the fact-force gate holds the
-first write to a file until its facts are read. This skill is the audited way past
-either hold. It mirrors `/gdd:unlock-decision`: a named approver plus a
-reason, recorded before anything is let through. Override is never silent.
-
-## Invocation
-
-| Command | Behavior |
-|---|---|
-| `/gdd:override <finding-id> --approver <who> --reason <text>` | Record a `D-XX` `override`-tagged decision in STATE.md `<decisions>` and let the risk-blocked action through. |
-| `/gdd:override factforce <path> --approver <who> --reason <text>` | Set `checked[path]` in the session fact-force state so the fact-force gate stops holding that path. |
-
-Both modes ask for a rationale: the audit trail is the reason override exists.
-
-## Steps
-
-1. **Parse args.** Mode is `factforce` when the first token is the literal `factforce`
-   (the next token is the `<path>`); otherwise the first token is a `<finding-id>`.
-   `--approver` is required (a non-empty name). Missing `--approver` prints the usage
-   and changes nothing. If `--reason` is absent, ASK for one (AskUserQuestion or a
-   prompt) before continuing: an override with no rationale is rejected.
-
-2. **Preview.** Show what will be written and stop for confirmation:
-   - finding mode: the decision entry from `overrideDecisionEntry(<id>, {approver, reason})`
-     (its `text`, `status: locked`, and `override` tag) plus the action it unblocks.
-   - factforce mode: the `<path>` that will gain `checked[path] = true` and the
-     session-state file it lands in.
-
-3. **Apply (finding mode).** Record the audited decision via the STATE writer
-   `mcp__gdd_state__add_decision` (it auto-assigns the next `D-N`). Pass the `text`
-   from the pure builder so the `override` tag is embedded and greppable:
-
-   ```bash
-   node -e '
-     const o = require("./scripts/lib/risk/override.cjs");
-     const [id, who, reason] = process.argv.slice(1);
-     const entry = o.overrideDecisionEntry(id, { approver: who, reason });
-     console.log(JSON.stringify(entry));
-   ' "<finding-id>" "<who>" "<reason>"
-   ```
-
-   Then call `mcp__gdd_state__add_decision` with `{ text: <entry.text>, status: "locked" }`.
-   The blocked action is now approved on the audit record; proceed with it.
-
-4. **Apply (factforce mode).** Set `checked[path]` in the session state file at
-   `<cwd>/.design/locks/factforce-<session_id>.json` (atomic tmp then rename), using
-   the pure helper so the shape matches what the fact-force gate reads:
-
-   ```bash
-   node -e '
-     const fs = require("fs"); const path = require("path");
-     const o = require("./scripts/lib/risk/override.cjs");
-     const [file, p] = process.argv.slice(1);
-     let state = {}; try { state = JSON.parse(fs.readFileSync(file, "utf8")); } catch {}
-     const next = o.setFactForceChecked(state, p);
-     fs.mkdirSync(path.dirname(file), { recursive: true });
-     const tmp = file + ".tmp";
-     fs.writeFileSync(tmp, JSON.stringify(next, null, 2) + "\n");
-     fs.renameSync(tmp, file);
-     console.log(JSON.stringify(next.checked));
-   ' "<cwd>/.design/locks/factforce-<session_id>.json" "<path>"
-   ```
-
-   The fact-force gate stops holding `<path>` for the rest of the session.
-
-5. **Report** the recorded approver, the reason, and either the new `D-XX` id (finding
-   mode) or the unblocked path (factforce mode).
-
-## Do Not
-
-- Do not skip the rationale: every override is audited.
-- Do not override a finding that the risk gate did not actually block.
-- Do not edit `scripts/lib/risk/route.cjs` or `compute-risk.cjs`: this skill consumes them.
-
-## OVERRIDE COMPLETE

package/dist/claude-code/.claude/skills/pause/SKILL.md

@@ -1,77 +0,0 @@
----
-name: gdd-pause
-description: "Write a numbered checkpoint so work can resume in a new session without re-running completed stages."
-argument-hint: "[context note]"
-tools: Read, Write, Bash, AskUserQuestion, mcp__gdd_state__get, mcp__gdd_state__set_status, mcp__gdd_state__add_blocker, mcp__gdd_state__checkpoint
-disable-model-invocation: true
----
-
-@reference/retrieval-contract.md
-@reference/cycle-handoff-preamble.md
-
-# /gdd:pause
-
-Captures enough state that a killed or stopped session can resume cleanly via `/gdd:resume` or `/gdd:continue`.
-
-Each invocation writes an **immutable numbered checkpoint** - it does not overwrite previous pauses. This enables branched cycles: you can pause, take a detour via `/gdd:sketch`, compare, and resume an older snapshot via `/gdd:resume N`.
-
-## Steps
-
-1. `mcp__gdd_state__get` → snapshot current pipeline state. Extract:
-   - Current `stage` and `cycle`
-   - `last_checkpoint` timestamp
-   - `task_progress` and `status` for the current run
-   - Open todos (from `.design/TODO.md` if present - this file is outside the MCP catalog, so `Read` is still used)
-   - Active sketch/spike directories (scan `.design/sketches/` and `.design/spikes/` for in-progress markers)
-
-2. **Determine checkpoint number**: run
-   ```bash
-   ls .design/checkpoints/ 2>/dev/null | grep -E '^[0-9]+' | sort -n | tail -1
-   ```
-   Next checkpoint = last number + 1 (or `01` if none exist).
-
-3. **Collect context**: if no context argument was passed, ask (AskUserQuestion):
-   "What are you in the middle of? (optional context to capture)"
-
-4. **Flip status via MCP** so `/gdd:resume` can detect the pause and recover the prior status:
-   1. `mcp__gdd_state__set_status` with `status: "paused:<prior-status>"` - the `paused:` prefix preserves the prior status for resume parsing.
-   2. If the user supplied a context/blocker message: `mcp__gdd_state__add_blocker` with `{ stage: <current>, date: <today>, text: <message> }`.
-   3. `mcp__gdd_state__checkpoint` to stamp `last_checkpoint` via MCP.
-
-5. **Write numbered checkpoint**: create `.design/checkpoints/` with `mkdir -p`, then write:
-   ```
-   .design/checkpoints/NN-<stage>-<ISO-date>.md
-   ```
-   e.g. `01-design-2026-04-24.md`
-
-   Content:
-   ```markdown
-   # Checkpoint NN
-   **Saved**: <ISO timestamp>
-   **Stage**: <stage>
-   **Cycle**: <cycle>
-   **In progress**: <task description + wave/index>
-   **Next**: <next step>
-   **Context**: <user note or "none">
-   **Active sketch**: <path or none>
-   **Open todos**: <N items (see .design/TODO.md)>
-   **Completed this session**: <list>
-   ```
-
-6. **Update HANDOFF.md pointer**: write `.design/HANDOFF.md` with:
-   ```markdown
-   # Session Handoff (pointer)
-   Latest checkpoint: `.design/checkpoints/NN-<stage>-<ISO-date>.md`
-   Run `/gdd:resume` to restore, or `/gdd:resume N` for a specific checkpoint.
-   ```
-
-7. Print: "Checkpoint NN saved. Run `/gdd:resume` or `/gdd:continue` to pick back up."
-
-## Do Not
-
-- Do not mutate STATE.md directly - all STATE.md writes go through the `gdd-state` MCP tools above. Checkpoint files + HANDOFF.md are sibling artifacts, written with `Write`.
-- Do not abort in-progress sketches; just record them.
-- Do not delete previous checkpoint files.
-- Do not call `mcp__gdd_state__transition_stage` - pause is status-only, never a stage transition.
-
-## PAUSE COMPLETE

package/dist/claude-code/.claude/skills/peer-cli-add/SKILL.md

@@ -1,88 +0,0 @@
----
-name: peer-cli-add
-description: "Guided ladder for adding a brand-new peer (not in the v1.27 capability matrix) to gdd's peer-CLI delegation layer. Walks the verification ladder, scaffolds an adapter, updates the capability matrix, and handles Windows quirks. Run when you discover a new peer CLI you want gdd to delegate to."
-argument-hint: "<new-peer-id> <peer-binary> <protocol: acp|asp>"
-tools: Read, Edit, Write, Bash, Grep
----
-
-<!-- Procedural pattern adapted from greenpolo/cc-multi-cli's `multi-cli-anything` skill (Apache 2.0). See NOTICE for full attribution. -->
-
-# peer-cli-add
-
-## Role
-
-You add a brand-new peer-CLI to gdd's delegation layer. v1.27.0 ships 5 peers (codex, gemini, cursor, copilot, qwen). When the user wants a 6th - a peer that exists in the wild but isn't in our capability matrix - you walk them through the verification ladder and produce the 3-file footprint that integrates the peer cleanly. The procedural ladder, adapter scaffold shape, and verification gate live in `./peer-cli-protocol.md`.
-
-## Invocation Contract
-
-- **Required input:** `<new-peer-id>` (lowercase, e.g. `aider`), `<peer-binary>` (executable, e.g. `aider` or `aider.cmd`), `<protocol>` (`acp` or `asp`).
-- **Output:** a 3-file diff + a verification report.
-
-## Procedure
-
-### Step 1 - Verification ladder (no edits yet)
-
-Walk the four-rung ladder in `./peer-cli-protocol.md` §"Verification ladder":
-
-1. Binary on PATH (`which` / `where`).
-2. Handshake test (`initialize` JSON-RPC over stdin; capture reply).
-3. Model-ID `-preview`-suffix trap (capture model list).
-4. Windows quirks (confirm `spawn-cmd.cjs` picks up `.cmd`).
-
-Stop at the first failing rung. Do not proceed to scaffold a broken adapter.
-
-### Step 2 - Generate the adapter scaffold
-
-Copy one of `scripts/lib/peer-cli/adapters/{codex,gemini,cursor,copilot,qwen}.cjs` as the template (pick by protocol - ASP for `<protocol>=asp`, else ACP). Replace `ROLES_CLAIMED`, `ROLE_PREFIX`, `name`, `protocol` with the user's values from Step 1. The full adapter scaffold shape - `claims`, `dispatch`, exports - lives in `./peer-cli-protocol.md` §"Adapter scaffold shape" so consumers (codex/gemini/cursor/copilot/qwen) stay byte-similar.
-
-Write the result to `scripts/lib/peer-cli/adapters/<new-peer-id>.cjs`.
-
-### Step 3 - Three-file footprint
-
-Per `./peer-cli-protocol.md` §"Three-file footprint":
-
-1. New adapter at `scripts/lib/peer-cli/adapters/<new-peer-id>.cjs` (Step 2).
-2. Edit `scripts/lib/install/runtimes.cjs` - add `peerBinary` field (platform-aware: `<peer-binary>.cmd` on Windows, plain on POSIX).
-3. Edit `reference/peer-cli-capabilities.md` - add matrix row + per-peer section citing the Step 1 verification evidence.
-4. Edit `scripts/lib/peer-cli/registry.cjs` - append to `CAPABILITY_MATRIX` (and `KNOWN_PEERS` if separate).
-
-### Step 4 - Verification gate
-
-Run the four-check gate in `./peer-cli-protocol.md` §"Verification gate": `tsc --noEmit`, peer-cli tests, reference-registry round-trip, frontmatter validator. Any failure - surface error + offer revert.
-
-### Step 5 - Surface the summary
-
-```
-## peer-cli-add summary
-Added peer: <new-peer-id> (protocol: <protocol>)
-Roles claimed: <role-1>, <role-2>
-
-Files modified:
-✓ scripts/lib/peer-cli/adapters/<new-peer-id>.cjs (new)
-✓ scripts/lib/install/runtimes.cjs (added peerBinary entry)
-✓ reference/peer-cli-capabilities.md (added matrix row + per-peer section)
-✓ scripts/lib/peer-cli/registry.cjs (added to CAPABILITY_MATRIX)
-
-Verification:
-✓ tsc clean
-✓ existing peer-cli tests pass
-✓ reference-registry round-trip valid
-✓ frontmatter validator: 0 violations
-
-Next steps:
-- /gdd:peers to confirm the new peer appears in the matrix.
-- skills/peer-cli-customize/SKILL.md to wire delegate_to: <new-peer-id>-<role> on agents.
-- Phase 23.5 bandit needs ~5 cycles of data before a posterior recommendation surfaces.
-```
-
-## Edge cases
-
-See `./peer-cli-protocol.md` §"Edge cases" for: peer speaks neither protocol, claims unknown role, claims all roles (generalist), peer-ID conflicts, and testing-only peers.
-
-## Record
-
-Append one JSONL line to `.design/skill-records.jsonl`:
-
-```json
-{"skill": "peer-cli-add", "ts": "<ISO timestamp>", "new_peer": "<new-peer-id>", "protocol": "<protocol>", "roles_claimed": ["<role-1>"], "verification_passed": true}
-```