peaks-loop 3.0.0 → 3.0.2

package/skills/peaks-solo/references/micro-cycle.md

@@ -160,7 +160,7 @@ verdict=return-to-rd → RD 修 (new slice 内部走 micro-cycle)
 
 # Mandatory RD QA repair loop (AUTO-PROCEED)
 
-> Body of `## Peaks-Cli Mandatory RD QA repair loop`.
+> Body of `## Peaks-Loop Mandatory RD QA repair loop`.
 
 > **CLI gate enforcement**: `peaks request transition` now refuses to move RD/QA to gated states when required artifacts are missing. The required files depend on `--type` chosen at `peaks request init` (default `feature`):
 >
@@ -171,13 +171,13 @@ verdict=return-to-rd → RD 修 (new slice 内部走 micro-cycle)
 >
 > When PRD lands, classify the request type before running `peaks request init` for every role — pass `--type <type>` so the artifact records it and downstream transitions enforce the right gates. Misclassifying a feature as `docs` to skip gates is a workflow violation. If a transition fails with `code: PREREQUISITES_MISSING`, the response lists every missing path — produce them, then re-transition. For one-off exceptions, the escape hatch `--allow-incomplete --reason "<text>"` records the bypass in the artifact transition note.
 
-After `peaks-rd` finishes any implementation, repair, or code-output slice, Peaks-Cli Solo MUST automatically route the result to `peaks-qa` without waiting for user confirmation. This is not optional in full-auto mode. Solo must not declare the workflow complete, emit a TXT handoff, or stop at RD completion.
+After `peaks-rd` finishes any implementation, repair, or code-output slice, Peaks-Loop Solo MUST automatically route the result to `peaks-qa` without waiting for user confirmation. This is not optional in full-auto mode. Solo must not declare the workflow complete, emit a TXT handoff, or stop at RD completion.
 
 **How Solo invokes another role (mechanism, not metaphor):**
 
 Solo is itself a skill running in the current session. There are **two distinct mechanisms** in this skill, and they MUST NOT be confused:
 
-1. **Swarm fan-out (planning side, after PRD confirmed)** — uses `peaks sub-agent dispatch <role>` to launch real concurrent sub-agents. The CLI returns a per-IDE tool-call descriptor that the LLM executes in its environment. See "Peaks-Cli Swarm parallel phase" above for the full contract. Sub-agents do NOT call Skill(...) back into the role; they execute the role's instructions inline from the prompt.
+1. **Swarm fan-out (planning side, after PRD confirmed)** — uses `peaks sub-agent dispatch <role>` to launch real concurrent sub-agents. The CLI returns a per-IDE tool-call descriptor that the LLM executes in its environment. See "Peaks-Loop Swarm parallel phase" above for the full contract. Sub-agents do NOT call Skill(...) back into the role; they execute the role's instructions inline from the prompt.
 2. **Sequential handoff (execution side, RD↔QA repair loop)** — Solo is the only loop, and after RD or QA finishes (whether as a sub-agent or directly), Solo drives the next step from the orchestrator seat. Do NOT use the `Skill` tool to "reactivate" peaks-rd or peaks-qa in the main loop; doing so is the v1.x anti-pattern that masqueraded as "calling the role" but actually just re-prompted the same session. From v1.3 onward, the main loop drives roles via the CLI gate (`peaks request transition`) and reads back artefacts (`peaks request show ... --json`); the actual RD/QA work is either done inline by Solo (when Solo has just been re-invoked by the user) or by a Task sub-agent (in swarm mode).
 
 After RD completes (whether inline or sub-agent), Solo does not stop — it must advance to QA. There is no "RD done, ask the user" state in full-auto mode. The only valid stops are: (a) QA verdict=pass, (b) repair cap hit, (c) explicit user cancel.
@@ -190,7 +190,7 @@ After RD completes (whether inline or sub-agent), Solo does not stop — it must
 peaks skill presence:set peaks-solo --project <repo> --mode <mode> --gate <current-gate>
 ```
 
-This keeps the CLAUDE.md status header accurate (`Peaks-Cli 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-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.
 
 **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).
 

package/skills/peaks-solo/references/mode-selection.md

@@ -1,11 +1,11 @@
 # Step 1 — Mode selection
 
-> Body of `### Peaks-Cli Step 1`. After Step 0 has anchored the workspace and presence, when the user invokes Peaks-Cli Solo without explicitly naming an execution profile, use `AskUserQuestion` to pick the profile. Present the recommended full-auto path as the first/default option with a practical description for each:
+> Body of `### Peaks-Loop Step 1`. After Step 0 has anchored the workspace and presence, when the user invokes Peaks-Loop Solo without explicitly naming an execution profile, use `AskUserQuestion` to pick the profile. Present the recommended full-auto path as the first/default option with a practical description for each:
 
-1. **Full auto (Recommended)** — Peaks-Cli handles planning, role coordination, validation, and compact handoff end-to-end while preserving required confirmation gates for risky or shared-state actions.
-2. **Assisted** — Peaks-Cli proposes plans, artifacts, and checks, then pauses for user decisions at major workflow boundaries.
-3. **Swarm** — Peaks-Cli maximizes safe parallel role/worker execution for larger RD or QA workloads while keeping reducer validation and artifact boundaries explicit.
-4. **Strict** — Peaks-Cli uses the most conservative gates: explicit confirmations, strict slice specs, coverage evidence, QA acceptance, and commit boundaries before continuing.
+1. **Full auto (Recommended)** — Peaks-Loop handles planning, role coordination, validation, and compact handoff end-to-end while preserving required confirmation gates for risky or shared-state actions.
+2. **Assisted** — Peaks-Loop proposes plans, artifacts, and checks, then pauses for user decisions at major workflow boundaries.
+3. **Swarm** — Peaks-Loop maximizes safe parallel role/worker execution for larger RD or QA workloads while keeping reducer validation and artifact boundaries explicit.
+4. **Strict** — Peaks-Loop uses the most conservative gates: explicit confirmations, strict slice specs, coverage evidence, QA acceptance, and commit boundaries before continuing.
 
 Map the user's selection to the `--mode` flag value (used by `peaks skill presence:set`; `presence:set --mode` accepts any string, so the name matches the user-facing label rather than overloading "solo" which is also the skill name):
 

package/skills/peaks-solo/references/openspec-workflow.md

@@ -31,7 +31,7 @@ For `peaks-solo refactor` runs against a repository with `openspec/`:
 3. QA exit gate — re-run `peaks openspec validate <id>` after implementation; record the result in the QA validation report.
 4. Archive — `peaks openspec archive <id> --apply` only after QA passes the exit gate and SC closes the final commit.
 
-If the consuming LLM needs an MCP server for docs lookup or research (e.g. Context7), it checks its own tool list for `mcp__<server>__*` and tells the user the install command if absent. peaks-cli is no longer in the install path; the LLM is the executor, the IDE is the dispatcher.
+If the consuming LLM needs an MCP server for docs lookup or research (e.g. Context7), it checks its own tool list for `mcp__<server>__*` and tells the user the install command if absent. peaks-loop is no longer in the install path; the LLM is the executor, the IDE is the dispatcher.
 
 ## Boundary
 
@@ -41,7 +41,7 @@ Solo must not write `openspec/changes/**` or `~/.claude/settings.json` directly.
 
 # Step 0.5 — OpenSpec first-run opt-in (conditional)
 
-> Body of `### Peaks-Cli Step 0.5`. After the workspace is anchored, before project scan, Solo checks whether
+> Body of `### Peaks-Loop Step 0.5`. After the workspace is anchored, before project scan, Solo checks whether
 the project already has an `openspec/` directory. The lifecycle
 (`render → validate → show → to-rd → validate → archive`) only applies
 when `openspec/` exists; without it, RD/QA/SC silently skip the

package/skills/peaks-solo/references/playwright-mcp-multi-terminal.md

@@ -29,7 +29,7 @@ peaks playwright stop  [--terminal <id>] [--project <path>] [--json]
 
 `peaks playwright start` tries ports in the order `8931, 8932, 8933, ..., 8949`. The first port that is **not** bound by anything (probe uses `net.createServer().listen()`; an `EADDRINUSE` is a busy port) is used. If 8931..8949 are all busy, the command exits with `PORT_EXHAUSTED`.
 
-The CLI does NOT bundle the playwright-mcp binary. It shells out to `npx playwright-mcp@latest --port=<n> --browser=<b> --user-data-dir=<path>`. peaks-cli is the lifecycle orchestrator, not the install medium.
+The CLI does NOT bundle the playwright-mcp binary. It shells out to `npx playwright-mcp@latest --port=<n> --browser=<b> --user-data-dir=<path>`. peaks-loop is the lifecycle orchestrator, not the install medium.
 
 ## Session file layout
 

package/skills/peaks-solo/references/project-memory-loading.md

@@ -1,6 +1,6 @@
 # Step 2.3 — Load project memory
 
-> Body of `### Peaks-Cli Step 2.3`. Before planning any work, read the project's persistent memory — durable memories that survive across sessions:
+> Body of `### Peaks-Loop Step 2.3`. Before planning any work, read the project's persistent memory — durable memories that survive across sessions:
 
 ```bash
 peaks project memories --project <repo> --json

package/skills/peaks-solo/references/project-scan-checklist.md

@@ -1,4 +1,4 @@
-# Peaks-Cli Pre-RD project scan checklist
+# 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.
 

package/skills/peaks-solo/references/quality-gate-cheatsheet.md

@@ -1,6 +1,6 @@
 # Quality-gate commands (CLI cheat sheet)
 
-> Body of `## Peaks-Cli Quality-gate commands`. These commands harden the workflow against silent skips. Use them in the runbook at the points indicated; they all support `--json` and `--session-id`.
+> Body of `## Peaks-Loop Quality-gate commands`. These commands harden the workflow against silent skips. Use them in the runbook at the points indicated; they all support `--json` and `--session-id`.
 
 | Command | Purpose | When to run | Non-zero exit when |
 |---|---|---|---|

package/skills/peaks-solo/references/resume-detection.md

@@ -1,6 +1,6 @@
 # Step 0.7 — Detect unfinished work and offer resume
 
-> Body of `### Peaks-Cli Step 0.7`. After Step 0 has anchored the workspace and presence, before Step 1 mode selection, run the resume-detection probe. If the current session has in-flight slice artifacts, the user is most likely "continuing" — surface resume options instead of starting a fresh PRD.
+> Body of `### Peaks-Loop Step 0.7`. After Step 0 has anchored the workspace and presence, before Step 1 mode selection, run the resume-detection probe. If the current session has in-flight slice artifacts, the user is most likely "continuing" — surface resume options instead of starting a fresh PRD.
 
 **Why this is a separate step** (per `feedback_peaks_solo_natural_language_primary` — a high-frequency request shape, see also the user's "继续完成刚才为完成的" pattern from session `2026-06-04-session-b60252`): the LLM was previously re-reading 3-5 artifact files to determine workflow state, wasting 3-5k tokens per resume request. This step replaces that work with a single deterministic read.
 

package/skills/peaks-solo/references/runbook.md

@@ -1,10 +1,10 @@
-# Peaks-Cli Default Runbook (orchestrator, full-auto profile)
+# 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.
 >
 > **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-cli tooling reads this file**:
+> **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).
 > - 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.
 
@@ -19,21 +19,21 @@ peaks sub-agent dispatch <role> --prompt "<body>" --request-id <rid> --batch-id
 ```
 
 ```bash
-# 0. Peaks-Cli Snapshot + 0.5 Peaks-Cli Workspace + 0.6 Peaks-Cli Project scan + 0.7 Peaks-Cli Existing-system extraction
+# 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 workspace init --project <repo> --json
 peaks workspace reconcile --project <repo> --json
 peaks scan archetype --project <repo> --json
-# → copy archetype, frontendOnly, signals into .peaks/_runtime/<session-id>/rd/project-scan.md (Peaks-Cli Gate A)
+# → copy archetype, frontendOnly, signals into .peaks/_runtime/<session-id>/rd/project-scan.md (Peaks-Loop Gate A)
 # → copy libraries[] into .peaks/_runtime/<session-id>/rd/project-scan.md under `## Library versions`
 peaks scan libraries --project <repo> --json
 # → if archetype != greenfield AND archetype != unknown:
 peaks scan existing-system --project <repo> --json
-# → copy tokens, sources, conventions, inconsistencies into .peaks/_runtime/<session-id>/system/existing-system.md (Peaks-Cli Gate A.5)
+# → copy tokens, sources, conventions, inconsistencies into .peaks/_runtime/<session-id>/system/existing-system.md (Peaks-Loop Gate A.5)
 
-# 1. Peaks-Cli Standards preflight + apply
+# 1. Peaks-Loop Standards preflight + apply
 #    Run dry-run first to inspect deltas, then APPLY. In full-auto and swarm modes,
 #    --apply is the default — Standards files (CLAUDE.md, .claude/rules/**) live INSIDE
 #    the target project and are required for downstream skill preflight, so producing
@@ -43,9 +43,9 @@ peaks standards init   --project <repo> --dry-run --json
 # or: peaks standards update --project <repo> --dry-run --json
 peaks standards init   --project <repo> --apply --json
 # or: peaks standards update --project <repo> --apply --json
-# After apply, verify the files actually exist on disk (see Peaks-Cli Gate G).
+# After apply, verify the files actually exist on disk (see Peaks-Loop Gate G).
 
-# 2. Peaks-Cli PRD (Assisted/Strict: [CONFIRM] before confirmed-by-user)
+# 2. Peaks-Loop PRD (Assisted/Strict: [CONFIRM] before confirmed-by-user)
 # Classify the request type from the PRD: feature | bugfix | refactor | docs | config | chore
 # This drives RD/QA gate strictness — see "Mandatory RD QA repair loop" for the matrix.
 peaks request init --role prd --id <rid> --project <repo> --apply --type <type> --json
@@ -59,7 +59,7 @@ peaks request lint <rid> --role prd --project <repo> --json
 peaks request transition <rid> --role prd --state confirmed-by-user --project <repo> --json
 peaks request transition <rid> --role prd --state handed-off --project <repo> --json
 
-# 3. Peaks-Cli Default sub-agent fan-out (slice 5 contract)
+# 3. Peaks-Loop Default sub-agent fan-out (slice 5 contract)
 #    Solo computes the swarm plan from --type + frontendOnly + frontend-keyword scan,
 #    writes it to .peaks/_runtime/<sid>/sc/swarm-plan.json, then writes the slice
 #    DAG to .peaks/_runtime/<sid>/sc/slice-dag.json and launches ONE
@@ -68,7 +68,7 @@ peaks request transition <rid> --role prd --state handed-off --project <repo> --
 #    same topological level — that is the canonical "fan-out" signal. The
 #    orchestrator emits N parallel `buildToolCall` descriptors in ONE response;
 #    the LLM-side runner executes them concurrently.
-#    See "Peaks-Cli Default sub-agent fan-out" above for the default rule and
+#    See "Peaks-Loop Default sub-agent fan-out" above for the default rule and
 #    exceptions; the gate logic is single-sourced in references/swarm-dispatch-contract.md.
 #    Hard rule: do NOT call Skill(skill="peaks-rd" | "peaks-qa" | "peaks-ui") from
 #    the Swarm phase — that's the v1.x anti-pattern. And do NOT issue N sequential
@@ -107,23 +107,23 @@ ls .peaks/_runtime/<sid>/qa/test-cases/<rid>.md                # QA test-cases (
 # ui (only when in plan):
 ls .peaks/_runtime/<sid>/ui/design-draft.md 2>&1               # non-blocking (Gate B info)
 # Apply the degradation rules in the main SKILL.md if any artefact is missing.
-# → Peaks-Cli Gate B convergence check. Assisted/Strict: [CONFIRM]
+# → Peaks-Loop Gate B convergence check. Assisted/Strict: [CONFIRM]
 
-# 4. Peaks-Cli RD planning artifact (the file required by the prerequisite gate)
+# 4. Peaks-Loop RD planning artifact (the file required by the prerequisite gate)
 #    feature / refactor → write .peaks/_runtime/<id>/rd/tech-doc.md
 #    bugfix             → write .peaks/_runtime/<id>/rd/bug-analysis.md
 #    config             → no planning artifact required at this state
 #    docs / chore       → no planning artifact required
 peaks request transition <rid> --role rd --state implemented --project <repo> --json
 
-# 5. Peaks-Cli Code review + security review BEFORE qa-handoff transition.
+# 5. Peaks-Loop Code review + security review BEFORE qa-handoff transition.
 #    Produce the evidence files the CLI gate enforces:
 #      - .peaks/_runtime/<id>/rd/code-review.md     (CRITICAL/HIGH findings + fixes; required for feature/bugfix/refactor)
 #      - .peaks/_runtime/<id>/rd/security-review.md (required for feature/bugfix/refactor/config)
 #    Then transition. If --type is docs/chore the gate is empty and the transition is unguarded.
 peaks request transition <rid> --role rd --state qa-handoff --project <repo> --json
 
-# 6. Peaks-Cli QA validation (AUTO-PROCEED from RD in full-auto)
+# 6. Peaks-Loop QA validation (AUTO-PROCEED from RD in full-auto)
 #    Before each QA transition, produce the evidence files the CLI gate enforces:
 #      Before qa:running        → .peaks/_runtime/<id>/qa/test-cases/<rid>.md
 peaks request transition <rid> --role qa --state running --project <repo> --json
@@ -131,9 +131,9 @@ peaks request transition <rid> --role qa --state running --project <repo> --json
 #                                 + .peaks/_runtime/<id>/qa/security-findings.md
 #                                 + .peaks/_runtime/<id>/qa/performance-findings.md (feature/refactor only)
 peaks request transition <rid> --role qa --state verdict-issued --project <repo> --json
-# → Peaks-Cli Gate D check. Assisted/Strict: [CONFIRM]
+# → Peaks-Loop Gate D check. Assisted/Strict: [CONFIRM]
 
-# 7. Peaks-Cli RD↔QA repair loop — if verdict is return-to-rd, re-run 4 through 6 until QA passes or blocked TXT.
+# 7. Peaks-Loop RD↔QA repair loop — if verdict is return-to-rd, re-run 4 through 6 until QA passes or blocked TXT.
 #    Before invoking peaks-rd again, check the cycle count so you don't blow past the cap silently:
 peaks request repair-status <rid> --project <repo> --json
 # → atCap=true → STOP and emit a blocked TXT handoff. Do NOT enter another cycle.
@@ -143,18 +143,18 @@ peaks request repair-status <rid> --project <repo> --json
 peaks scan request-type-sanity --project <repo> --type <type> --json
 # → consistent=false → RD scope-creeped during repair; review before re-handoff.
 
-# 8. Peaks-Cli SC phase
+# 8. Peaks-Loop SC phase
 peaks sc impact --change-id <cid> --module <module> --file <path> --json
 peaks sc retention --slice-id <rid> --prd <prd> --rd <rd> --qa <qa> --json
 peaks sc validate --slice-id <rid> --json
 peaks sc boundary --slice-id <rid> --artifact <artifact> --code <file> --json
 
-# 9. Peaks-Cli OpenSpec archive (exit gate; only after QA pass, when openspec/ exists)
+# 9. Peaks-Loop OpenSpec archive (exit gate; only after QA pass, when openspec/ exists)
 peaks openspec validate <cid> --project <repo> --json
 peaks openspec archive <cid> --project <repo> --apply --json
 peaks workspace reconcile --project <repo> --apply --older-than 7
 
-# 10. Peaks-Cli TXT handoff — invoke peaks-txt which embeds memory markers and extracts
+# 10. Peaks-Loop TXT handoff — invoke peaks-txt which embeds memory markers and extracts
 #     peaks-txt writes the handoff capsule to .peaks/_runtime/<id>/txt/handoff.md. Inside the
 #     capsule body, peaks-txt embeds <!-- peaks-memory:start --> blocks for every
 #     stable project fact surfaced this session.
@@ -180,7 +180,7 @@ peaks memory extract --project <repo> --artifact .peaks/_runtime/<id>/txt/handof
 #      --apply is REQUIRED to write .peaks/memory/; without it the command only
 #      previews. The extract regenerates index.json in the same call.
 
-# 11. Peaks-Cli Final snapshot
+# 11. Peaks-Loop Final snapshot
 peaks project dashboard --project <repo> --json
 peaks skill doctor --json
 ```

package/skills/peaks-solo/references/skill-presence-and-title.md

@@ -1,6 +1,6 @@
 # Step 2 + 2.5 — Skill presence and session title
 
-> Combined body for `### Peaks-Cli Step 2: Re-set skill presence with the chosen mode` and `### Peaks-Cli Step 2.5: Set session title`.
+> Combined body for `### Peaks-Loop Step 2: Re-set skill presence with the chosen mode` and `### Peaks-Loop Step 2.5: Set session title`.
 
 ## Step 2 — Re-set skill presence
 
@@ -16,7 +16,7 @@ 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-Cli Skill: peaks-solo | Peaks-Cli 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-solo | 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.
 

package/skills/peaks-solo/references/standards-preflight.md

@@ -1,11 +1,11 @@
 # Project standards preflight
 
-> Body of `## Peaks-Cli Project standards preflight`. Before orchestrating an end-to-end code repository workflow, gather the project standards preflight status from RD and QA by calling the Peaks-Cli CLI:
+> Body of `## Peaks-Loop Project standards preflight`. Before orchestrating an end-to-end code repository workflow, gather the project standards preflight status from RD and QA by calling the Peaks-Loop CLI:
 
 - `peaks standards init --project <path> --dry-run`
 - `peaks standards update --project <path> --dry-run`
 
-Use `standards init` for first-time creation and `standards update` for existing `CLAUDE.md` append/review behavior. In `full-auto` and `swarm` profiles, `--apply` runs automatically after `--dry-run` succeeds — these files live inside the target project, are required for downstream skill preflight, and producing them is part of finishing the workflow (Peaks-Cli Gate G enforces this). `assisted` and `strict` profiles pause for explicit user confirmation between dry-run and apply.
+Use `standards init` for first-time creation and `standards update` for existing `CLAUDE.md` append/review behavior. In `full-auto` and `swarm` profiles, `--apply` runs automatically after `--dry-run` succeeds — these files live inside the target project, are required for downstream skill preflight, and producing them is part of finishing the workflow (Peaks-Loop Gate G enforces this). `assisted` and `strict` profiles pause for explicit user confirmation between dry-run and apply.
 
 **CRITICAL — Standards must reflect the project scan.** When generating or updating `CLAUDE.md`, the content must reference concrete findings from `.peaks/_runtime/<sessionId>/rd/project-scan.md`: the detected component library (e.g. "This project uses antd 5.x"), CSS solution (e.g. "Uses Less via Umi"), build tool, state management, and routing. Never emit a generic template that says "read .claude/rules/..." without naming the actual project stack. If the project-scan has not been run yet, run it before standards init/update.
 

package/skills/peaks-solo/references/step-0-55-1x-detection.md

@@ -1,10 +1,10 @@
 # Step 0.55 — 1.x → 2.0 detection reference
 
-> Body of `### Peaks-Cli Step 0.55`. Slice: 2026-06-12-solo-step-0-55-1x-detection.
+> Body of `### Peaks-Loop Step 0.55`. Slice: 2026-06-12-solo-step-0-55-1x-detection.
 
 ## Why this step exists
 
-The peaks-cli 1.x → 2.0 closeout ships:
+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`).
@@ -68,7 +68,7 @@ The decision is persisted via `peaks preferences set --project <root> --key auto
 ## What is NOT in this step
 
 - The auto-upgrade execution itself: the umbrella is invoked via the AskUserQuestion's recommended option. The umbrella's behavior (6 sub-commands + write-upgrade-record) is documented in the umbrella's own help text.
-- The postinstall auto-dispatch: that's `scripts/install-skills.mjs:autoUpgrade1xProjectIfPresent`, which fires fire-and-forget on `npm i -g peaks-cli@2.0`. Step 0.55 is the user-invoked path.
+- The postinstall auto-dispatch: that's `scripts/install-skills.mjs:autoUpgrade1xProjectIfPresent`, which fires fire-and-forget on `npm i -g peaks-loop@2.0`. Step 0.55 is the user-invoked path.
 - Re-authoring the 1.x detector heuristics: the implementation is a 1:1 mirror of the canonical `.mjs` version. Drift is prevented by the parity test.
 
 ## How this integrates with the rest of the workflow

package/skills/peaks-solo/references/sub-agent-dispatch.md

@@ -25,7 +25,7 @@ the skills compose. For sub-agent dispatch the relationship is:
 | 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) |
 
 This is the **inverse** of the prior shape: SKILL.md used to hardcode
-`Task(subagent_type="general-purpose", ...)`, which made peaks-cli
+`Task(subagent_type="general-purpose", ...)`, which made peaks-loop
 depend on Claude Code's specific tool name. Adding a new IDE meant
 editing every SKILL.md that mentioned sub-agents. With the new shape,
 the only per-IDE thing in the dispatch chain is the dispatcher — SKILL.md
@@ -178,7 +178,7 @@ to keep the user informed during the wait.
 
 **Slice #016 retirement (G3 prompt template — MCP subsystem removed)**:
 The MCP-decouple paragraph from slice #007-007 no longer applies.
-peaks-cli no longer manages MCP install or invocation. Sub-agents
+peaks-loop no longer manages MCP install or invocation. Sub-agents
 check their own tool list for `mcp__<server>__*` entries and invoke
 the tool by name directly. The only prompt-template addition that
 remains is the tool-list self-check:
@@ -304,7 +304,7 @@ The role's required artefact paths (also see peaks-ui/rd/qa SKILL.md and `refere
 | `rd-planning` | `.peaks/_runtime/<sessionId>/rd/tech-doc.md` (feature/refactor) or `.peaks/_runtime/<sessionId>/rd/bug-analysis.md` (bugfix) | PRD body, project-scan, existing-system, codegraph |
 | `qa-test-cases` | `.peaks/_runtime/<sessionId>/qa/test-cases/<rid>.md` | PRD body, RD planning artefact, project-scan, codegraph |
 
-**Solo launches all sub-agents in the swarm plan in a single message (multiple `peaks sub-agent dispatch` calls in parallel, each followed by execution of the returned toolCall)** — this is what gives real concurrency. Do not sequentialize them. The CLI returns N toolCall descriptors; the LLM fires all N in the same message; the IDE dispatches them concurrently; Solo then waits for all to return, runs `ls` checks against the paths above (Peaks-Cli Gate B), and only then advances to RD implementation.
+**Solo launches all sub-agents in the swarm plan in a single message (multiple `peaks sub-agent dispatch` calls in parallel, each followed by execution of the returned toolCall)** — this is what gives real concurrency. Do not sequentialize them. The CLI returns N toolCall descriptors; the LLM fires all N in the same message; the IDE dispatches them concurrently; Solo then waits for all to return, runs `ls` checks against the paths above (Peaks-Loop Gate B), and only then advances to RD implementation.
 
 **Hard prohibitions on sub-agents** (also passed in each dispatch prompt):
 

package/skills/peaks-solo/references/swarm-dispatch-contract.md

@@ -2,11 +2,11 @@
 
 > 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.
 
-## Peaks-Cli Swarm parallel phase (sub-agent fan-out, default)
+## 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-Cli Default
+> fan-out rule** in `skills/peaks-solo/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
@@ -158,7 +158,7 @@ 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-Cli Skill: peaks-solo | Peaks-Cli 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-solo | 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.
 

package/skills/peaks-solo/references/workflow-gates-and-types.md

@@ -1,14 +1,14 @@
-# Peaks-Cli Workflow Order + Request Type Classification + Transition Verification Gates
+# 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.
 >
 > **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-cli tooling reads this file**:
+> **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.
 > - 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-Cli Request type classification (MANDATORY before `peaks request init`)
+## Peaks-Loop Request type classification (MANDATORY before `peaks request init`)
 
 Before initializing any role artifact, classify the request into exactly one of six types. The choice drives RD/QA gate strictness (see "Mandatory RD QA repair loop"). Pick the **primary intent** — if a request could fit two types, the higher-strictness one wins.
 
@@ -25,34 +25,34 @@ Before initializing any role artifact, classify the request into exactly one of
 
 For ambiguous cases (e.g. "improve login flow"), ask the user to clarify before initializing. The cost of one `AskUserQuestion` round is much lower than running the wrong gate matrix for the whole workflow.
 
-When Peaks-Cli Solo coordinates development in a code repository, keep this order explicit:
+When Peaks-Loop Solo coordinates development in a code repository, keep this order explicit:
 
-0. **Peaks-Cli Snapshot** — `peaks doctor` + `peaks project dashboard` to capture baseline state before anything else;
-0.5. **Peaks-Cli Workspace initialization** — `.peaks/_runtime/<session-id>/` created, directory structure verified;
-0.6. **Peaks-Cli Project scan** — archetype, component library, CSS framework, build tool, state management, routing, data fetching, legacy signals detected and recorded to `.peaks/_runtime/<session-id>/rd/project-scan.md`;
-0.7. **Peaks-Cli Existing-system extraction** (MANDATORY when archetype ∈ {legacy-frontend, legacy-fullstack, frontend-monorepo}; SKIP for greenfield) — extract visual tokens and code conventions from the live codebase to `.peaks/_runtime/<session-id>/system/existing-system.md`. The path lives under `system/` (not `ui/`) because the file also records non-UI conventions (service-layer signatures, hooks, naming) that backend-only or legacy-fullstack work consumes. See `references/existing-system-extraction.md`. UI design-draft and RD implementation MUST treat the extracted tokens and conventions as hard constraints;
-1. **Peaks-Cli Standards preflight** — `peaks standards init/update --dry-run`, must reference concrete project-scan findings (never emit generic templates);
-2. **Peaks-Cli PRD phase** — capture request as canonical artifact, extract scope and acceptance criteria:
+0. **Peaks-Loop Snapshot** — `peaks doctor` + `peaks project dashboard` to capture baseline state before anything else;
+0.5. **Peaks-Loop Workspace initialization** — `.peaks/_runtime/<session-id>/` created, directory structure verified;
+0.6. **Peaks-Loop Project scan** — archetype, component library, CSS framework, build tool, state management, routing, data fetching, legacy signals detected and recorded to `.peaks/_runtime/<session-id>/rd/project-scan.md`;
+0.7. **Peaks-Loop Existing-system extraction** (MANDATORY when archetype ∈ {legacy-frontend, legacy-fullstack, frontend-monorepo}; SKIP for greenfield) — extract visual tokens and code conventions from the live codebase to `.peaks/_runtime/<session-id>/system/existing-system.md`. The path lives under `system/` (not `ui/`) because the file also records non-UI conventions (service-layer signatures, hooks, naming) that backend-only or legacy-fullstack work consumes. See `references/existing-system-extraction.md`. UI design-draft and RD implementation MUST treat the extracted tokens and conventions as hard constraints;
+1. **Peaks-Loop Standards preflight** — `peaks standards init/update --dry-run`, must reference concrete project-scan findings (never emit generic templates);
+2. **Peaks-Loop PRD phase** — capture request as canonical artifact, extract scope and acceptance criteria:
    - Full-auto/Swarm: auto-transition to `confirmed-by-user` once the artifact is complete;
    - Assisted/Strict: pause with `AskUserQuestion` for explicit user confirmation before proceeding;
-3. **Peaks-Cli Swarm parallel phase** — after PRD confirmed, launch UI, RD(planning), QA(test-cases) simultaneously:
+3. **Peaks-Loop Swarm parallel phase** — after PRD confirmed, launch UI, RD(planning), QA(test-cases) simultaneously:
    3a. UI design draft and visual direction (MANDATORY when request is frontend/user-visible; skipped for `--type docs|chore|config` or pure-backend requests);
    3b. RD planning artifact — `rd/tech-doc.md` for feature/refactor, `rd/bug-analysis.md` for bugfix, skipped for docs/chore/config;
    3c. QA test-case generation (skipped for docs/chore — no acceptance surface to validate);
-4. **Peaks-Cli RD implementation** — consumes the type-appropriate inputs: project-scan + standards + (if UI involved) UI design-draft + RD planning artifact + QA test-cases. Includes unit tests for new/changed behavior (TDD) unless `--type` is docs/chore;
-5. **Peaks-Cli Code review + security review** — CRITICAL/HIGH issues fixed before progression; marked-blocked issues only allow a blocked handoff;
-6. **Peaks-Cli QA validation** (auto-proceed from RD in full-auto) — execute test cases + API checks + Playwright MCP headed browser E2E for frontend + security/perf checks + test report;
-7. **Peaks-Cli RD↔QA repair loop** — if QA verdict is `return-to-rd`, loop back to step 4 (RD implementation) and re-run through QA; max 3 repair cycles, then emit blocked TXT regardless;
-8. **Peaks-Cli SC phase** — change-control evidence: impact, retention, validate, boundary;
-9. **Peaks-Cli OpenSpec archive** — exit gate: validate → archive only after QA verdict=pass (when `openspec/` exists);
-10. **Peaks-Cli TXT handoff capsule** — mode, validated decisions, artifact paths, standards deltas, open questions, next action;
-11. **Peaks-Cli Final snapshot** — `peaks project dashboard` + `peaks skill doctor` to confirm the workflow closed cleanly.
+4. **Peaks-Loop RD implementation** — consumes the type-appropriate inputs: project-scan + standards + (if UI involved) UI design-draft + RD planning artifact + QA test-cases. Includes unit tests for new/changed behavior (TDD) unless `--type` is docs/chore;
+5. **Peaks-Loop Code review + security review** — CRITICAL/HIGH issues fixed before progression; marked-blocked issues only allow a blocked handoff;
+6. **Peaks-Loop QA validation** (auto-proceed from RD in full-auto) — execute test cases + API checks + Playwright MCP headed browser E2E for frontend + security/perf checks + test report;
+7. **Peaks-Loop RD↔QA repair loop** — if QA verdict is `return-to-rd`, loop back to step 4 (RD implementation) and re-run through QA; max 3 repair cycles, then emit blocked TXT regardless;
+8. **Peaks-Loop SC phase** — change-control evidence: impact, retention, validate, boundary;
+9. **Peaks-Loop OpenSpec archive** — exit gate: validate → archive only after QA verdict=pass (when `openspec/` exists);
+10. **Peaks-Loop TXT handoff capsule** — mode, validated decisions, artifact paths, standards deltas, open questions, next action;
+11. **Peaks-Loop Final snapshot** — `peaks project dashboard` + `peaks skill doctor` to confirm the workflow closed cleanly.
 
-### Peaks-Cli Transition verification gates (MANDATORY — run the command, see the output)
+### Peaks-Loop Transition verification gates (MANDATORY — run the command, see the output)
 
 You cannot declare a phase complete from memory. Each gate below is a `ls` command you **MUST run** and whose output you **MUST see** before proceeding. If any file shows "No such file", the phase is incomplete.
 
-**Peaks-Cli Gate A — After workspace init + project scan:**
+**Peaks-Loop Gate A — After workspace init + project scan:**
 ```bash
 ls .peaks/_runtime/<sessionId>/rd/project-scan.md
 # Expected output: .peaks/_runtime/<sessionId>/rd/project-scan.md
@@ -61,7 +61,7 @@ ls .peaks/_runtime/<sessionId>/rd/project-scan.md
 # File present and complete → reuse (project-scan is a session-scoped singleton)
 ```
 
-**Peaks-Cli Gate A.5 — Existing-system extraction (legacy projects only):**
+**Peaks-Loop Gate A.5 — Existing-system extraction (legacy projects only):**
 ```bash
 # If project-scan.md `## Archetype` is greenfield → skip this gate
 # Otherwise:
@@ -70,9 +70,9 @@ ls .peaks/_runtime/<sessionId>/system/existing-system.md
 # (see references/existing-system-extraction.md)
 ```
 
-**Peaks-Cli Gate B — After swarm convergence (UI + RD planning + QA test-cases):**
+**Peaks-Loop Gate B — After swarm convergence (UI + RD planning + QA test-cases):**
 
-Peaks-Cli Gate B has two sub-checks: a HARD gate (blocks progression) and an INFORMATIONAL check (records degradation but does not block).
+Peaks-Loop Gate B has two sub-checks: a HARD gate (blocks progression) and an INFORMATIONAL check (records degradation but does not block).
 
 ```bash
 # B.hard — REQUIRED before continuing to RD implementation.
@@ -98,7 +98,7 @@ ls .peaks/_runtime/<sessionId>/ui/design-draft.md 2>&1
 # "No such file" + pure backend / docs / chore / config → state skip reason in TXT, proceed.
 ```
 
-**Peaks-Cli Gate C — After RD implementation (before QA handoff):**
+**Peaks-Loop Gate C — After RD implementation (before QA handoff):**
 
 The CLI gate (`peaks request transition --state qa-handoff`) is the authoritative check; running this `ls` first lets you produce missing files before the CLI rejects the transition.
 
@@ -125,7 +125,7 @@ ls .peaks/_runtime/<sessionId>/rd/requests/<rid>.md
 # Missing any required file → DO NOT attempt the qa-handoff transition; CLI will reject with PREREQUISITES_MISSING.
 ```
 
-**Peaks-Cli Gate D — After QA validation:**
+**Peaks-Loop Gate D — After QA validation:**
 
 The CLI gate at `qa:verdict-issued` is the authoritative check; this `ls` lets you produce missing evidence before the CLI rejects the transition.
 
@@ -141,17 +141,17 @@ ls .peaks/_runtime/<sessionId>/qa/requests/<rid>.md
 # Missing required file → QA incomplete; do not transition to verdict-issued.
 ```
 
-**Peaks-Cli Gate E — Before declaring workflow complete:**
+**Peaks-Loop Gate E — Before declaring workflow complete:**
 ```bash
 find .peaks/_runtime/<sessionId>/ -type f | sort
 # Verify: files from gates A-D all appear in this list.
 # Any mandatory file missing → NOT complete. Do not emit TXT.
-# Peaks-Cli Gate G (CLAUDE.md + .claude/rules/**) must ALSO pass before TXT is emitted.
+# Peaks-Loop Gate G (CLAUDE.md + .claude/rules/**) must ALSO pass before TXT is emitted.
 ```
 
-**Peaks-Cli Gate F — Root pollution check (BLOCKING before completion):**
+**Peaks-Loop Gate F — Root pollution check (BLOCKING before completion):**
 ```bash
-# Verify no Peaks-Cli intermediate artifacts leaked to project root.
+# Verify no Peaks-Loop intermediate artifacts leaked to project root.
 ls feishu-doc-*.md *-snapshot.md qa-server.js 2>&1
 # Expected: "No such file or directory" for ALL patterns.
 # Any file found → ROOT POLLUTION. Move it to .peaks/_runtime/<sessionId>/prd/source/
@@ -162,11 +162,11 @@ ls feishu-doc-*.md *-snapshot.md qa-server.js 2>&1
 ```bash
 # Extended check for common leak patterns
 find . -maxdepth 1 -name "*.png" -o -name "*.jpg" -o -name "qa-*.js" -o -name "mock-server.*" 2>&1
-# Any Peaks-Cli QA/UI intermediate files here → ROOT POLLUTION. Move and note.
-# Legitimate project files (e.g. favicon.png) are fine — only move Peaks-Cli artifacts.
+# Any Peaks-Loop QA/UI intermediate files here → ROOT POLLUTION. Move and note.
+# Legitimate project files (e.g. favicon.png) are fine — only move Peaks-Loop artifacts.
 ```
 
-**Peaks-Cli Gate G — Project standards present (BLOCKING before workflow completion):**
+**Peaks-Loop Gate G — Project standards present (BLOCKING before workflow completion):**
 ```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
@@ -180,7 +180,7 @@ ls <repo>/.claude/rules/common/coding-style.md \
    <repo>/.claude/rules/common/security.md
 # Any "No such file" → BLOCKED. The standards apply step did not complete; re-run
 # standards init/update with --apply and re-verify.
-# Skipping Peaks-Cli Gate G (e.g. because the user did not explicitly authorize writes) is
+# Skipping Peaks-Loop Gate G (e.g. because the user did not explicitly authorize writes) is
 # only acceptable in `assisted`/`strict` modes where the user actively declined; in
 # `full-auto`/`swarm` the absence of these files is a workflow violation.
 ```

package/skills/peaks-solo-resume/SKILL.md

@@ -3,9 +3,9 @@ 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", "把刚才没做完的收尾".
 ---
 
-# Peaks-Cli Solo Resume (wrapper)
+# Peaks-Loop Solo Resume (wrapper)
 
-Peaks-Cli 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-solo` 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.
 

package/skills/peaks-solo-status/SKILL.md

@@ -3,9 +3,9 @@ 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".
 ---
 
-# Peaks-Cli Solo Status (wrapper)
+# Peaks-Loop Solo Status (wrapper)
 
-Peaks-Cli 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-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.
 
 **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).
 
@@ -54,7 +54,7 @@ Compact 1-screen format:
 === peaks-solo status ===
 Session:   2026-06-04-session-b60252
 Active:    peaks-solo (mode: full-auto, gate: qa-validation)
-Workspace: /Users/yuanyuan/.../peaks-cli/.peaks/2026-06-04-session-b60252
+Workspace: /Users/yuanyuan/.../peaks-loop/.peaks/2026-06-04-session-b60252
 
 | Role | State          | Artifact                |
 |------|----------------|-------------------------|
@@ -75,7 +75,7 @@ If the session is fresh (no in-flight slice), render a different layout:
 === peaks-solo status ===
 Session: 2026-06-04-session-b60252
 Active:  peaks-solo (mode: full-auto, gate: startup)
-Workspace: /Users/yuanyuan/.../peaks-cli/.peaks/2026-06-04-session-b60252
+Workspace: /Users/yuanyuan/.../peaks-loop/.peaks/2026-06-04-session-b60252
 
 No in-flight slice. Ready for a new request.
 Health: skill-doctor 35/35 pass

package/skills/peaks-solo-test/SKILL.md

@@ -3,9 +3,9 @@ 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".
 ---
 
-# Peaks-Cli Solo Test (wrapper)
+# Peaks-Loop Solo Test (wrapper)
 
-Peaks-Cli 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-solo 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).
 
@@ -18,10 +18,10 @@ peaks project memories --project <repo> --json  # load durable memory
 
 ## Step 1: Detect the project's test command
 
-The Peaks-Cli project standard is `pnpm vitest run` (per `vitest.config.ts` + `package.json` scripts). For other project types, check the package.json scripts first. If the user explicitly named a different command (e.g. "跑 `pnpm test` not vitest"), use that.
+The Peaks-Loop project standard is `pnpm vitest run` (per `vitest.config.ts` + `package.json` scripts). For other project types, check the package.json scripts first. If the user explicitly named a different command (e.g. "跑 `pnpm test` not vitest"), use that.
 
 ```bash
-# Default for peaks-cli itself + most TS projects with vitest
+# Default for peaks-loop itself + most TS projects with vitest
 pnpm vitest run
 ```