peaks-loop 3.1.2 → 4.0.0-beta

package/skills/{peaks-solo → peaks-code}/references/sub-agent-dispatch.md

@@ -1,7 +1,7 @@
 # sub-agent-dispatch.md — peaks sub-agent dispatch orchestrator contract
 
 > **Slice**: 2026-06-07-sub-agent-dispatch-decouple (G3 + G6)
-> **Audience**: SKILL.md authors and LLM readers of peaks-solo / peaks-rd / peaks-qa
+> **Audience**: SKILL.md authors and LLM readers of peaks-code / peaks-rd / peaks-qa
 > **Status**: stable
 
 This reference is the orchestrator-side contract for sub-agent dispatch.
@@ -20,7 +20,7 @@ the skills compose. For sub-agent dispatch the relationship is:
 
 | Surface | Who owns | What it does | Who calls it |
 |---|---|---|---|
-| SKILL.md (主面) | peaks-solo, peaks-rd, peaks-qa | Tells the LLM when and why to dispatch a sub-agent; what prompt to pass; what artifacts to expect back | LLM (during normal Solo / RD / QA flow) |
+| SKILL.md (主面) | peaks-code, peaks-rd, peaks-qa | Tells the LLM when and why to dispatch a sub-agent; what prompt to pass; what artifacts to expect back | LLM (during normal Solo / RD / QA flow) |
 | CLI (副 / 原子) | `peaks sub-agent dispatch` | Validates the role, looks up the current IDE's `subAgentDispatcher`, returns a per-IDE tool-call descriptor + writes a dispatch record | LLM (read from the SKILL.md) |
 | Dispatcher 抽象 (per-IDE) | `src/services/dispatch/sub-agent-dispatcher.ts` | Encapsulates the IDE-private tool name (claude-code: `Task`, trae: UNVERIFIED placeholder) and arg shape | CLI (called by the CLI) |
 
@@ -157,7 +157,7 @@ system is dead. G6 is the rule that says: **no**.
 | Layer | Who | What | Cadence |
 |---|---|---|---|
 | **Sub-agent writes** | The sub-agent itself | Calls `peaks sub-agent heartbeat --record <dispatchRecordPath> --status <state> --progress <pct> --note "<text>"` to append a heartbeat | 30 s default; SKILL.md can override via `heartbeatIntervalSec: 15` |
-| **Dispatcher reads** | peaks-solo main loop, during the batch-sync wait | In-process async poller (`BatchHeartbeatPoller`) reads `heartbeats[]` + `lastBeatAt` from each record, emits a single-line status per G6.5 | 10 s (offset from 30 s to avoid jitter) |
+| **Dispatcher reads** | peaks-code main loop, during the batch-sync wait | In-process async poller (`BatchHeartbeatPoller`) reads `heartbeats[]` + `lastBeatAt` from each record, emits a single-line status per G6.5 | 10 s (offset from 30 s to avoid jitter) |
 | **User / CLI reads** | Anyone, anytime | `peaks sub-agent list --session-id <sid> --json` (G5 RL-10, future slice) | manual |
 
 ### Sub-agent prompt template (heartbeat-aware + MCP-decoupled)
@@ -207,10 +207,10 @@ add it explicitly.
 Single line, 80-120 chars:
 
 ```
-[peaks-solo] swarm 3/3 running | rd-planning 45% (12s ago) | qa-test-cases 30% (5s ago) | ui-design 20% (2s ago)
-[peaks-solo] swarm 3/3 running | rd-planning 70% (8s ago) | qa-test-cases 50% (3s ago) | ui-design 30% (6s ago)
+[peaks-code] swarm 3/3 running | rd-planning 45% (12s ago) | qa-test-cases 30% (5s ago) | ui-design 20% (2s ago)
+[peaks-code] swarm 3/3 running | rd-planning 70% (8s ago) | qa-test-cases 50% (3s ago) | ui-design 30% (6s ago)
 ...
-[peaks-solo] swarm 3/3 done
+[peaks-code] swarm 3/3 done
 ```
 
 If a sub-agent has not written a heartbeat in 5 minutes, the poller
@@ -231,7 +231,7 @@ once the poller has read them.
 
 - AC-33 `peaks sub-agent heartbeat` CLI primitive (implemented)
 - AC-34 Dispatch record schema upgrade (`heartbeats[]` + `lastBeatAt` + `status` aggregate, backward-compat defaults)
-- AC-35 peaks-solo main loop batch-sync poller (10 s cadence, 5 min stale)
+- AC-35 peaks-code main loop batch-sync poller (10 s cadence, 5 min stale)
 - AC-36 SKILL.md fan-out sections include heartbeat instruction
 - AC-37 G6 E2E dogfood (3 heartbeats, 101 → truncated, stale simulation)
 
@@ -243,7 +243,7 @@ once the poller has read them.
 - AC-10: dispatch CLI unit tests
 - AC-11 / AC-11b / AC-11c: E2E dogfood on the live repo
 - AC-12: `peaks --help` byte-level delta is `+1` line (`sub-agent <cmd>`)
-- AC-13..AC-19: SKILL.md fan-out rewrites (peaks-solo 5 spots, peaks-rd 2, peaks-qa 3-way, peaks-ui 1; this reference is the canonical contract)
+- AC-13..AC-19: SKILL.md fan-out rewrites (peaks-code 5 spots, peaks-rd 2, peaks-qa 3-way, peaks-ui 1; this reference is the canonical contract)
 - AC-22..AC-24: R-2 path guard, prompt size limit, atomic write
 - AC-25..AC-32: G5 resource lifecycle (RL-1 batch counter, dispatch record schema, reducer dispose, slice archive, cancel dispose)
 - AC-33..AC-37: G6 heartbeat CLI, schema, poller, status line, E2E
@@ -271,7 +271,7 @@ When writing a SKILL.md that fans out sub-agents:
 - RD request #009 in-scope files (implementation contract)
 - `.peaks/memory/sub-agent-resource-lifecycle-red-line.md` (G5 red line)
 - `.peaks/memory/sub-agent-heartbeat-progress-red-line.md` (G6 red line)
-- `skills/peaks-solo/references/swarm-dispatch-contract.md` (predecessor contract)
+- `skills/peaks-code/references/swarm-dispatch-contract.md` (predecessor contract)
 - `skills/peaks-qa/references/qa-fanout-contract.md` (QA-specific fan-out)
 
 ---
@@ -330,5 +330,5 @@ The role's required artefact paths (also see peaks-ui/rd/qa SKILL.md and `refere
 After every sub-agent dispatch returns, Solo **restores presence** once (not per-agent), then continues to Gate B verification:
 
 ```bash
-peaks skill presence:set peaks-solo --project <repo> --mode <mode> --gate swarm-converged
+peaks skill presence:set peaks-code --project <repo> --mode <mode> --gate swarm-converged
 ```

package/skills/{peaks-solo → peaks-code}/references/swarm-dispatch-contract.md

@@ -1,12 +1,12 @@
 # Swarm dispatch contract
 
-> Reference for `peaks-solo` Swarm phase and the role sub-agents (`peaks-ui` / `peaks-rd` planning / `peaks-qa` test-cases). Defines the **mechanism** of fan-out: how Solo launches sub-agents, what the sub-agent prompt must contain, what the sub-agent must return, and how Solo reduces the result.
+> Reference for `peaks-code` Swarm phase and the role sub-agents (`peaks-ui` / `peaks-rd` planning / `peaks-qa` test-cases). Defines the **mechanism** of fan-out: how Solo launches sub-agents, what the sub-agent prompt must contain, what the sub-agent must return, and how Solo reduces the result.
 
 ## Peaks-Loop Swarm parallel phase (sub-agent fan-out, default)
 
 > **Slice 5 (2026-06-23) + slice 2026-06-23-audit-4th #F3:** the
 > previous "conditional swarm" framing is replaced by the **default
-> fan-out rule** in `skills/peaks-solo/SKILL.md` §"Peaks-Loop Default
+> fan-out rule** in `skills/peaks-code/SKILL.md` §"Peaks-Loop Default
 > sub-agent fan-out". When the slice DAG has ≥ 2 leaves at the same
 > topological level, dispatch goes through
 > `peaks sub-agent dispatch --from-dag` (NOT one-at-a-time). The
@@ -31,7 +31,7 @@ The previous "Swarm" used `Skill(skill="peaks-rd")` calls. That is **single-stac
 This contract (slice #009) replaces the IDE-private sub-agent literal with the IDE-agnostic primitive `peaks sub-agent dispatch <role>`. The CLI returns a JSON `data.toolCall` descriptor; the LLM executes that tool in its own environment. SKILL.md is now free of IDE-private tool names and the same prompt works on every registered IDE. Real concurrent fan-out is achieved by Solo launching N dispatch calls in a single message and the platform scheduling the returned toolCalls concurrently.
 
 ```
-You are a sub-agent invoked by peaks-solo. You are NOT the main Claude session.
+You are a sub-agent invoked by peaks-code. You are NOT the main Claude session.
 Your job: execute ONE role from the peaks skill family and write its artefact(s).
 Return a compact JSON envelope — do not write prose.
 
@@ -150,7 +150,7 @@ After all sub-agent dispatch calls return and the LLM has invoked the toolCalls,
 
 1. Restores presence ONCE (not per-agent):
    ```
-   peaks skill presence:set peaks-solo --project <repo> --mode <mode> --gate swarm-converged
+   peaks skill presence:set peaks-code --project <repo> --mode <mode> --gate swarm-converged
    ```
 2. Runs `ls` checks against `sc/swarm-plan.json` — every promised artefact must exist (Gate B hard). If any are missing, apply the degradation rules in "Degradation when swarm roles fail or are absent" (main SKILL.md).
 3. Updates `sc/swarm-plan.json` with the final status of each sub-agent (ok / blocked / skipped / error).
@@ -158,20 +158,20 @@ After all sub-agent dispatch calls return and the LLM has invoked the toolCalls,
 
 ## 5. Presence restoration (single-shot)
 
-Sub-agents are explicitly forbidden from calling `peaks skill presence:set`. That means `.peaks/.active-skill.json` does not move during the fan-out. Solo sets it to `gate=swarm-fan-out` before fan-out and to `gate=swarm-converged` once after all Tasks return. The status header (the `Peaks-Loop Skill: peaks-solo | Peaks-Loop Gate: <gate>` line) therefore reads consistently across the fan-out window.
+Sub-agents are explicitly forbidden from calling `peaks skill presence:set`. That means `.peaks/.active-skill.json` does not move during the fan-out. Solo sets it to `gate=swarm-fan-out` before fan-out and to `gate=swarm-converged` once after all Tasks return. The status header (the `Peaks-Loop Skill: peaks-code | Peaks-Loop Gate: <gate>` line) therefore reads consistently across the fan-out window.
 
 If a sub-agent is misbehaving and writes to `.peaks/.active-skill.json` anyway, the next Solo presence-set (after fan-out) overwrites it — the bug self-heals on the next gate advance, but the swarm-phase display may be off. The hard prohibition is there to prevent this; Solo should still treat the file as a single-writer resource.
 
 ## 6. Why not a `peaks-swarm` skill?
 
-A skill cannot itself trigger sub-agents — the Skill tool runs in the main loop. The orchestrator (peaks-solo) has to be in the main loop and has to call `peaks sub-agent dispatch` directly. Putting swarm logic into a separate skill would either re-introduce the "single-stack blocking" anti-pattern or require a custom slash command that bypasses the Skill tool. The current design keeps swarm control in peaks-solo where it belongs.
+A skill cannot itself trigger sub-agents — the Skill tool runs in the main loop. The orchestrator (peaks-code) has to be in the main loop and has to call `peaks sub-agent dispatch` directly. Putting swarm logic into a separate skill would either re-introduce the "single-stack blocking" anti-pattern or require a custom slash command that bypasses the Skill tool. The current design keeps swarm control in peaks-code where it belongs.
 
 ## 7. Tests / dogfood
 
 - `peaks scan archetype --project <repo> --json` must keep emitting `frontendOnly` and `frontendOnlyReason`. Both fields are read here and by the existing pre-RD scan contract.
 - `peaks request show <rid> --role prd --json` must surface the `--type` chosen at `peaks request init`. Sub-agents pass it through unchanged.
 - `peaks skill presence:set` must remain single-writer-friendly (the sub-agents do not call it).
-- Smoke test: a full-auto peaks-solo run on a `legacy-frontend` project with a UI-affecting PRD should produce `sc/swarm-plan.json` containing all three sub-agents and three corresponding artefacts in `ui/`, `rd/`, `qa/`.
+- Smoke test: a full-auto peaks-code run on a `legacy-frontend` project with a UI-affecting PRD should produce `sc/swarm-plan.json` containing all three sub-agents and three corresponding artefacts in `ui/`, `rd/`, `qa/`.
 
 ---
 

package/skills/{peaks-solo → peaks-code}/references/workflow-gates-and-types.md

@@ -1,11 +1,11 @@
 # Peaks-Loop Workflow Order + Request Type Classification + Transition Verification Gates
 
-> **Maintenance**: This reference holds the canonical contract for (a) how Solo sequences the 11 workflow steps, (b) which `--type` to pass to `peaks request init` for which slice shape, and (c) the executable `ls` / `grep` gate commands that physically block progression. SKILL.md keeps the narrative ("what peaks-solo does"); this file keeps the contract.
+> **Maintenance**: This reference holds the canonical contract for (a) how Solo sequences the 11 workflow steps, (b) which `--type` to pass to `peaks request init` for which slice shape, and (c) the executable `ls` / `grep` gate commands that physically block progression. SKILL.md keeps the narrative ("what peaks-code does"); this file keeps the contract.
 >
 > **Why extracted from SKILL.md**: this content is 165 lines of mostly-tabular + bash-block contract — reference data, not orchestration prose. Inlining it bloats SKILL.md past the 800-line cap (per `common/coding-style.md`). The numbers, gate command shapes, and type-classification rules change rarely; the SKILL.md prose around them (orchestration flow, repair-loop intent, swarm fan-out shape) changes more often.
 >
 > **How peaks-loop tooling reads this file**:
-> - `peaks skill runbook peaks-solo` (CLI) and the in-line LLM reading the SKILL.md should reference this file when the gate-machine or type-classification contract is in play.
+> - `peaks skill runbook peaks-code` (CLI) and the in-line LLM reading the SKILL.md should reference this file when the gate-machine or type-classification contract is in play.
 > - The test `tests/unit/skill-default-runbook.test.ts` does NOT check this file (it only checks the runbook). Future tests can add a similar fallback for the gates-and-types contract.
 
 ## Peaks-Loop Request type classification (MANDATORY before `peaks request init`)
@@ -170,7 +170,7 @@ find . -maxdepth 1 -name "*.png" -o -name "*.jpg" -o -name "qa-*.js" -o -name "m
 ```bash
 # After `peaks standards init/update --apply`, verify the files actually landed
 # at the project root. The CLAUDE.md and rules files are required so that
-# subsequent peaks-rd / peaks-qa / peaks-solo runs perform the project-local
+# subsequent peaks-rd / peaks-qa / peaks-code runs perform the project-local
 # preflight described in CLAUDE.md (read coding-style.md, code-review.md, security.md).
 ls <repo>/CLAUDE.md
 # "No such file" → BLOCKED. Run `peaks standards init --project <repo> --apply --json`

package/skills/peaks-doctor/SKILL.md

@@ -22,7 +22,7 @@ The doctor workflow is read-only by design. It produces:
 - `peaks doctor` report (69 checks: 68 pass, 1 fail — L3:l3-memory-health)
 - Optional OpenSpec change records via `peaks openspec from-doctor`
 
-If a doctor finding requires a code change, the workflow hands off to `peaks-rd` (or `peaks-solo` for the full pipeline). The doctor itself does NOT modify code.
+If a doctor finding requires a code change, the workflow hands off to `peaks-rd` (or `peaks-code` for the full pipeline). The doctor itself does NOT modify code.
 
 ## Workflow (5 steps)
 

package/skills/peaks-doctor/references/doctor-check-catalog.md

@@ -24,7 +24,7 @@ Slice L3.2 ships 69 doctor checks. The most user-relevant ones:
 
 ## Skills
 
-- **`skill:<required-skill>`** — each required skill (peaks-ide, peaks-prd, peaks-rd, peaks-qa, peaks-sc, peaks-solo, peaks-sop, peaks-txt, peaks-ui, peaks-doctor) must be installed in the bundled skills dir
+- **`skill:<required-skill>`** — each required skill (peaks-ide, peaks-prd, peaks-rd, peaks-qa, peaks-sc, peaks-code, peaks-sop, peaks-txt, peaks-ui, peaks-doctor) must be installed in the bundled skills dir
 
 ## Doctor self
 

package/skills/peaks-final-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: peaks-final-review
-description: Final-review skill for Peaks. Use when a workflow needs to assemble 4-dimension business-review evidence (functional-completeness, problem-resolution, no-new-bugs, existing-functionality-intact) for human acceptance at the end of an autonomous slice. Triggers on "/peaks-final-review", "prepare final review", "4-dim review", or peaks-solo end-of-workflow handoff.
+description: Final-review skill for Peaks. Use when a workflow needs to assemble 4-dimension business-review evidence (functional-completeness, problem-resolution, no-new-bugs, existing-functionality-intact) for human acceptance at the end of an autonomous slice. Triggers on "/peaks-final-review", "prepare final review", "4-dim review", or peaks-code end-of-workflow handoff.
 ---
 
 ## Single-scope-axis naming convention
@@ -66,7 +66,7 @@ If any precondition is missing, **STOP** and route back to the responsible skill
 ### Current call path (today, until a CLI wrapper is built)
 
 ```ts
-// peaks-solo end-of-workflow, peaks-txt, or any other hand-rolled caller
+// peaks-code end-of-workflow, peaks-txt, or any other hand-rolled caller
 import { prepareFinalReview } from './src/services/final-review/final-review-service.js';
 import { auditGoalLlmRunner } from './src/services/audit/llm-runner.js'; // or your provider
 
@@ -85,7 +85,7 @@ const out = await prepareFinalReview('<rid>', {
 peaks prepare-final-review --rid <rid> [--session-id <sid>] --json
 ```
 
-`--rid` is required and resolves to `.peaks/_runtime/<sessionId>/audit-goal/<rid>.json`. `--json` is required for machine consumption (peaks-solo, peaks-txt, downstream CI). The wrapper will resolve `--session-id` from `.peaks/_runtime/current-change` when omitted, matching the workspace binding pattern used by `peaks request *`.
+`--rid` is required and resolves to `.peaks/_runtime/<sessionId>/audit-goal/<rid>.json`. `--json` is required for machine consumption (peaks-code, peaks-txt, downstream CI). The wrapper will resolve `--session-id` from `.peaks/_runtime/current-change` when omitted, matching the workspace binding pattern used by `peaks request *`.
 
 ## Output
 

package/skills/peaks-final-review/references/4-dimensions.md

@@ -107,7 +107,7 @@ A pre/post baseline diff shows no unintended drift in the test surface, public A
 The service contract (`src/services/final-review/final-review-service.ts:23-31` and `:88-93`):
 
 - `allPass === true` iff every dimension's `verdict === 'pass'`.
-- `needsAttention` is the list of dimension names whose verdict is `fail` or `inconclusive`. The LLM does NOT need to populate it — the service enforces presence of all 4 dimensions and the human-facing summarizer (in peaks-solo or peaks-txt) computes `needsAttention` for display.
+- `needsAttention` is the list of dimension names whose verdict is `fail` or `inconclusive`. The LLM does NOT need to populate it — the service enforces presence of all 4 dimensions and the human-facing summarizer (in peaks-code or peaks-txt) computes `needsAttention` for display.
 - An `IncompleteFinalReviewError` is thrown when JSON is malformed or any required dimension is missing. That is a **gate failure**, not a `fail` verdict — the LLM call is invalid and must be re-prompted, not surfaced to the human.
 
 ## Confidence and what it means

package/skills/peaks-ide/SKILL.md

@@ -128,7 +128,7 @@ The audit log is **machine-readable** (so `peaks project dashboard` can read it
 - introduce new `peaks <cmd>` CLI commands (dev-preference red line: "Default-no on new CLI commands")
 - bypass the user's confirmation on destructive paths (Switch / Uninstall)
 - write the settings.json directly (the CLI primitives own that)
-- run other peaks skills (peaks-solo, peaks-qa, etc.) — those are separate skills with their own scopes
+- run other peaks skills (peaks-code, peaks-qa, etc.) — those are separate skills with their own scopes
 - handle multi-IDE scenarios in slice #2 (e.g. "I use Claude at work and Trae at home" — the registry is single-IDE per session; a future slice could add multi-IDE)
 
 ## Reference: the CLI primitives the skill composes

package/skills/{peaks-solo-resume → peaks-resume}/SKILL.md

@@ -1,18 +1,18 @@
 ---
-name: peaks-solo-resume
-description: Resume an in-flight peaks-solo slice in the current session. Use when the user says "continue the unfinished work", "继续完成", "把刚才没做完的收尾", or invokes `/peaks-solo-resume` directly. Detects the current session's deepest completed gate (via the Step 0.7 detection script at `tests/fixtures/skill-resume-mode-detect.sh`) and surfaces a resume option via `AskUserQuestion`. Triggers on `/peaks-solo-resume`, "继续完成刚才的", "resume the unfinished slice", "把刚才没做完的收尾".
+name: peaks-resume
+description: Universal resume primitive for any in-flight Peaks-Loop workflow (orchestrator-agnostic). Detects the current session's deepest completed gate and surfaces a resume option via AskUserQuestion. Use when ANY bee (peaks-code, future peaks-research, future peaks-content, …) needs to recover from /compact or session interruption. Triggers on "/peaks-resume", "continue the unfinished work", "继续完成", "把刚才没做完的收尾". (Replaces peaks-resume as a top-level primitive.)
 ---
 
 # Peaks-Loop Solo Resume (wrapper)
 
-Peaks-Loop Solo Resume is a thin wrapper that handles the **most common high-frequency request shape**: "I was in the middle of something, continue it." It detects the current session's deepest completed gate, surfaces a resume option, then yields to the main `peaks-solo` skill (which runs the actual workflow from the matching gate onwards).
+Peaks-Loop Solo Resume is a thin wrapper that handles the **most common high-frequency request shape**: "I was in the middle of something, continue it." It detects the current session's deepest completed gate, surfaces a resume option, then yields to the main `peaks-code` skill (which runs the actual workflow from the matching gate onwards).
 
-**This is a transparent wrapper.** The user does not stay in this skill — once the resume option is confirmed, control hands off to `peaks-solo`. The wrapper exists only to (a) detect the in-flight slice without the LLM re-reading 3-5 artifact files, and (b) surface the resume option as a `AskUserQuestion` before the main loop skips ahead.
+**This is a transparent wrapper.** The user does not stay in this skill — once the resume option is confirmed, control hands off to `peaks-code`. The wrapper exists only to (a) detect the in-flight slice without the LLM re-reading 3-5 artifact files, and (b) surface the resume option as a `AskUserQuestion` before the main loop skips ahead.
 
 ## Skill presence (MANDATORY first action)
 
 ```bash
-peaks skill presence:set peaks-solo-resume --project <repo> --mode <mode> --gate startup
+peaks skill presence:set peaks-resume --project <repo> --mode <mode> --gate startup
 peaks project memories --project <repo> --json  # load durable memory
 ```
 
@@ -32,15 +32,15 @@ bash tests/fixtures/skill-resume-mode-detect.sh "$sid" .peaks
 
 ## Step 2: Branch on the detection
 
-**If `fresh`**: no in-flight slice. Tell the user "No in-flight slice in this session." Then hand off to `peaks-solo` for a fresh start (set presence back, then run `peaks workspace init --project <repo> --json` and continue with Step 1 of `peaks-solo`).
+**If `fresh`**: no in-flight slice. Tell the user "No in-flight slice in this session." Then hand off to `peaks-code` for a fresh start (set presence back, then run `peaks workspace init --project <repo> --json` and continue with Step 1 of `peaks-code`).
 
-**If `complete`**: the workflow is already done. Tell the user "This session is complete — your previous slice already shipped." Then suggest a fresh start (`peaks-solo`) or close-out.
+**If `complete`**: the workflow is already done. Tell the user "This session is complete — your previous slice already shipped." Then suggest a fresh start (`peaks-code`) or close-out.
 
 **If `resume:<gate>`**: surface a resume option via `AskUserQuestion`:
 
 | Option | What it does |
 |---|---|
-| Resume from `<gate>` (Recommended) | Hand off to `peaks-solo` with the gate already at the matching point. The main loop skips ahead; the existing artifacts are preserved as-is. |
+| Resume from `<gate>` (Recommended) | Hand off to `peaks-code` with the gate already at the matching point. The main loop skips ahead; the existing artifacts are preserved as-is. |
 | Start a fresh slice | Treat the current request as a new slice (new `rid`). Existing artifacts are preserved but not auto-resumed. |
 | Abandon the in-flight slice | Mark the in-flight slice as `deferred` (`peaks request transition <rid> --role rd --state deferred --reason "user abandoned"`) and start fresh. |
 
@@ -50,21 +50,21 @@ bash tests/fixtures/skill-resume-mode-detect.sh "$sid" .peaks
 
 Use `AskUserQuestion` with a single option (Confirm and resume from `<state>`). Do NOT auto-resume mid-implementation.
 
-## Step 3: Hand off to peaks-solo
+## Step 3: Hand off to peaks-code
 
-After the user confirms, **re-assert `peaks-solo` presence** so the status header reads correctly for the rest of the run:
+After the user confirms, **re-assert `peaks-code` presence** so the status header reads correctly for the rest of the run:
 
 ```bash
-peaks skill presence:set peaks-solo --project <repo> --mode <mode> --gate <matching-gate>
+peaks skill presence:set peaks-code --project <repo> --mode <mode> --gate <matching-gate>
 ```
 
-Then tell the user: "Resuming from `<gate>`. The main peaks-solo skill will take over from there." and yield control. The user's next message will land in the `peaks-solo` main loop, which will pick up the workflow from the matching gate.
+Then tell the user: "Resuming from `<gate>`. The main peaks-code skill will take over from there." and yield control. The user's next message will land in the `peaks-code` main loop, which will pick up the workflow from the matching gate.
 
 ## Hard rules (do NOT skip)
 
 - **Never silently auto-resume.** Always use `AskUserQuestion` first. The detection is a discovery; the user's confirmation is the gate.
 - **Never auto-resume mid-implementation.** For `in-flight:<state>`, the only valid option is "Confirm and resume from `<state>`" — never "Start a fresh slice" or "Abandon" without the user's explicit choice.
-- **Never write code or modify files in this skill.** This is a wrapper. The actual work (PRD, RD, QA, SC, TXT) is the main `peaks-solo` skill's job.
+- **Never write code or modify files in this skill.** This is a wrapper. The actual work (PRD, RD, QA, SC, TXT) is the main `peaks-code` skill's job.
 - **Never add a new `peaks <cmd>`.** Use the existing CLI primitives: `peaks workspace init`, `peaks project dashboard`, `peaks session list`, `peaks skill runbook`, `peaks skill doctor`, `peaks scan archetype`, `peaks request transition`. The detection script (`tests/fixtures/skill-resume-mode-detect.sh`) is the only executable this skill invokes.
 
 ## Anti-patterns (do NOT do)
@@ -77,5 +77,5 @@ Then tell the user: "Resuming from `<gate>`. The main peaks-solo skill will take
 ## Cross-references
 
 - The detection logic is canonical at `tests/fixtures/skill-resume-mode-detect.sh` (added in slice 003). The 8 vitest cases in `tests/unit/skill-resume-mode.test.ts` cover all classification outcomes.
-- The SKILL.md prose at `skills/peaks-solo/SKILL.md` Step 0.7 (added in slice 003) is the same logic, written for LLM consumption. This wrapper reuses the same script — there is no parallel implementation.
+- The SKILL.md prose at `skills/peaks-code/SKILL.md` Step 0.7 (added in slice 003) is the same logic, written for LLM consumption. This wrapper reuses the same script — there is no parallel implementation.
 - The "drives a CLI on the user's behalf" pattern (mirror of `peaks-sop`) is the closest existing precedent for this wrapper.

package/skills/peaks-sop/SKILL.md

@@ -39,7 +39,7 @@ real process.
 
 If the user invoked this skill directly ("peaks-sop") without mentioning a
 specific project, assume `--project .` (current directory). If they are NOT in
-the middle of a multi-skill peaks-solo/prd/rd/qa pipeline, skip `statusline
+the middle of a multi-skill peaks-code/prd/rd/qa pipeline, skip `statusline
 install` — the status bar is for long-running orchestrations; a standalone SOP
 authoring session does not need it.
 

package/skills/{peaks-solo-status → peaks-status}/SKILL.md

@@ -1,18 +1,18 @@
 ---
-name: peaks-solo-status
-description: Show the current state of the peaks-solo orchestrator in a compact summary. Use when the user says "what's the current state", "现在到哪了", "where are we", or invokes `/peaks-solo-status` directly. Reads the existing CLI primitives (`peaks skill presence`, `peaks session list`, `peaks project dashboard`, `peaks request show`) and renders a 1-screen status table. Triggers on `/peaks-solo-status`, "现在到哪了", "what is the current state", "show me the dashboard", "where are we".
+name: peaks-status
+description: Universal status primitive for any in-flight Peaks-Loop workflow (orchestrator-agnostic). Reads the existing CLI primitives (peaks skill presence, peaks session list, peaks project dashboard, peaks request show) and renders a 1-screen status table. Use when the user asks "where are we", "现在到哪了", "what's the current state" for ANY bee (peaks-code, future peaks-research, …). Triggers on "/peaks-status", "现在到哪了", "what is the current state", "show me the dashboard". (Replaces peaks-status as a top-level primitive.)
 ---
 
 # Peaks-Loop Solo Status (wrapper)
 
-Peaks-Loop Solo Status is a thin wrapper that renders a compact status table for the current peaks-solo orchestrator state. It is the answer to "I just want to know where we are" — no PRD, no RD, no QA, no full peaks-solo orchestration. Just read the existing CLI state and render a 1-screen summary.
+Peaks-Loop Solo Status is a thin wrapper that renders a compact status table for the current peaks-code orchestrator state. It is the answer to "I just want to know where we are" — no PRD, no RD, no QA, no full peaks-code orchestration. Just read the existing CLI state and render a 1-screen summary.
 
-**This is a transparent wrapper.** The user does not stay in this skill — the status table is rendered, and control hands off (back to the user, or to `peaks-solo` if the user wants to act on the status).
+**This is a transparent wrapper.** The user does not stay in this skill — the status table is rendered, and control hands off (back to the user, or to `peaks-code` if the user wants to act on the status).
 
 ## Skill presence (MANDATORY first action)
 
 ```bash
-peaks skill presence:set peaks-solo-status --project <repo> --mode <mode> --gate startup
+peaks skill presence:set peaks-status --project <repo> --mode <mode> --gate startup
 peaks project memories --project <repo> --json  # load durable memory
 ```
 
@@ -51,9 +51,9 @@ All 6 calls are read-only. Total cost: sub-second. (The original draft said "5 c
 Compact 1-screen format:
 
 ```
-=== peaks-solo status ===
+=== peaks-code status ===
 Session:   2026-06-04-session-b60252
-Active:    peaks-solo (mode: full-auto, gate: qa-validation)
+Active:    peaks-code (mode: full-auto, gate: qa-validation)
 Workspace: /Users/yuanyuan/.../peaks-loop/.peaks/2026-06-04-session-b60252
 
 | Role | State          | Artifact                |
@@ -72,9 +72,9 @@ Health: skill-doctor 35/35 pass
 If the session is fresh (no in-flight slice), render a different layout:
 
 ```
-=== peaks-solo status ===
+=== peaks-code status ===
 Session: 2026-06-04-session-b60252
-Active:  peaks-solo (mode: full-auto, gate: startup)
+Active:  peaks-code (mode: full-auto, gate: startup)
 Workspace: /Users/yuanyuan/.../peaks-loop/.peaks/2026-06-04-session-b60252
 
 No in-flight slice. Ready for a new request.
@@ -85,16 +85,16 @@ Health: skill-doctor 35/35 pass
 
 | Option | What it does |
 |---|---|
-| Continue from the current gate | Hand off to `peaks-solo` with the gate already at the current state. Existing artifacts are preserved. |
+| Continue from the current gate | Hand off to `peaks-code` with the gate already at the current state. Existing artifacts are preserved. |
 | Open a new slice in this session | Keep the workspace, treat the current request as a new slice (new `rid`). |
 | Just summarize and exit | No further action; the user will decide later. |
 
 ## Step 4: Hand off (if user picked option 1 or 2)
 
-Re-assert `peaks-solo` presence so the status header reads correctly for the rest of the run:
+Re-assert `peaks-code` presence so the status header reads correctly for the rest of the run:
 
 ```bash
-peaks skill presence:set peaks-solo --project <repo> --mode <mode> --gate <matching-gate>
+peaks skill presence:set peaks-code --project <repo> --mode <mode> --gate <matching-gate>
 ```
 
 Then yield control.
@@ -116,5 +116,5 @@ Then yield control.
 ## Cross-references
 
 - The "drives a CLI on the user's behalf" pattern (mirror of `peaks-sop`) is the closest existing precedent.
-- `peaks-solo-resume` (P2.1) and `peaks-solo-test` (P2.2) are the sibling wrappers. `peaks-solo-resume` focuses on workflow-state introspection + resume decision; `peaks-solo-status` is the broader 5-CLI snapshot. The two are complementary, not redundant.
+- `peaks-resume` (P2.1) and `peaks-test` (P2.2) are the sibling wrappers. `peaks-resume` focuses on workflow-state introspection + resume decision; `peaks-status` is the broader 5-CLI snapshot. The two are complementary, not redundant.
 - The "read 5 CLI primitives, render 1 table" pattern is intentionally minimal — the wrapper does NOT add a new status-introspection CLI command (would violate the dev-preference.md "default-no on new CLI" rule).

package/skills/{peaks-solo-test → peaks-test}/SKILL.md

@@ -1,18 +1,18 @@
 ---
-name: peaks-solo-test
-description: Run the project's test suite on the current repo and report results. Use when the user says "run the tests", "跑一下 test", "跑测试", or invokes `/peaks-solo-test` directly. Runs `pnpm vitest run` (or the project's equivalent test command), captures pass/fail counts and any failures, and surfaces a compact summary. Triggers on `/peaks-solo-test`, "跑一下 test", "跑测试", "run the tests", "test now".
+name: peaks-test
+description: Universal test-runner primitive for any in-flight Peaks-Loop workflow (orchestrator-agnostic). Runs the project's test suite on the current repo and reports results. Use when the user asks "run the tests", "跑一下 test", "跑测试" for ANY bee (peaks-code, future peaks-research, …). Triggers on "/peaks-test", "跑一下 test", "跑测试", "run the tests", "test now". (Replaces peaks-test as a top-level primitive.)
 ---
 
 # Peaks-Loop Solo Test (wrapper)
 
-Peaks-Loop Solo Test is a thin wrapper that runs the project's test suite on the current repo and reports results. It is the answer to "I just want to see if the tests pass" — no PRD, no RD, no QA, no full peaks-solo orchestration. Just `pnpm vitest run` and a compact summary.
+Peaks-Loop Solo Test is a thin wrapper that runs the project's test suite on the current repo and reports results. It is the answer to "I just want to see if the tests pass" — no PRD, no RD, no QA, no full peaks-code orchestration. Just `pnpm vitest run` and a compact summary.
 
-**This is a transparent wrapper.** The user does not stay in this skill — the test command runs, the result is summarized, and control hands off (back to the user, or to `peaks-solo` if the user wants to act on the result).
+**This is a transparent wrapper.** The user does not stay in this skill — the test command runs, the result is summarized, and control hands off (back to the user, or to `peaks-code` if the user wants to act on the result).
 
 ## Skill presence (MANDATORY first action)
 
 ```bash
-peaks skill presence:set peaks-solo-test --project <repo> --mode <mode> --gate startup
+peaks skill presence:set peaks-test --project <repo> --mode <mode> --gate startup
 peaks project memories --project <repo> --json  # load durable memory
 ```
 
@@ -50,23 +50,23 @@ Then ask the user what they want to do next via `AskUserQuestion`:
 | Option | What it does |
 |---|---|
 | Show the full failure list | Print all failing test names + messages (not just the first 5-10) |
-| Open a slice to fix the failures | Hand off to `peaks-solo` with the failing tests as the slice's "acceptance criteria" |
+| Open a slice to fix the failures | Hand off to `peaks-code` with the failing tests as the slice's "acceptance criteria" |
 | Just summarize and exit | No further action; the user will decide later |
 
 ## Step 4: Hand off (if user picked option 2)
 
-Re-assert `peaks-solo` presence so the status header reads correctly for the rest of the run:
+Re-assert `peaks-code` presence so the status header reads correctly for the rest of the run:
 
 ```bash
-peaks skill presence:set peaks-solo --project <repo> --mode <mode> --gate qa-validation
+peaks skill presence:set peaks-code --project <repo> --mode <mode> --gate qa-validation
 ```
 
-Then yield control. The user's next message will land in `peaks-solo` (in QA validation phase, since the failing tests are the validation surface).
+Then yield control. The user's next message will land in `peaks-code` (in QA validation phase, since the failing tests are the validation surface).
 
 ## Hard rules (do NOT skip)
 
 - **Never silently fix test failures.** The user must choose what to do via `AskUserQuestion`. Silently "auto-fix"ing a failing test would mask the failure.
-- **Never modify source code in this skill.** This is a wrapper. The actual fix (if the user wants one) is `peaks-solo`'s job.
+- **Never modify source code in this skill.** This is a wrapper. The actual fix (if the user wants one) is `peaks-code`'s job.
 - **Never add a new `peaks <cmd>`.** Use only existing primitives: `peaks skill presence:set`, `peaks project memories`, `peaks workspace init` (for the handoff), `peaks request transition` (if going to QA-validation). The actual test command is the project's existing test runner, not a `peaks <cmd>`.
 - **Never trust the test runner's exit code as the only signal.** Some failures print partial success (e.g. 100 passed + 1 failed); the wrapper must show the failures, not just say "exit 0".
 
@@ -80,5 +80,5 @@ Then yield control. The user's next message will land in `peaks-solo` (in QA val
 ## Cross-references
 
 - The "drives a CLI on the user's behalf" pattern (mirror of `peaks-sop`) is the closest existing precedent.
-- `peaks-solo-resume` (sibling wrapper, P2.1) is the workflow-state introspection variant; `peaks-solo-test` is the test-execution variant.
+- `peaks-resume` (sibling wrapper, P2.1) is the workflow-state introspection variant; `peaks-test` is the test-execution variant.
 - The "harness a project-native test runner" pattern is intentionally minimal — the wrapper should NOT add a new CLI for running tests (would violate the dev-preference.md "default-no on new CLI" rule + the user's explicit ask for "skill-first, CLI-auxiliary").

package/skills/peaks-solo/references/command-migration.md

@@ -1,3 +0,0 @@
-# command-migration.md
-
-This reference documents command-migration.md for peaks-solo.