peaks-loop 4.0.0-beta.4 → 4.0.0-beta.6

package/skills/peaks-solo/references/triage-decision-table.md

@@ -0,0 +1,31 @@
+# peaks-solo — Triage Decision Table
+
+> 关键词 → leaf skill 快速映射。peaks-solo 在 §3 triage 决策流里先扫本表做"启发式预判",再用 `peaks skill search --query "<NL>"` 做精确匹配。
+> 匹配规则:case-insensitive substring(命中即行;同 NL 多行命中 → AskUserQuestion 多选)。
+
+| keyword | → | leaf skill |
+|---|---|---|
+| code / 代码 / 改 bug / 写功能 / 全流程 / 端到端 / PR / 测试覆盖 / 改 src | → | /peaks-code |
+| 文档 / article / blog / 内容 / 写稿 / 内容工作流 / 公众号 / 长文 | → | /peaks-content |
+| 健康 / health / 体检 / audit / 报告 / doctor report / 项目诊断 | → | /peaks-doctor |
+| issue / 修 issue / sweep / 批量修 / open issue 处理 | → | /peaks-issue-fix-orchestrator |
+| SOP / 流程 / 工作流 / 审批 / 门禁 / 标准操作 | → | /peaks-sop |
+| 性能 / perf / 慢 / 优化 / latency / 响应时间 | → | /peaks-perf-audit (or 自规划) |
+| 安全 / security / 漏洞 / vulnerability / OWASP | → | /peaks-security-audit (or 自规划) |
+| 状态 / status / 进度 / 现在到哪 / 当前在哪一步 | → | /peaks-status |
+| 跑测试 / test / vitest / unit test | → | /peaks-test |
+| 恢复 / resume / 继续 / 接上次 | → | /peaks-resume |
+| 不知道 / 随便 / 帮我 / 你帮我决定 / 我想做点东西 | → | peaks-solo triage (this skill) |
+| 切片 / slice / 拆解任务 / 大任务拆小 | → | /peaks-slice-decompose |
+| 想法 / brain-storm / 创意 / 探索思路 | → | /peaks-ide |
+| 最终审查 / final review / 验收 / 4-dim evidence | → | /peaks-final-review |
+| 研究 / research / 信息查询 / GitHub trending / top 10 / 调查 | → | (no leaf) → 自规划(deep-search / WebSearch) |
+| 一句话需求 / 一次性 / 单次性 | → | peaks-solo 自规划兜底 |
+
+## 使用说明
+
+1. **先扫表,再跑 search。** 表是 O(N) 的 substring 命中;跑 `peaks skill search` 是兜底。两者结果不一致时,以 search 为准(search 读的是 live frontmatter)。
+2. **多行命中 → AskUserQuestion 多选,**模板见 SKILL.md §3.1。
+3. **(e) "都不对" → 自规划兜底。** 走 SKILL.md §4。
+4. **空表条目:** "研究 / 信息查询 / GitHub trending / top 10" 等一次性信息查询,**当前 skill 池没有专属 leaf**,peaks-solo 直接走自规划(deep-search / WebSearch)。
+5. **本表是 opportunistic 表,**不是 exhaustive 表。S2/S3 后续可在 dogfood 中发现新关键词补行。

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

@@ -1,81 +0,0 @@
-# OpenSpec Lifecycle for Peaks Code
-
-Peaks Code orchestrates RD, QA, and SC. When the target repository uses OpenSpec, Code must drive the full lifecycle through the Peaks CLI so each role works against the same stable surface.
-
-> **Slice #016 (2026-06-09)**: this document used to live at `openspec-mcp-workflow.md` and contained a section on the `peaks mcp *` lifecycle. The MCP subsystem was retired in slice #016; that section is gone. The OpenSpec lifecycle described below is unchanged.
-
-## OpenSpec change lifecycle
-
-```text
-peaks openspec render   →  RD authors a change pack (dry-run, then --apply)
-peaks openspec validate →  Code gates RD output before slicing starts
-peaks openspec show     →  any role reads parsed proposal/tasks state
-peaks openspec to-rd    →  RD projects the pack into refactor slice input
-                          SC projects it into commit boundary candidates
-peaks openspec validate →  QA gates the final state before sign-off
-peaks openspec archive  →  Code moves the change under changes/archive/<id>/
-```
-
-Rules Code applies:
-
-- `render --apply` is the only Peaks-managed way to write a change pack. Other roles must not hand-edit `openspec/changes/**`.
-- `validate` is run twice per change in a refactor flow: once before slicing (RD entry gate) and once before archive (QA exit gate). Both must end with `data.valid === true`.
-- `archive --apply` is the lifecycle terminator; Code only invokes it after QA acceptance and SC commit.
-
-## Refactor workflow wiring
-
-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).
-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-loop is no longer in the install path; the LLM is the executor, the IDE is the dispatcher.
-
-## Boundary
-
-Code must not write `openspec/changes/**` or `~/.claude/settings.json` directly. Every mutation goes through the CLI commands above. The CLI returns stable envelopes; Code captures them as artifact links rather than re-explaining their content in the handoff.
-
----
-
-# Step 0.5 — OpenSpec first-run opt-in (conditional)
-
-> Body of `### Peaks-Loop Step 0.5`. After the workspace is anchored, before project scan, Code 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
-openspec-aware paths and you lose change-proposal tracking, commit
-boundaries from `tasks.md`, and the historical archive.
-
-To make that opt-in visible instead of silent, Code runs:
-
-```bash
-# 1. Detect whether the project already has openspec/.
-ls <repo>/openspec/changes 2>&1
-# 2. If absent, ask the user once — only on the first Code run in this
-#    project. The decision is sticky: write it to .peaks/.peaks-openspec-opt-in.json
-#    so subsequent Code invocations do not re-ask.
-test -f <repo>/.peaks/.peaks-openspec-opt-in.json || \
-  echo "{\"enabled\": <bool>}" > <repo>/.peaks/.peaks-openspec-opt-in.json
-```
-
-**AskUserQuestion** (only when `openspec/` is absent and the opt-in
-file is missing):
-
-| Option | What it does |
-|---|---|
-| Enable OpenSpec for this project (Recommended) | Run `peaks openspec init --project <repo> --apply`. After that, every Code run uses the change-proposal lifecycle for the same project. |
-| Skip for now | Do nothing. Code proceeds without openspec; the question is re-asked on the next first-run detection. |
-| Never ask again for this project | Write `{enabled: false, sticky: true}`. Code stops asking. The user can re-enable later by removing `.peaks/.peaks-openspec-opt-in.json` and re-running. |
-
-The first option is the recommended default because it gives Code the
-full change-proposal lifecycle (proposal / tasks / design / specs
-deltas, archive on ship, commit boundaries from `tasks.md`). It costs
-only a single scaffolded directory and pays back the first time the
-project needs a real review trail.
-
-If the user picks "Enable", the only required follow-up is to make
-sure `openspec/changes/` is added to git (it is part of the project
-repo, not a tool-managed artefact). Code does not run `git add` for
-the user; that is the user's commit boundary.