peaks-loop 3.1.2 → 4.0.0-beta

package/skills/{peaks-ui → bee/peaks-ui}/SKILL.md

@@ -1,6 +1,12 @@
 ---
 name: peaks-ui
-description: UI and experience skill for Peaks. Use when a workflow touches UI/UX, interaction design, visual direction, design systems, frontend page behavior, high-fidelity HTML prototypes, or UI regression seeds.
+description: |
+  UI and experience role for Peaks-Loop (LLM-only internal role; not user-invocable.
+  Triggered by peaks-code via `peaks sub-agent dispatch --role ui`.)
+  Use when a workflow touches UI/UX, interaction design, visual direction, design systems,
+  frontend page behavior, high-fidelity HTML prototypes, or UI regression seeds.
+visibility: internal
+---
 ---
 
 # Peaks-Loop UI
@@ -26,9 +32,9 @@ find . -maxdepth 1 -name '*.png' 2>&1
 
 UI inherits `peaks-qa`'s hard-block contract: `AskUserQuestion` with three options (logged in / skip / cancel); no silent downgrade, no DOM-state inference.
 
-## Sub-agent dispatch (when launched by peaks-solo swarm)
+## Sub-agent dispatch (when launched by peaks-code swarm)
 
-When this skill is launched as a sub-agent via `peaks sub-agent dispatch <role>` from `peaks-solo`, these sections are **suspended** for the sub-agent run:
+When this skill is launched as a sub-agent via `peaks sub-agent dispatch <role>` from `peaks-code`, these sections are **suspended** for the sub-agent run:
 
 - **Session id** — use parent's sid (`.peaks/_runtime/session.json` or `--session-id <parent-sid>`). Do NOT spawn your own session; `peaks session info --active` reads the canonical binding.
 - **Skill presence** — do NOT call `peaks skill presence:set peaks-ui`; Solo owns `.peaks/.active-skill.json`. Marker file at `.peaks/_runtime/<session-id>/system/sub-agent-ui.json` only.
@@ -217,7 +223,7 @@ Use gstack as a design-review workflow reference for the `Plan → Review → Te
 - map browser walkthrough concepts to UI regression seeds when runtime validation is approved;
 - keep accessibility, performance, and visual direction as Peaks-Loop UI acceptance inputs.
 
-For frontend work, especially full-auto mode, use the Playwright MCP to inspect the running page or prototype before accepting the UI direction. The LLM checks its own tool list for any Playwright MCP entry in the LLM tool list; if present, it invokes the tools by name directly (browser_navigate / browser_snapshot / browser_take_screenshot / browser_console_messages / browser_network_requests / browser_close) — no peaks-loop envelope. Playwright MCP launches a headed browser on demand; if the tool list is empty, the user installs via `claude mcp add playwright -- npx @playwright/mcp@latest` (Claude Code) or the IDE's own MCP install path. (Chrome DevTools MCP is a secondary surface that connects to an already-running Chrome via `--remote-debugging-port=9222`; it does NOT launch a browser on its own.) If login, CAPTCHA, SSO, or MFA appears, the visible browser is already open; wait for the user to complete login and explicitly confirm completion before continuing. Capture only sanitized visible regressions as UI feedback for design/RD; do not retain login URLs, cookies, headers, tokens, storage state, browser traces, or screenshots/logs containing PII or SSO/MFA material. Canonical browser workflow: `peaks-solo/references/browser-workflow.md`.
+For frontend work, especially full-auto mode, use the Playwright MCP to inspect the running page or prototype before accepting the UI direction. The LLM checks its own tool list for any Playwright MCP entry in the LLM tool list; if present, it invokes the tools by name directly (browser_navigate / browser_snapshot / browser_take_screenshot / browser_console_messages / browser_network_requests / browser_close) — no peaks-loop envelope. Playwright MCP launches a headed browser on demand; if the tool list is empty, the user installs via `claude mcp add playwright -- npx @playwright/mcp@latest` (Claude Code) or the IDE's own MCP install path. (Chrome DevTools MCP is a secondary surface that connects to an already-running Chrome via `--remote-debugging-port=9222`; it does NOT launch a browser on its own.) If login, CAPTCHA, SSO, or MFA appears, the visible browser is already open; wait for the user to complete login and explicitly confirm completion before continuing. Capture only sanitized visible regressions as UI feedback for design/RD; do not retain login URLs, cookies, headers, tokens, storage state, browser traces, or screenshots/logs containing PII or SSO/MFA material. Canonical browser workflow: `peaks-code/references/browser-workflow.md`.
 
 ## Prototype fidelity gate (MANDATORY — check BEFORE any design work)
 
@@ -344,7 +350,7 @@ Do not own backend architecture, non-UI implementation, runtime hook installatio
 
 ## Sub-agent context governance (slice #010)
 
-UI sub-agents follow the same G7 metadata-only + G8.6 share protocol. UI artifacts are large binary-ish; the 1MB artifact size limit (G7.3) applies. Detailed: `skills/peaks-solo/references/context-governance.md`.
+UI sub-agents follow the same G7 metadata-only + G8.6 share protocol. UI artifacts are large binary-ish; the 1MB artifact size limit (G7.3) applies. Detailed: `skills/peaks-code/references/context-governance.md`.
 
 ### G7 — UI sub-agent protocol
 

package/skills/peaks-audit/SKILL.md

@@ -36,7 +36,7 @@ Invoke `peaks-audit` when **any** of these are true:
 
 - A human just expressed a software-development need and no accepted `proposedGoal` exists yet.
 - A previous audit was rejected (any dimension missing, malformed JSON, or the user said "redo the audit").
-- A drift detector (peaks-doctor, peaks-solo) flagged that an in-flight slice lost its goal binding.
+- A drift detector (peaks-doctor, peaks-code) flagged that an in-flight slice lost its goal binding.
 - The user typed `/peaks-audit` or said "audit this", "scope this", "what would this take", "is this a good idea".
 
 Do NOT invoke peaks-audit when the user is asking for a code review, a test run, or a deployment — those are downstream skills.

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

@@ -1,6 +1,6 @@
 ---
-name: peaks-solo
-description: Full-auto orchestration facade for the Peaks-Loop skill family. Use when the user asks Peaks-Loop to handle a project workflow end-to-end (端到端/全流程/需求开发), especially from a product document (PRD/飞书文档/Feishu doc) through implementation and validation. Coordinates peaks-prd, peaks-rd, peaks-ui, peaks-qa, peaks-sc, and peaks-txt while preserving user confirmation gates. Triggers on `/peaks-solo`, "peaks solo", "全流程开发", "端到端迭代".
+name: peaks-code
+description: Code-domain loop engineering orchestrator for the Peaks-Loop skill family. Use when the user asks Peaks-Loop to handle a code-repo workflow end-to-end (端到端/全流程/需求开发), especially from a product document (PRD/飞书文档/Feishu doc) through implementation and validation. Coordinates peaks-prd, peaks-rd, peaks-qa, peaks-ui, peaks-sc, and peaks-txt while preserving user confirmation gates. Triggers on `/peaks-code`, "peaks code", "全流程开发", "端到端迭代". General primitives (peaks-resume / peaks-status / peaks-test) are sibling skills, not children.
 ---
 
 ## Single-scope-axis naming convention (2.7.1)
@@ -29,7 +29,7 @@ This skill is the **primary surface**. The `peaks <cmd>` CLI is **auxiliary**
 
 ## Code-Change Red Line (BLOCKING — read before ANY tool call)
 
-**Peaks-Loop Solo is an orchestrator, NOT an implementer. You MUST NOT write, edit, or modify any application source code directly.** Every code change goes through `peaks-solo → RD → QA → verdict`. **If you catch yourself about to write code, STOP.** Hand off to RD. Before declaring workflow complete, run `peaks workflow verify-pipeline --rid <rid> --project <repo> --json`.
+**Peaks-Loop Solo is an orchestrator, NOT an implementer. You MUST NOT write, edit, or modify any application source code directly.** Every code change goes through `peaks-code → RD → QA → verdict`. **If you catch yourself about to write code, STOP.** Hand off to RD. Before declaring workflow complete, run `peaks workflow verify-pipeline --rid <rid> --project <repo> --json`.
 
 ## Peaks-Loop Startup sequence (MANDATORY — execute in order)
 
@@ -65,7 +65,7 @@ After every 4th tool call, probe via `peaks solo context-now --project <repo> --
 
 ### Peaks-Loop Step 0: Anchor the workflow (MANDATORY FIRST ACTIONS — no bail-out)
 
-Run `peaks workspace init` + `peaks skill presence:set peaks-solo` BEFORE any analysis, role handoff, or mode-selection question. Even "分析下这个项目" / "看一下代码" / one-line questions anchor first.
+Run `peaks workspace init` + `peaks skill presence:set peaks-code` BEFORE any analysis, role handoff, or mode-selection question. Even "分析下这个项目" / "看一下代码" / one-line questions anchor first.
 
 → see `references/anchoring-and-session-info.md` for the full Step 0 contract + session-conflict resolution.
 
@@ -128,7 +128,7 @@ Use `AskUserQuestion` with `Full auto (Recommended)` first when user did not nam
 
 ### Peaks-Loop Step 2: Re-set skill presence with the chosen mode
 
-Re-run `peaks skill presence:set peaks-solo --mode <mode-value> --gate startup`. Install statusline on first run (`peaks statusline install`). → `references/skill-presence-and-title.md`.
+Re-run `peaks skill presence:set peaks-code --mode <mode-value> --gate startup`. Install statusline on first run (`peaks statusline install`). → `references/skill-presence-and-title.md`.
 
 ### Peaks-Loop Step 2.3: Load project memory (durable, LLM-authored memories)
 
@@ -140,7 +140,7 @@ Extract a short title from the user's first request (8-20 Chinese chars or 4-10
 
 ## Sub-agent session sharing (MANDATORY — one conversation = one sid)
 
-When peaks-solo dispatches a sub-agent (peaks-rd, peaks-qa, peaks-ui, peaks-txt, peaks-sc), the prompt MUST include the parent's sid. The sub-agent MUST NOT call `peaks workspace init` (would orphan the parent's binding).
+When peaks-code dispatches a sub-agent (peaks-rd, peaks-qa, peaks-ui, peaks-txt, peaks-sc), the prompt MUST include the parent's sid. The sub-agent MUST NOT call `peaks workspace init` (would orphan the parent's binding).
 
 ## Boundaries
 
@@ -164,7 +164,7 @@ When the project has no live backend (no swagger.json, no API server), Solo must
 
 ## Peaks-Loop Request type classification + Workflow order + Transition verification gates
 
-The contract for the 6-type classification table, the 11-step workflow order, and the 7 transition verification gates (A through G with their `ls` / `grep` shell snippets) lives in `references/workflow-gates-and-types.md`. The peaks-solo narrative references those gate numbers (Gate A through Gate G) — keep both files in lockstep when adding or renaming a gate.
+The contract for the 6-type classification table, the 11-step workflow order, and the 7 transition verification gates (A through G with their `ls` / `grep` shell snippets) lives in `references/workflow-gates-and-types.md`. The peaks-code narrative references those gate numbers (Gate A through Gate G) — keep both files in lockstep when adding or renaming a gate.
 
 ## Peaks-Loop Default sub-agent fan-out (≥ 2 leaves/topological level → `--from-dag`)
 
@@ -204,7 +204,7 @@ Gather via `peaks standards init/update --project <path> --dry-run`. Standards m
 
 ## Peaks-Loop Refactor mode
 
-Read `references/refactor-mode.md` first. Default MVP: `peaks-solo refactor`. Red lines: understand before changes, ≥95% UT coverage, split broad refactors, strict verifiable specs, 100% acceptance per slice.
+Read `references/refactor-mode.md` first. Default MVP: `peaks-code refactor`. Red lines: understand before changes, ≥95% UT coverage, split broad refactors, strict verifiable specs, 100% acceptance per slice.
 
 ## Peaks-Loop Quality-gate commands (CLI cheat sheet)
 
@@ -212,7 +212,7 @@ Five CLI commands harden the workflow against silent skips: `peaks request lint`
 
 ## Peaks-Loop Completion handoff
 
-After final validation, refresh project-local standards via `peaks standards init/update` (never hand-write). Use Peaks-Loop TXT for the compact handoff capsule. **Presence management is delegated to the last downstream skill** — peaks-solo does not call `peaks skill presence:clear` itself.
+After final validation, refresh project-local standards via `peaks standards init/update` (never hand-write). Use Peaks-Loop TXT for the compact handoff capsule. **Presence management is delegated to the last downstream skill** — peaks-code does not call `peaks skill presence:clear` itself.
 
 ## Peaks-Loop Step 11: Memory sediment (BLOCKING on workflow complete)
 

package/skills/{peaks-solo → peaks-code}/references/a2a-artifact-mapping.md

@@ -1,6 +1,6 @@
 # A2A artifact mapping (informational)
 
-> Reference for `peaks-solo` and any other peaks skill that produces durable artefacts in `.peaks/_runtime/<session-id>/`. Maps peaks's on-disk artefact vocabulary onto the A2A (Agent2Agent) protocol's vocabulary so a future peaks consumer (e.g. an external LLM agent or a downstream peaks-loop extension) can read peaks output without having to learn a brand-new schema. This is a **documentation mapping**, not a protocol implementation: peaks-loop does not speak A2A over HTTP, does not host an AgentCard endpoint, and does not advertise its capabilities via A2A's discovery mechanism. It only uses A2A's *concepts* as a shared naming layer.
+> Reference for `peaks-code` and any other peaks skill that produces durable artefacts in `.peaks/_runtime/<session-id>/`. Maps peaks's on-disk artefact vocabulary onto the A2A (Agent2Agent) protocol's vocabulary so a future peaks consumer (e.g. an external LLM agent or a downstream peaks-loop extension) can read peaks output without having to learn a brand-new schema. This is a **documentation mapping**, not a protocol implementation: peaks-loop does not speak A2A over HTTP, does not host an AgentCard endpoint, and does not advertise its capabilities via A2A's discovery mechanism. It only uses A2A's *concepts* as a shared naming layer.
 
 ## 1. Why this reference exists
 
@@ -70,7 +70,7 @@ A consumer translating peaks states to A2A should:
 
 ## 5. Worked example: a feature slice from start to finish
 
-A user runs `peaks-solo` for a "add user authentication" feature. Mapping the resulting files to A2A concepts:
+A user runs `peaks-code` for a "add user authentication" feature. Mapping the resulting files to A2A concepts:
 
 ```
 .peaks/_runtime/<sessionId>/prd/requests/001.md      → A2A Artifact (kind=proposal)

package/skills/{peaks-solo → peaks-code}/references/anchoring-and-session-info.md

@@ -10,19 +10,19 @@
 # the "two sessions in .peaks/" confusion that bites Solo, always omit --session-id
 # here and let the CLI auto-generate.
 peaks workspace init --project <repo> --json
-peaks skill presence:set peaks-solo --project <repo> --gate startup
+peaks skill presence:set peaks-code --project <repo> --gate startup
 ```
 
 > `<repo>` is the **git project root** (the directory containing `.git`). In a monorepo / single-repo-multi-package layout, this is the repo root, NOT a sub-package — `.peaks/` lives at the repo root so every package shares one workspace. If unsure, run `git rev-parse --show-toplevel` and use that path. Never let `.peaks/` land inside a sub-package directory.
 
 **There is no request too lightweight to skip this.** "分析下这个项目", "看一下代码", "分析项目", "解释一下架构", a one-line question — all of them still create the workspace and set presence first. The workspace is cheap; a missing `.peaks/` is the #1 reported failure.
 
-**Anti-bail-out rule (BLOCKING):** You MUST NOT exit the peaks-solo workflow, hand control back, or produce a final answer before Step 0 has run. If you catch yourself thinking "this is just analysis, I don't need the workflow" — STOP. Run Step 0, set presence, then continue. A pure-analysis request runs the **lightweight analysis branch** (project scan + standards dry-run + handoff with a Standards-increment section), but it still anchors the workspace and keeps presence active. Declining to anchor is a workflow violation.
+**Anti-bail-out rule (BLOCKING):** You MUST NOT exit the peaks-code workflow, hand control back, or produce a final answer before Step 0 has run. If you catch yourself thinking "this is just analysis, I don't need the workflow" — STOP. Run Step 0, set presence, then continue. A pure-analysis request runs the **lightweight analysis branch** (project scan + standards dry-run + handoff with a Standards-increment section), but it still anchors the workspace and keeps presence active. Declining to anchor is a workflow violation.
 
 **Session conflict resolution (read once, internalise):** If `peaks workspace init` returns `code: "CONFLICTING_SESSION"` with a body like
 `{"existingSessionId":"<Y>","requestedSessionId":"<X>"}`, the project is already bound to a different in-flight session `<Y>` (the one you or a prior run was working on). The fix is **NOT** to pass `--allow-session-rebind` to clobber `<Y>` — that destroys an active session's data. Instead: finish or abandon `<Y>` first (use `peaks session list --json` to see what it is, then `peaks session finish --id <Y>` or `peaks session abandon --id <Y>` — see your session command's help for the exact verbs). Only after `<Y>` is closed should you re-run `peaks workspace init`. The same rule applies to `peaks workspace init --session-id "<manually-forged>"` — do not pre-forge session ids; the CLI's auto-generated value is the binding.
 
-**Fact-Forcing Gate bypass (slice 2.0.1-bug3):** Claude Code's [Fact-Forcing Gate] fires in two shapes inside peaks-solo Step 0: (1) Bash-side "Quote the user's current instruction verbatim. Then retry the same operation." and (2) Write-side 4-facts prompt. Both block the very first Write to `.peaks/_runtime/<sid>/session.json` and the first `peaks skill presence:set peaks-solo` invocation. The default `peaks workspace init` (no flag) materializes `.claude/settings.local.json` in the consumer project root with a PreToolUse hook allow-list that exits 0 for tool calls inside `.peaks/**` and for `peaks <whitelisted-subcommand>` Bash commands. The hook bypasses the gate before it fires.
+**Fact-Forcing Gate bypass (slice 2.0.1-bug3):** Claude Code's [Fact-Forcing Gate] fires in two shapes inside peaks-code Step 0: (1) Bash-side "Quote the user's current instruction verbatim. Then retry the same operation." and (2) Write-side 4-facts prompt. Both block the very first Write to `.peaks/_runtime/<sid>/session.json` and the first `peaks skill presence:set peaks-code` invocation. The default `peaks workspace init` (no flag) materializes `.claude/settings.local.json` in the consumer project root with a PreToolUse hook allow-list that exits 0 for tool calls inside `.peaks/**` and for `peaks <whitelisted-subcommand>` Bash commands. The hook bypasses the gate before it fires.
 
 If the bypass is not in effect (e.g. `.claude/` was read-only, or the user passed `--no-claude-hooks`, or the consumer manually deleted the file), the recovery flow is:
 
@@ -31,4 +31,4 @@ If the bypass is not in effect (e.g. `.claude/` was read-only, or the user passe
 
 **Anti-bail-out rule for the gate:** Do NOT skip Step 0 because the gate fired. The gate is a Claude Code core feature that peaks-loop cannot modify directly; peaks-loop can only sidestep it via the hook allow-list. If the gate still blocks Step 0 after the bypass is in effect, the user has a misconfigured `.claude/settings.json` upstream — surface that as a separate `AskUserQuestion` ("Your `.claude/settings.json` is overriding the local allow-list. May peaks-loop delete the local file and regenerate it?") rather than skipping Step 0.
 
-`presence:set` accepts no `--mode` here on purpose — mode is unknown until Step 1. It is re-run with the selected mode in Step 2. Setting presence early guarantees the status header/line shows `peaks-solo` from the very first turn even if the user never reaches mode selection.
+`presence:set` accepts no `--mode` here on purpose — mode is unknown until Step 1. It is re-run with the selected mode in Step 2. Setting presence early guarantees the status header/line shows `peaks-code` from the very first turn even if the user never reaches mode selection.

package/skills/{peaks-solo → peaks-code}/references/artifact-contracts.md

@@ -13,10 +13,10 @@ Each role produces artifacts with predictable file names so cross-role reference
 | PRD | `prd/requests/` | `<request-id>.md` | peaks-prd | peaks-ui, peaks-rd, peaks-qa, peaks-txt |
 | UI | `ui/` | `design-draft.md` | peaks-ui | peaks-rd (implementation), peaks-qa (visual regression) |
 | RD planning | `rd/` | `tech-doc.md` | peaks-rd (planning phase) | peaks-rd (implementation phase) |
-| RD project scan | `rd/` | `project-scan.md` | peaks-solo (pre-RD scan) | peaks-rd, peaks-ui |
+| RD project scan | `rd/` | `project-scan.md` | peaks-code (pre-RD scan) | peaks-rd, peaks-ui |
 | RD implementation | `rd/requests/` | `<request-id>.md` | peaks-rd | peaks-qa, peaks-sc, peaks-txt |
 | QA test cases | `qa/test-cases/` | `<request-id>.md` | peaks-qa (pre-implementation) | peaks-rd (TDD guidance), peaks-qa (execution) |
-| QA test reports | `qa/test-reports/` | `<request-id>.md` | peaks-qa (post-execution) | peaks-solo (verdict), peaks-txt |
+| QA test reports | `qa/test-reports/` | `<request-id>.md` | peaks-qa (post-execution) | peaks-code (verdict), peaks-txt |
 | QA requests | `qa/requests/` | `<request-id>.md` | peaks-qa | peaks-txt |
 | SC | `sc/` | `<change-id>-impact.md`, `<slice-id>-retention.md` | peaks-sc | peaks-txt |
 | TXT | `txt/` | `handoff-<request-id>.md` | peaks-txt | user (final deliverable) |

package/skills/{peaks-solo → peaks-code}/references/browser-workflow.md

@@ -9,7 +9,7 @@ Peaks skills standardize on **Playwright MCP** as the controlled headed-browser
 | Frontend E2E validation that needs to start, navigate, capture, close | **Playwright MCP** | Headed mode, full lifecycle in one tool. |
 | Live page debugging where the user wants to keep their own Chrome session in front | Chrome DevTools MCP | Stays attached without disrupting the user's tabs. |
 
-> **Bug history**: an earlier version of this document recommended Chrome DevTools MCP for "open a headed browser when peaks-solo gets a product document link." Dogfood testing in 2026-05 revealed the tool requires a pre-running Chrome with remote debugging enabled — it does NOT launch its own browser. Playwright MCP is the correct tool for the "open on demand" case.
+> **Bug history**: an earlier version of this document recommended Chrome DevTools MCP for "open a headed browser when peaks-code gets a product document link." Dogfood testing in 2026-05 revealed the tool requires a pre-running Chrome with remote debugging enabled — it does NOT launch its own browser. Playwright MCP is the correct tool for the "open on demand" case.
 
 > **Slice #016 (2026-06-09)**: peaks-loop no longer manages MCP install / dispatch. Skill bodies instruct the LLM to (a) check its own tool list for any Playwright MCP entry, (b) invoke the tool by name if present, (c) tell the user the install command if absent. There is no peaks-loop MCP indirection layer anymore.
 

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

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

package/skills/{peaks-solo → peaks-code}/references/completion-handoff.md

@@ -8,9 +8,9 @@ Use Peaks-Loop TXT for the compact handoff capsule: mode, validated decisions, a
 
 ## Workflow completion (no auto-exit)
 
-peaks-solo does NOT itself call `peaks skill presence:clear --project <repo>` at workflow end. Presence management is delegated to the last downstream skill in the workflow (peaks-rd, peaks-qa, peaks-txt); each of those skills owns its own presence:clear step per its SKILL.md. peaks-solo only sets presence: it does not unset it.
+peaks-code does NOT itself call `peaks skill presence:clear --project <repo>` at workflow end. Presence management is delegated to the last downstream skill in the workflow (peaks-rd, peaks-qa, peaks-txt); each of those skills owns its own presence:clear step per its SKILL.md. peaks-code only sets presence: it does not unset it.
 
-The user can continue with follow-up requirements naturally — no need to re-invoke `/peaks-solo` to do so. The header continues to display whatever skill is active; the user can `/peaks-solo` again to re-anchor.
+The user can continue with follow-up requirements naturally — no need to re-invoke `/peaks-code` to do so. The header continues to display whatever skill is active; the user can `/peaks-code` again to re-anchor.
 
 Before ending, extract durable memories from this session.
 

package/skills/{peaks-solo → peaks-code}/references/context-governance.md

@@ -41,7 +41,7 @@ On completion:
 ### Main LLM reducer view (G7.4.e)
 
 ```
-[peaks-solo] batch 3/3 done in 47.3s
+[peaks-code] batch 3/3 done in 47.3s
 - rd → .peaks/_sub_agents/2026-06-06-session-5b1095/artifacts/003-rd-001.md (12KB, sha256:abc123) summary: "wrote RD tech-doc with 4 sub-roles and dispatcher interface"
 - qa-business → .../artifacts/003-qa-business-001.md (8KB, sha256:def456) summary: "wrote 12 API test cases covering happy + 3 error paths"
 - qa-perf → .../artifacts/003-qa-perf-001.md (5KB, sha256:ghi789) summary: "wrote perf baseline; p95 latency target ≤ 200ms"
@@ -165,7 +165,7 @@ PROTOCOL (mandatory):
 
 Main LLM view format (G7.4.e):
 ```
-[peaks-solo] batch 3/3 done in 47.3s
+[peaks-code] batch 3/3 done in 47.3s
 - rd → .peaks/_sub_agents/2026-06-06-session-5b1095/artifacts/003-rd-001.md (12KB, sha256:abc123) summary: "wrote RD tech-doc with 4 sub-roles"
 - qa-business → .../artifacts/003-qa-business-001.md (8KB, sha256:def456) summary: "wrote 12 API test cases"
 - qa-perf → .../artifacts/003-qa-perf-001.md (5KB, sha256:ghi789) summary: "p95 latency target ≤ 200ms"

package/skills/{peaks-solo → peaks-code}/references/frontend-only-mode.md

@@ -1,6 +1,6 @@
 # Peaks-Loop Frontend-only development mode
 
-> Extracted from `skills/peaks-solo/SKILL.md` on 2026-06-09 (slice 019 — slim skill files to references) to keep SKILL.md under the 800-line cap from `common/coding-style.md`. The content below is the verbatim Frontend-only development mode section that was previously inline; nothing was paraphrased, just relocated.
+> Extracted from `skills/peaks-code/SKILL.md` on 2026-06-09 (slice 019 — slim skill files to references) to keep SKILL.md under the 800-line cap from `common/coding-style.md`. The content below is the verbatim Frontend-only development mode section that was previously inline; nothing was paraphrased, just relocated.
 
 When the project has no live backend (no swagger.json, no API server), Solo must activate frontend-only mode.
 

package/skills/{peaks-solo → peaks-code}/references/local-artifact-workspace.md

@@ -28,7 +28,7 @@ The workspace initialization creates this structure under `.peaks/`:
 # --active --json` (and the matching read-only primitives for the
 # other two) to discover session-id / active-skill / sop-state.
 .peaks/_runtime/
-├── active-skill.json   # orchestrator presence marker (peaks-solo / -rd / -qa / -ui / -sc / -sop / -txt)
+├── active-skill.json   # orchestrator presence marker (peaks-code / -rd / -qa / -ui / -sc / -sop / -txt)
 ├── session.json        # project → session binding (the only single-session source of truth)
 └── sop-state/          # current phase + history; definitions live globally in ~/.peaks
 

package/skills/{peaks-solo → peaks-code}/references/micro-cycle.md

@@ -95,7 +95,7 @@ peaks slice check [--rid <rid>] [--project <path>] [--json]
 
 4 个 check 全绿 + verify-pipeline pass → 才进 `peaks request transition --state qa-handoff`，让 peaks-qa 接管。
 
-> **新增 run 017（2026-06-09）**：边界默认走 changed-only suite，原来的全 suite 行为移到 `--run-tests` opt-in。`peaks-solo-test` skill 仍然是手动跑全量的入口。rationale: 全量 30s+ 严重拖慢 workflow；changed-only 命中 99% 真正回归。详见 PRD `.peaks/_runtime/2026-06-07-session-84feb7/prd/requests/002-017-2026-06-09-remove-auto-full-vitest-from-slice-check.md`。
+> **新增 run 017（2026-06-09）**：边界默认走 changed-only suite，原来的全 suite 行为移到 `--run-tests` opt-in。`peaks-test` skill 仍然是手动跑全量的入口。rationale: 全量 30s+ 严重拖慢 workflow；changed-only 命中 99% 真正回归。详见 PRD `.peaks/_runtime/2026-06-07-session-84feb7/prd/requests/002-017-2026-06-09-remove-auto-full-vitest-from-slice-check.md`。
 
 ## Micro-cycle → 边界 check → QA 的串联
 
@@ -131,21 +131,21 @@ verdict=return-to-rd → RD 修 (new slice 内部走 micro-cycle)
 
 | 阶段 | 谁负责 | 节奏 |
 |---|---|---|
-| RD slice 内部 | peaks-solo (main loop) | micro-cycle（5-10s 一个） |
-| RD slice 边界 | peaks-solo 调用 `peaks slice check` | 一次 |
+| RD slice 内部 | peaks-code (main loop) | micro-cycle（5-10s 一个） |
+| RD slice 边界 | peaks-code 调用 `peaks slice check` | 一次 |
 | QA test execution | peaks-qa (sub-agent or inline) | slice 级 |
 | 3-way fan-out (CR + sec + perf) | peaks-rd (sub-agent) | slice 级（RD 内部一次 + 边界 check 一次） |
 | TXT handoff | peaks-txt | slice 级 |
 | SC commit-boundaries | peaks-sc | slice 级 |
 
-## 为什么这套比当前 peaks-solo 的设计合理
+## 为什么这套比当前 peaks-code 的设计合理
 
 - **快**：micro-cycle ~100ms（vs 30s 全 suite），改 10 个 bug 从 5 分钟降到 30 秒
 - **稳**：边界 check 不省，4 项检查（tsc + vitest run --changed + 3-way + verify-pipeline）一次全跑；changed-only 模式 1-3s 内出结果，全量用 `--run-tests` opt-in
 - **清晰**：LLM 看到一个 explicit "禁止" 列表 + 强制 sequence，比"建议"更不容易越界
 - **可观测**：micro-cycle 走单测 → 边界跑 verify-pipeline，每步都有 JSON envelope 验证
 
-## 跟 peaks-solo SKILL.md 的对账
+## 跟 peaks-code SKILL.md 的对账
 
 - `peaks slice check` = 边界命令
 - micro-cycle = slice 内部
@@ -187,10 +187,10 @@ After RD completes (whether inline or sub-agent), Solo does not stop — it must
 **Presence restoration after RD/QA work returns (MANDATORY):** In v1.x, role skills called `peaks skill presence:set <role>` internally and stomped on `.peaks/.active-skill.json`. From v1.3 onward, sub-agents in the Swarm path are forbidden from calling `peaks skill presence:set` (see "Sub-agent dispatch" in each role's SKILL.md), so the main loop's presence file is preserved across the fan-out window by construction. The one place Solo still has to actively restore presence is **once after the fan-out returns** (gate=swarm-converged) and again **after each RD↔QA repair iteration** (gate=repair-cycle-<N>). Use the same command from Step 2 with the current mode and the gate that has just advanced:
 
 ```bash
-peaks skill presence:set peaks-solo --project <repo> --mode <mode> --gate <current-gate>
+peaks skill presence:set peaks-code --project <repo> --mode <mode> --gate <current-gate>
 ```
 
-This keeps the CLAUDE.md status header accurate (`Peaks-Loop Skill: peaks-solo`) instead of showing a stale role name. Use the current mode and gate values; the gate may have advanced since startup. Skipping this step causes the header to display the last-known gate permanently.
+This keeps the CLAUDE.md status header accurate (`Peaks-Loop Skill: peaks-code`) instead of showing a stale role name. Use the current mode and gate values; the gate may have advanced since startup. Skipping this step causes the header to display the last-known gate permanently.
 
 **Full-auto auto-proceed rule**: In the `full-auto` profile, when RD transitions to `qa-handoff`, Solo immediately drives QA — by launching a `peaks sub-agent dispatch qa` sub-agent carrying the `peaks-qa` body (swarm path), then executing the returned toolCall, or by running QA inline in the main loop (assisted/strict path). Do not pause, do not ask the user, do not summarize RD results as if they were final. The only valid reason to skip QA is when `--type` is `docs` or `chore` (no acceptance surface).
 
@@ -217,7 +217,7 @@ When `peaks-qa` returns `verdict=return-to-rd`, Solo does NOT manually rewrite R
 6. Repeat steps 1-5 until QA returns `verdict=pass`, or the cap below fires.
    **After each repair iteration** (after peaks-rd and peaks-qa both return), Solo MUST restore presence:
    ```bash
-   peaks skill presence:set peaks-solo --project <repo> --mode <mode> --gate repair-cycle-<N>
+   peaks skill presence:set peaks-code --project <repo> --mode <mode> --gate repair-cycle-<N>
    ```
 
 **Repair cycle cap**: After 3 repair cycles without a passing QA verdict, emit a blocked TXT handoff regardless of remaining issues. Do not loop indefinitely. If a specific issue cannot be resolved within 3 cycles, mark it as a known blocker in the TXT handoff and proceed to the SC phase.
@@ -297,7 +297,7 @@ reasons array preserved verbatim.
 
 ### Runbook integration
 
-When the peaks-solo main loop sees `qa verdict != pass` or any audit
+When the peaks-code main loop sees `qa verdict != pass` or any audit
 prereq missing, the runbook now does:
 
 1. Call `aggregateVerdict({ security, perf, karpathy, mut, qa })` with

package/skills/{peaks-solo → peaks-code}/references/mode-selection-with-stale-presence.md

@@ -8,19 +8,19 @@
 
 Defect A (from PRD-002, 2026-06-28 session 88b27d):
 
-1. session A runs in `full-auto` → `peaks skill presence:set peaks-solo --mode full-auto --gate startup` stamps
+1. session A runs in `full-auto` → `peaks skill presence:set peaks-code --mode full-auto --gate startup` stamps
    `.peaks/_runtime/active-skill.json` with `outerSessionId=outer-A`.
 2. session A closes (Claude window quit).
 3. session B opens (a new Claude window, `outerSessionId=outer-B`).
 4. `peaks skill presence:get --project <path>` still returns `mode=full-auto` because the file is on disk.
-5. peaks-solo Step 1 reads the presence, sees `mode=full-auto`, **skips** AskUserQuestion.
+5. peaks-code Step 1 reads the presence, sees `mode=full-auto`, **skips** AskUserQuestion.
 6. The user never picked `full-auto` for THIS session — the mode was sticky from the previous one.
 
 The fix: presence is only authoritative when its `outerSessionId` matches the current outer session. Otherwise Step 1 must re-ask.
 
 ## Detection protocol
 
-Before deciding to skip Step 1's AskUserQuestion, the LLM driver (or any peaks-solo caller) MUST run:
+Before deciding to skip Step 1's AskUserQuestion, the LLM driver (or any peaks-code caller) MUST run:
 
 ```bash
 peaks skill presence:check-stale --project <path> --json
@@ -35,7 +35,7 @@ The CLI returns a JSON envelope of shape:
   "data": {
     "stale": true,
     "reason": "outer-session-mismatch",
-    "presence": { "skill": "peaks-solo", "mode": "full-auto", "outerSessionId": "outer-A", ... },
+    "presence": { "skill": "peaks-code", "mode": "full-auto", "outerSessionId": "outer-A", ... },
     "currentOuterSessionId": "outer-B",
     "recordedOuterSessionId": "outer-A"
   },
@@ -79,11 +79,11 @@ Returns the same `stale` / `reason` / `currentOuterSessionId` / `recordedOuterSe
 }
 ```
 
-The hard-pause on `step-1-mode-select` is preserved for ALL modes (defect #1 fix from slice 2026-06-28-solo-mode-bypass-fix). Stale-presence is an additional reason — even when the user names a profile explicitly, peaks-solo can still surface the staleness for visibility.
+The hard-pause on `step-1-mode-select` is preserved for ALL modes (defect #1 fix from slice 2026-06-28-solo-mode-bypass-fix). Stale-presence is an additional reason — even when the user names a profile explicitly, peaks-code can still surface the staleness for visibility.
 
 ## Auto-clear on session rotation
 
-`peaks workspace init` now calls `clearStalePresenceOnRotation` whenever an `outer-session-mismatch` rotation fires. This means in the COMMON path (user reopens Claude → peaks-solo auto-runs `peaks workspace init` → rotation clears the stale presence → Step 1 reads no-presence → re-ask). The check-stale CLI is the safety net for the rare case where rotation was suppressed (`--no-rotate-on-outer-mismatch`).
+`peaks workspace init` now calls `clearStalePresenceOnRotation` whenever an `outer-session-mismatch` rotation fires. This means in the COMMON path (user reopens Claude → peaks-code auto-runs `peaks workspace init` → rotation clears the stale presence → Step 1 reads no-presence → re-ask). The check-stale CLI is the safety net for the rare case where rotation was suppressed (`--no-rotate-on-outer-mismatch`).
 
 The auto-clear respects two guards so it never destroys a user-explicit mode:
 
@@ -92,17 +92,17 @@ The auto-clear respects two guards so it never destroys a user-explicit mode:
 
 ## Worked example (the 88b27d defect)
 
-Session A: `peaks skill presence:set peaks-solo --mode full-auto` (outer A).
+Session A: `peaks skill presence:set peaks-code --mode full-auto` (outer A).
 Session A closes. Session B starts (outer B).
 
 ```bash
-# 1. Run init (the common entry into peaks-solo).
+# 1. Run init (the common entry into peaks-code).
 peaks workspace init --project . --json
 # → auto-rotates session binding AND auto-clears stale presence
 #   nextActions: ["Auto-cleared stale skill presence ..."]
 #   data.rotation: { previousSessionId: "session-A", reason: "outer-session-mismatch" }
 
-# 2. peaks-solo Step 1 (was: skip AskUserQuestion because presence.mode=full-auto).
+# 2. peaks-code Step 1 (was: skip AskUserQuestion because presence.mode=full-auto).
 # Now: presence is gone → no-presence → AskUserQuestion fires.
 
 peaks skill presence:check-stale --project . --json
@@ -112,7 +112,7 @@ peaks solo should-pause --step step-1-mode-select --mode full-auto --json
 # → { shouldPause: true, reason: "step=step-1-mode-select is a mode/context-selection step → always pause" }
 
 # 3. User picks a profile (or repeats "full-auto"). Then:
-peaks skill presence:set peaks-solo --mode full-auto --gate startup
+peaks skill presence:set peaks-code --mode full-auto --gate startup
 # → re-stamps with outer=B. Future sessions that read this presence
 #   see outerSessionId=outer-B matching THEIR outer=B → not stale.
 ```
@@ -120,5 +120,5 @@ peaks skill presence:set peaks-solo --mode full-auto --gate startup
 ## ACL — what NOT to do
 
 - **NEVER** skip Step 1 just because `.peaks/_runtime/active-skill.json` shows a `mode` field. Run `presence:check-stale` first.
-- **NEVER** call `peaks skill presence:clear` from peaks-solo to "fix" a stale mode. The auto-clear path is `peaks workspace init`'s job; manual clears destroy user-explicit mode choices that may belong to another live outer session.
-- **NEVER** set the presence `mode` field from inside a sub-agent (peaks-rd, peaks-qa, etc.). Sub-agents may read presence to honour the user's chosen mode but the write authority for Step 1 belongs to the peaks-solo driver.
+- **NEVER** call `peaks skill presence:clear` from peaks-code to "fix" a stale mode. The auto-clear path is `peaks workspace init`'s job; manual clears destroy user-explicit mode choices that may belong to another live outer session.
+- **NEVER** set the presence `mode` field from inside a sub-agent (peaks-rd, peaks-qa, etc.). Sub-agents may read presence to honour the user's chosen mode but the write authority for Step 1 belongs to the peaks-code driver.

package/skills/{peaks-solo → peaks-code}/references/mode-selection.md

@@ -18,4 +18,4 @@ Map the user's selection to the `--mode` flag value (used by `peaks skill presen
 
 > Note: `peaks workflow route --mode solo|team` is a **different** CLI dimension (solo developer vs team flow) and is unrelated to the profile choice here. Do not conflate them.
 
-If the user already names a profile in their invocation (e.g. `/peaks-solo --full-auto`, "用全自动模式"), skip this question and use the named profile directly.
+If the user already names a profile in their invocation (e.g. `/peaks-code --full-auto`, "用全自动模式"), skip this question and use the named profile directly.

package/skills/{peaks-solo → peaks-code}/references/openspec-workflow.md

@@ -24,7 +24,7 @@ Rules Solo applies:
 
 ## Refactor workflow wiring
 
-For `peaks-solo refactor` runs against a repository with `openspec/`:
+For `peaks-code refactor` runs against a repository with `openspec/`:
 
 1. RD entry gate — `peaks openspec validate <id>` must pass and `peaks openspec to-rd <id>` must return `acceptance.length > 0`.
 2. Each slice must reference one OpenSpec tasks section as its commit boundary (per `references/openspec-commit-boundaries.md` in peaks-sc).

package/skills/{peaks-solo → peaks-code}/references/project-scan-checklist.md

@@ -1,6 +1,6 @@
 # Peaks-Loop Pre-RD project scan checklist
 
-> Extracted from `skills/peaks-solo/SKILL.md` on 2026-06-09 (slice 019 — slim skill files to references) to keep SKILL.md under the 800-line cap from `common/coding-style.md`. The content below is the verbatim Pre-RD project scan checklist that was previously inline; nothing was paraphrased, just relocated.
+> Extracted from `skills/peaks-code/SKILL.md` on 2026-06-09 (slice 019 — slim skill files to references) to keep SKILL.md under the 800-line cap from `common/coding-style.md`. The content below is the verbatim Pre-RD project scan checklist that was previously inline; nothing was paraphrased, just relocated.
 
 Before handing off to `peaks-rd`, scan the project and record findings to `.peaks/_runtime/<sessionId>/rd/project-scan.md`. RD and UI roles read this before starting work. **project-scan.md is a session-scoped singleton** — check if it already exists before regenerating (e.g. via `ls .peaks/_runtime/<sessionId>/rd/project-scan.md`). If it exists and is complete (has `## Archetype` and `## Project mode` sections), reuse it. Only regenerate if missing or incomplete.
 

package/skills/{peaks-solo → peaks-code}/references/refactor-mode.md

@@ -1,6 +1,6 @@
 # Peaks Solo Refactor Mode
 
-`peaks-solo refactor` is the primary MVP path.
+`peaks-code refactor` is the primary MVP path.
 
 ## Flow
 

package/skills/{peaks-solo → peaks-code}/references/resume-detection.md

@@ -60,4 +60,4 @@ done
 **Strict quality guarantee (per user's hard rule: "严格要保证不能比当前的效果差")**:
 - If no in-flight slice is detected, this step is a no-op: zero extra commands beyond the existing Step 0 probe, zero extra token cost.
 - If an in-flight slice is detected, the cost is one `find` + one `grep` loop (sub-millisecond) + one `AskUserQuestion` (one round-trip). The savings are 3-5k tokens (the cost of manually re-reading 3-5 artifact files).
-- The dogfood test in `tests/unit/skill-resume-mode.test.ts` (8 cases, bash-fixture shim — the legacy interface used by `skills/peaks-solo-resume`) and `tests/unit/services/skill/resume-detector.test.ts` (24 cases, the canonical TypeScript classifier at `src/services/skill/resume-detector.ts`) together cover: (a) fresh / complete / resume:rd-planning / resume:qa-validation / resume:txt-handoff state-based classifications, (b) the "Other resume triggers" overrides (missing `rd/tech-doc.md` → `rd-planning`; missing `rd/code-review.md` or `rd/security-review.md` → `rd-review-fanout`; missing `qa/test-reports/<rid>.md` → `qa-execution`), (c) the mid-implementation distinction (`spec-locked` / `implemented` / `running` / `blocked` all return `in-flight:<state>`), (d) the primary-vs-abandoned filter (multiple RDs → spec-locked wins; single blocked RD stays primary; 2+ all-abandoned → fresh), (e) the legacy `.peaks/_runtime/<sessionId>/` path fallback, and (f) determinism across two invocations on the same fixture.
+- The dogfood test in `tests/unit/skill-resume-mode.test.ts` (8 cases, bash-fixture shim — the legacy interface used by `skills/peaks-resume`) and `tests/unit/services/skill/resume-detector.test.ts` (24 cases, the canonical TypeScript classifier at `src/services/skill/resume-detector.ts`) together cover: (a) fresh / complete / resume:rd-planning / resume:qa-validation / resume:txt-handoff state-based classifications, (b) the "Other resume triggers" overrides (missing `rd/tech-doc.md` → `rd-planning`; missing `rd/code-review.md` or `rd/security-review.md` → `rd-review-fanout`; missing `qa/test-reports/<rid>.md` → `qa-execution`), (c) the mid-implementation distinction (`spec-locked` / `implemented` / `running` / `blocked` all return `in-flight:<state>`), (d) the primary-vs-abandoned filter (multiple RDs → spec-locked wins; single blocked RD stays primary; 2+ all-abandoned → fresh), (e) the legacy `.peaks/_runtime/<sessionId>/` path fallback, and (f) determinism across two invocations on the same fixture.

package/skills/{peaks-solo → peaks-code}/references/runbook.md

@@ -1,11 +1,11 @@
 # Peaks-Loop Default Runbook (orchestrator, full-auto profile)
 
-> **Maintenance**: The numbered workflow list in `skills/peaks-solo/SKILL.md` (steps 0-11) is the canonical phase sequence. This runbook is the executable CLI transcription. When updating, keep both in lockstep — a change to one must be reflected in the other.
+> **Maintenance**: The numbered workflow list in `skills/peaks-code/SKILL.md` (steps 0-11) is the canonical phase sequence. This runbook is the executable CLI transcription. When updating, keep both in lockstep — a change to one must be reflected in the other.
 >
 > **Why this is a reference, not inline**: the runbook is a stable, copy-pasteable shell (~150 lines of bash) that does not change between skill runs. Inlining it bloats the orchestrator skill body past the 800-line cap (per `common/coding-style.md`). Extracting it here keeps SKILL.md focused on flow / decisions / contracts, while the runbook stays as the canonical place for the CLI sequence.
 >
 > **How peaks-loop tooling reads this file**:
-> - `peaks skill runbook peaks-solo` (CLI) reads the `## Default runbook` section in either SKILL.md or `references/runbook.md` (whichever has the bash code).
+> - `peaks skill runbook peaks-code` (CLI) reads the `## Default runbook` section in either SKILL.md or `references/runbook.md` (whichever has the bash code).
 > - The test in `tests/unit/skill-default-runbook.test.ts` looks for `## Default runbook` in SKILL.md first, then falls back to `references/runbook.md` here.
 
 ## Default runbook — CLI sequence
@@ -22,7 +22,7 @@ peaks sub-agent dispatch <role> --prompt "<body>" --request-id <rid> --batch-id
 # 0. Peaks-Loop Snapshot + 0.5 Peaks-Loop Workspace + 0.6 Peaks-Loop Project scan + 0.7 Peaks-Loop Existing-system extraction
 peaks doctor --json
 peaks project dashboard --project <repo> --json
-peaks skill runbook peaks-solo --json
+peaks skill runbook peaks-code --json
 peaks workspace init --project <repo> --json
 peaks workspace reconcile --project <repo> --json
 peaks scan archetype --project <repo> --json
@@ -80,7 +80,7 @@ peaks request transition <rid> --role prd --state handed-off --project <repo> --
 #     sub-agent may also call peaks request init itself (idempotent on the same rid);
 #     Solo's call here is the source of truth. Only init roles that are in the
 #     swarm plan — roles not in the plan do not get a slot yet.
-peaks skill presence:set peaks-solo --project <repo> --mode <mode> --gate swarm-fan-out
+peaks skill presence:set peaks-code --project <repo> --mode <mode> --gate swarm-fan-out
 # for each role in swarm-plan.subAgents:
 # peaks request init --role ui --id <rid> --project <repo> --apply --type <type> --json
 # peaks request init --role rd --id <rid> --project <repo> --apply --type <type> --json
@@ -99,7 +99,7 @@ peaks skill presence:set peaks-solo --project <repo> --mode <mode> --gate swarm-
 peaks sc build-dag --change-id <cid> --project <repo> --json > .peaks/_runtime/<sid>/sc/slice-dag.json
 peaks sub-agent dispatch --from-dag .peaks/_runtime/<sid>/sc/slice-dag.json --batch-id <id> --project <repo> --json
 # 3c. After fan-out, Solo restores presence once and runs Gate B (ls checks):
-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
 ls .peaks/_runtime/<sid>/prd/requests/<rid>.md                # PRD artefact must exist (Gate B hard)
 # feature / refactor → ls .peaks/_runtime/<sid>/rd/tech-doc.md
 # bugfix             → ls .peaks/_runtime/<sid>/rd/bug-analysis.md

package/skills/{peaks-solo → peaks-code}/references/skill-presence-and-title.md

@@ -7,7 +7,7 @@
 Step 0 already set presence with no mode. Now that the mode is known (user selected or explicitly named), re-run presence:set so the header/status line shows the profile:
 
 ```bash
-peaks skill presence:set peaks-solo --project <repo> --mode <mode-value> --gate startup
+peaks skill presence:set peaks-code --project <repo> --mode <mode-value> --gate startup
 ```
 
 On the first presence:set in a project, ensure the out-of-band status bar is installed so the user can see at a glance that Peaks is orchestrating — it renders the active skill in Claude Code's terminal status line, independent of model output:
@@ -16,9 +16,9 @@ On the first presence:set in a project, ensure the out-of-band status bar is ins
 peaks statusline install --project <repo>   # idempotent; skips if already installed
 ```
 
-Then display the compact status header: `Peaks-Loop Skill: peaks-solo | Peaks-Loop Gate: startup | Next: <one short action>`. Display this header on EVERY turn while the skill is active.
+Then display the compact status header: `Peaks-Loop Skill: peaks-code | Peaks-Loop Gate: startup | Next: <one short action>`. Display this header on EVERY turn while the skill is active.
 
-Update with `peaks skill presence:set peaks-solo --project <repo> --mode <mode> --gate <gate>` when gates change. The presence file persists across the full workflow lifecycle — do NOT clear it at workflow end.
+Update with `peaks skill presence:set peaks-code --project <repo> --mode <mode> --gate <gate>` when gates change. The presence file persists across the full workflow lifecycle — do NOT clear it at workflow end.
 
 ## Step 2.5 — Set session title
 

package/skills/{peaks-solo → peaks-code}/references/standards-preflight.md

@@ -13,7 +13,7 @@ Use `standards init` for first-time creation and `standards update` for existing
 
 Do not hand-write standards file mutations inside the skill.
 
-For project-analysis requests such as "分析项目" / "分析下这个项目", Step 0 still applies: the workspace is initialized and `peaks-solo` presence is set before any analysis output. These requests run the lightweight analysis branch (project scan + standards dry-run) rather than the full RD/QA pipeline, but they never skip workspace anchoring or exit the workflow. The handoff must include an explicit **Standards increment** section. Report the current `CLAUDE.md` and `.claude/rules/**` status from the dry-run output as incremental deltas, not just a generic preflight note:
+For project-analysis requests such as "分析项目" / "分析下这个项目", Step 0 still applies: the workspace is initialized and `peaks-code` presence is set before any analysis output. These requests run the lightweight analysis branch (project scan + standards dry-run) rather than the full RD/QA pipeline, but they never skip workspace anchoring or exit the workflow. The handoff must include an explicit **Standards increment** section. Report the current `CLAUDE.md` and `.claude/rules/**` status from the dry-run output as incremental deltas, not just a generic preflight note:
 
 - whether `CLAUDE.md` is missing, existing, planned, skipped, appended, or review-only;
 - which `.claude/rules/**` files are planned, existing, skipped, appended, or review-only;

package/skills/{peaks-solo → peaks-code}/references/step-0-55-1x-detection.md

@@ -8,9 +8,9 @@ The peaks-loop 1.x → 2.0 closeout ships:
 
 1. A postinstall that auto-detects 1.x state and dispatches the upgrade (slice 1, commit `b6e34e6`).
 2. A standards-migrate path that thins `.claude/rules/**/*.md` and scaffolds `.peaks/standards/` (slice 2, commit `33dd392`).
-3. **THIS STEP** — a peaks-solo startup sequence probe that detects 1.x state when the user invokes `/peaks-solo` directly in a 1.x consumer project, and prompts the user to upgrade.
+3. **THIS STEP** — a peaks-code startup sequence probe that detects 1.x state when the user invokes `/peaks-code` directly in a 1.x consumer project, and prompts the user to upgrade.
 
-The 1.x user experience is: "I just typed /peaks-solo. Why is it not working in 2.0 mode?" Step 0.55 catches this case and surfaces an `AskUserQuestion` with a one-click upgrade.
+The 1.x user experience is: "I just typed /peaks-code. Why is it not working in 2.0 mode?" Step 0.55 catches this case and surfaces an `AskUserQuestion` with a one-click upgrade.
 
 ## Detection algorithm
 
@@ -35,7 +35,7 @@ The CLI returns:
   },
   "warnings": [],
   "nextActions": [
-    "Detected 1.x state. peaks-solo Step 0.55 should present an AskUserQuestion to invoke `peaks upgrade --to 2.0 --auto --project /path/to/project`."
+    "Detected 1.x state. peaks-code Step 0.55 should present an AskUserQuestion to invoke `peaks upgrade --to 2.0 --auto --project /path/to/project`."
   ]
 }
 ```
@@ -52,8 +52,8 @@ The TS mirror in `src/services/upgrade/1x-detector-service.ts` is the canonical
 
 | Option | What it does |
 |---|---|
-| Run `peaks upgrade --to 2.0 --auto --project <root>` (Recommended) | Invokes the umbrella. The user sees the 6 sub-step results in the terminal. After the upgrade, re-run peaks-solo with the standing 2.0 layout. Persist `autoUpgradePrompt: opt-in` to `.peaks/preferences.json`. |
-| Skip for this session | Continue with the standing 1.x layout. Persist `autoUpgradePrompt: skip-this-session` to `.peaks/preferences.json`. The next time the user invokes peaks-solo in this project, the question re-asks. |
+| Run `peaks upgrade --to 2.0 --auto --project <root>` (Recommended) | Invokes the umbrella. The user sees the 6 sub-step results in the terminal. After the upgrade, re-run peaks-code with the standing 2.0 layout. Persist `autoUpgradePrompt: opt-in` to `.peaks/preferences.json`. |
+| Skip for this session | Continue with the standing 1.x layout. Persist `autoUpgradePrompt: skip-this-session` to `.peaks/preferences.json`. The next time the user invokes peaks-code in this project, the question re-asks. |
 | Never ask again for this project | Persist `autoUpgradePrompt: skip-forever` to `.peaks/preferences.json`. Step 0.55 becomes a no-op for this project from now on. The user can re-enable later by removing the `autoUpgradePrompt` key from preferences.json. |
 
 ## Persistence contract