sillyspec 3.28.2 → 3.28.4

package/.claude/skills/sillyspec-auto/SKILL.md

@@ -20,7 +20,7 @@ $ARGUMENTS
 
 ## 执行流程
 
-你是全流程编排器，按 brainstorm → plan → execute → verify 顺序自动推进。
+按 brainstorm → plan → execute → verify 顺序自动推进；**编排由 CLI driver 承担，你只执行判断步**。
 
 ### 启动
 
@@ -28,66 +28,27 @@ $ARGUMENTS
 sillyspec run auto --input "<用户需求>" [--mode <模式>]
 ```
 
-2. 读取 CLI 输出的 step prompt（含角色描述）
-3. 执行 prompt 中的操作
-4. **记录 CLI 输出中显示的 Change 名称**（如 `Change: 2026-06-02-xxx`）
+零活跃变更时 CLI 自动创建（也可 `--change <名>` 指定）；多活跃变更 CLI 会列出候选要求显式指定。单活跃自动选中并回显，无需记忆/传递变更名。
 
-### 步骤循环
+### 每步循环（唯一纪律）
 
-重复以下循环直到 CLI 输出"全部流程已完成"：
+1. 跑 CLI 给出的命令（启动时是上面的 run auto；此后每步读上一步输出尾部的 **SS-META 块**）。
+2. 读 prompt 尾部机器可读元数据块：
 
-1. **读取 CLI 输出的 step prompt**
-2. **判断是否需要用户确认：**
-   - prompt 含"请用户选择 / 等待用户回答 / 展示给用户 / 用户确认" → **暂停，等用户回复**
-   - 纯内部操作 → **直接执行**
-3. **执行 prompt 要求的操作**
-4. **完成后运行：**
-   ```bash
-   sillyspec run auto --done --change <变更名> --output "<你的摘要>"
    ```
-   - ⚠️ **必须携带 `--change <变更名>`**，变更名来自启动时 CLI 输出的 `Change:` 字段
-   - **绝不使用 `--change default`**，除非 CLI 启动时明确显示的 Change 名称就是 `default`
-5. **读取 CLI 输出的下一步 prompt**，回到步骤 1
-
-### auto 参数
-
-| 参数 | 说明 |
-|---|---|
-| `--input "<需求>"` | 启动时传入用户需求 |
-| `--mode <模式>` | 显式指定流程模式（默认按复杂度自动分类） |
-| `--done --change <名> --output "..."` | 完成当前步骤（必带 --change） |
-| `--spec-dir <path>` | 指定规范目录 |
-| `--non-interactive` | CI/脚本下禁用交互 |
-
-## 阶段审核门控（Stage Review Gate）
-
-审核发生在 brainstorm / plan / execute 各阶段的 review 步骤，**分级由 CLI 按变更规模自动判定**（不是 agent 凭关键词或复杂度启发式判断）：
-
-- **tier=self**（变更 ≤3 文件）：当前 agent 自审，直接产 review.json。
-- **tier=independent**（变更 >3 文件）：必须派发**独立 QA 子代理**（独立上下文，不共享实现者分析）产 review.json。
-
-CLI 会在 review 步骤注入：完整 JSON schema 表 + 示例 + docHash 算法 + 自动决策 checklist（AC-001 起，逐条核验公共 API / schema / 鉴权 / 文件边界 / 依赖 / 核心模块 / 兼容性 / 业务等维度）。你按**实际注入的契约与 tier 指令**执行：
-
-- checklist 全 ✅ 且方案唯一合理 → AUTO_DECIDED，推进下一阶段
-- checklist 有 ❌（影响架构/数据/接口/权限/兼容性/业务）→ 暂停，用 AskUserQuestion 让用户选择
-
-**不要**自行编造"简单/中等/复杂 → N 个审核子代理"规则——审核子代理数量由 tier 决定（self=0 额外子代理，independent=1 个独立 QA），不是复杂度启发式；以 CLI 实际注入的 tier 与 checklist 为准。
-
-## 关键规则
+   <!--SS-META:{"stage":...,"requiresUser":true|false,"doneCommand":"...","waitHint":"..."}-->
+   ```
 
-- 不要跳过任何步骤
-- 不要手动修改进度数据（SQLite 数据库）
-- 不要自动 commit，只 `git add`
-- 不要使用 npx
-- 不要编造不存在的 CLI 子命令
-- 遇到命令报错 → 展示错误，暂停等用户介入
-- **每次 `sillyspec run auto --done` 都必须携带 `--change <变更名>`**（= CLI 首次输出的 Change 名）
+3. 按块驱动：
+   - `requiresUser=true` → 本步需要用户输入：按 prompt 的 wait 指令先展示选项，取得用户回答后走 `--continue --answer`，再 `--done`（用户在终端且带 `--wait-interactive` 时 CLI 会直接 readline 收，无需转抄）。
+   - `requiresUser=false` → 执行本步任务（设计/实现/审查等判断工作），完成后**逐字执行 `doneCommand`**（`--output "你的摘要"` 换成真实一句话摘要）。
+4. CLI 会在阶段边界自动流转（gate 不过会给出修复指引——修完重跑，进度不丢）。
 
-## 异常处理
+### 终止
 
-- 命令执行失败 → 展示错误信息，暂停等待用户指示
-- 用户说"停止"/"暂停" → 立即停止，报告当前进度
+**CLI 打印「流程收尾总结」分隔线块（变更/阶段/任务勾选/产物清单）即全流程完成**——不要自行判断完成、不要自撰总结。CLI 若提示「全部流程已完成」（All auto flow stages are complete）同义。
 
-## 完成条件
+### 边界
 
-CLI 输出"全部流程已完成"后，输出完整流程总结，提示用户提交改动（`/sillyspec:commit`）。
+- 中断恢复：直接重跑 `sillyspec run auto`（进度已落盘，从断点续）。
+- 分类为 quick 的小变更：CLI 会提示改跑 `sillyspec run quick`，照提示执行。

package/.claude/skills/sillyspec-brainstorm/SKILL.md

@@ -100,7 +100,7 @@ brainstorm 在 `tier=independent` 规模下除 design.md 等四件套外，还
   }
   ```
 
-- `docHash` = `sha256(主审查文档内容)`（hex）—— brainstorm 主文档是 `design.md`（即 `reviewedFiles[0]`）。CLI 重算 sha256 比对，不符判伪造（fail-closed）。docHash 可先占位（如 "TODO"）；改 design.md 后勿手算 sha256——跑 `sillyspec register-stage-review --change <变更名> --stage brainstorm --refresh-hash` 一键重算代填（verdict 保留；design 改版多阶段联动加 --all）。`tier=self`（≤3 文件）降级为当前 agent 自审，不强制独立子代理。
+- `docHash` = `sha256(主审查文档内容)`（hex）—— brainstorm 主文档是 `design.md`（即 `reviewedFiles[0]`）。CLI 重算 sha256 比对，不符判伪造（fail-closed）。docHash 可先占位（如 "TODO"）；改 design.md 后勿手算 sha256——跑 `sillyspec register-stage-review --change <变更名> --stage brainstorm --refresh-hash` 一键重算代填（verdict 保留；design 改版多阶段联动加 --all）。忘跑也不会被拦：gate 检测到「仅 docHash 失配」时自动机械重算放行（verdict 保留 + 审计行留痕）；schema/verdict 错误照常 fail-closed。`tier=self`（≤3 文件）降级为当前 agent 自审，不强制独立子代理。
 - 运行时 CLI 会把精确 schema 表 + 完整 JSON 示例 + docHash 算法注入到该步 prompt，以你实际收到的注入版契约为权威逐字模板。
 
 ## 铁律

package/.claude/skills/sillyspec-continue/SKILL.md

@@ -3,45 +3,15 @@ name: sillyspec:continue
 description: 自动判断并执行下一步
 ---
 
----
-
-你现在是 SillySpec 的自动推进器。
-
-## 判断逻辑
-
-> 🔧 **先跑 `sillyspec next`**——CLI 已内置下方探测表（含活跃变更逐个推断 + task 勾选进度），输出「状态 + 下一步命令 + 依据」。直接按输出的建议命令执行；CLI 异常/输出与实际不符时才按下方手工表兜底。
-
-按顺序检查，第一个未完成的就执行：
-
-```
-1. 有 HANDOFF.json？→ 执行 /sillyspec:resume
-
-2. .sillyspec/changes/ 有进行中的变更？
-   2a. 没有任何文件 → 提示检查 proposal 是否需要完善
-   2b. 没有 design.md → 提示补充 design（运行 /sillyspec:brainstorm 推进到设计产物步）
-   2c. 没有 tasks.md → 执行 /sillyspec:brainstorm（规范文件 proposal/requirements/tasks 由 brainstorm 末步生成）
-   2d. 有 tasks.md 但没有 plan.md → 执行 /sillyspec:plan
-   2e. tasks.md 有未完成项 + 有计划文件 → 执行 /sillyspec:execute
-   2f. tasks.md 全完成 + 没验证 → 执行 /sillyspec:verify
-   2g. 已验证通过 → 执行 /sillyspec:archive
-
-3. 有设计文档但没有对应变更？
-   → 提示运行 /sillyspec:brainstorm（基于设计文档建立变更并生成规范文件）
-
-4. 有 .sillyspec/docs/*/scan/ 但没有进行中的工作？
-   → 提示运行 /sillyspec:brainstorm "你的想法"
+## 流程
 
-5. 什么都没有？
-   → 提示运行 /sillyspec:init（新项目）或 /sillyspec:scan（棕地项目）
-```
+**先跑 `sillyspec next`**——CLI 已内置全套探测（HANDOFF / 活跃变更逐个产物推断 / task 勾选进度 / scan 文档 / 绿地棕地判定），直接输出「状态 + 下一步命令 + 依据」。
 
-## 输出
+1. 把探测结果转述给用户（状态 / 下一步 / 依据三行）。
+2. 按输出的建议命令直接执行对应 skill（如 `sillyspec run brainstorm` / `plan` / `execute` / `verify` / `archive`）。
+3. 仅当 CLI 异常或输出与实际明显不符时，才手工核对 `.sillyspec/` 下的产物文件后重新判断。
 
-先报告检测结果，再执行：
+勿自行 ls/cat 重算探测表——那就是 `next` 命令本体。
 
-> 🤖 SillySpec 自动检测
-> 
-> 当前状态：[描述]
-> 下一步：[执行的命令]
-> 
-> [开始执行...]
+## 用户指令
+$ARGUMENTS

package/.claude/skills/sillyspec-execute/SKILL.md

@@ -90,7 +90,15 @@ execute 完成时，每个 task 必须有 `review.json` 且 verdict 通过，否
 
 - `base` / `head` 必须是**真实 git commit**（`git rev-parse --verify`），否则判伪造并阻断。`changedFiles` 与实际 `git diff base..head` 完全不相交也判伪造。base..head 空 commit diff 但 working-tree 有未提交改动 → 视为有效改动（warning 不阻断）。
 
-> 🔧 **mechanics 字段不要手算**：`schemaVersion`/`task`/`base`/`head`/`changedFiles`(/跨仓 `repo`) 全部可由 CLI 从 git + task 卡推导。子代理/你只需写**语义字段**（`specVerdict`/`qualityVerdict`/`reviewerNotes`/`requiredEvidence`），mechanics 字段可以瞎填占位（如 `"base": "TODO"`），写完跑 `sillyspec backfill-reviews --change <变更名> --adopt` 一键重算代填（verdict 原样保留）。gate 拦下 mechanics 错误时也跑同一条命令修复。
+> 🔧 **首选命令式写入（2026-09-07 起）——不要手拼 JSON**：
+>
+> ```bash
+> sillyspec review write --change <变更名> --task task-NN --spec pass --quality pass --notes "评审备注"
+> ```
+>
+> verdict/notes/evidence 由你给；`schemaVersion`/路径目录/`execute-run-id`/`base`/`head`/`changedFiles`/`diffPaths` 全由 CLI 从 git + task 卡代算，写完即过 schema。`cannot_verify` 必须加 `--evidence "..."`；归属切片为空（改了声明外文件 / 纯验证任务）时 CLI 会报错列出 diff 候选——确认后用 `--changed-files <a,b>` 显式给出（纯验证任务 `--changed-files ""` 空覆盖 + evidence 披露）；已存在的 review 拒覆盖，`--force` 越过。
+>
+> 手写整文件仍是兼容路径：mechanics 字段勿手算——可瞎填占位（如 `"base": "TODO"`），写完跑 `sillyspec backfill-reviews --change <变更名> --adopt` 一键重算代填（verdict 原样保留）；gate 拦下 mechanics 错误时也跑同一条命令修复。
 
 - 后端 router task 另需产出 API 端点清单：`sillyspec endpoints extract --change <变更名> --task <task-NN>`（CLI 静态扫描 FastAPI/Express/Spring 路由装饰器生成 endpoints.json，verify 探针 5 消费；扫描面默认取 task 卡 allowed_paths ∪ design 清单，也可 `--dir`/`--files` 显式指定）。勿手扫装饰器手写——易漏 endpoint。
 
@@ -118,7 +126,7 @@ execute 还有**第二道**独立的 stage 级审查：除逐 task review.json
   }
   ```
 
-- `docHash` = `sha256(主审查文档内容)`（hex）—— execute 主审查文档是 `design.md`，即 `reviewedFiles[0]`。CLI 会重算 sha256 比对，不符判伪造（fail-closed）；找不到主文档也 fail。**docHash 可先占位（如 "TODO"）勿手算**——改 design.md 后跑 `sillyspec register-stage-review --change <变更名> --stage execute --refresh-hash` 一键重算代填（verdict 保留；design 改版多阶段联动加 --all）；gate 拦 docHash 失配时也用同一条命令修复。
+- `docHash` = `sha256(主审查文档内容)`（hex）—— execute 主审查文档是 `design.md`，即 `reviewedFiles[0]`。CLI 会重算 sha256 比对，不符判伪造（fail-closed）；找不到主文档也 fail。**docHash 可先占位（如 "TODO"）勿手算**——改 design.md 后跑 `sillyspec register-stage-review --change <变更名> --stage execute --refresh-hash` 一键重算代填（verdict 保留；design 改版多阶段联动加 --all）。忘跑也不会被拦：gate 检测到「仅 docHash 失配」时自动机械重算放行（verdict 保留 + 审计行留痕）；schema/verdict 错误照常 fail-closed。
 - `tier=independent` 时必须由独立 QA 子代理产出该 review.json（独立上下文，不共享实现者分析）；`tier=self`（变更 ≤3 文件）降级为当前 agent 自审。
 - **审查范围分级**（tier=independent 时省重复消耗）：Task Review Gate 已产出 review.json 且 specVerdict/qualityVerdict 双 pass 的 task，QA 子代理只抽查（读 1-2 个核心 diff 文件抽验 reviewerNotes 与实际改动相符）；fail/cannot_verify/缺失的 task 全量重审。三项始终必查：跨 task 交界、design.md 整体对照、组装行为（全量测试/构建/启动）——task review 只看单 task diff，覆盖不到这三项。
 - 该 acceptance review 同时覆盖"代码审查"视角，后续代码审查步骤仅需轻量复审。

package/.claude/skills/sillyspec-knowledge/SKILL.md

@@ -5,266 +5,36 @@ argument-hint: "search --query \"<text>\" --limit N | inspect --id \"<id>\" | va
 version: "3.19.2"
 ---
 
-## 交互规范
-当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项以参数传入。
-
 ## 何时使用此技能
-Use this skill when working on a SillySpec repository and the task may depend on prior project knowledge, known issues, implementation patterns, scan-derived learnings, execute-stage knowledge hits, or `.sillyspec/knowledge`.
-
-Before implementing changes, **first search the knowledge base** to avoid repeating known work or running into known issues.
-
-## 命令列表
-
-### 1. knowledge search — 搜索知识库
-在执行任务前搜索相关知识。
-
-```bash
-sillyspec knowledge search --query "<task summary>" --limit 5
-```
-
-**示例：**
-```bash
-sillyspec knowledge search --query "worktree baseline apply conflict" --limit 5
-sillyspec knowledge search --query "postcheck validation error"
-sillyspec knowledge search --query "GLM usage metadata"
-```
-
-**输出（JSON）：**
-```json
-{
-  "ok": true,
-  "query": "worktree baseline",
-  "matches": [
-    {
-      "id": "patterns",
-      "path": "knowledge/patterns.md",
-      "title": "Patterns",
-      "summary": "每个阶段一个独立模块定义（含步骤与提示词）...",
-      "score": 3,
-      "tags": ["worktree", "git-worktree", "WorktreeManager"],
-      "category": "Patterns"
-    }
-  ]
-}
-```
-
-**使用场景：**
-- 实现新功能前，检查是否有现有模式可复用
-- 遇到报错前，搜索是否是已知问题
-- 修改特定模块前，了解约定和坑点
-
----
-
-### 2. knowledge inspect — 读取知识条目详情
-搜索命中后，读取完整条目内容。
-
-```bash
-sillyspec knowledge inspect --id "<knowledge-id>"
-```
-
-**示例：**
-```bash
-sillyspec knowledge inspect --id "patterns"
-sillyspec knowledge inspect --id "known-issues/sqljs-wasm-only"
-sillyspec knowledge inspect --id "generated/worktree-baseline-conflict"
-```
-
-**输出（JSON）：**
-```json
-{
-  "ok": true,
-  "entry": {
-    "id": "patterns",
-    "title": "Patterns",
-    "summary": "每个阶段对应 `src/stages/` 下的独立模块...",
-    "zone": "manual",
-    "path": "knowledge/patterns.md",
-    "meta": {
-      "author": "<git-user>",
-      "created_at": "2026-06-19T12:40:00+08:00",
-      "updated_at": "2026-06-24T10:00:00+08:00"
-    },
-    "body": "完整 markdown 内容..."
-  }
-}
-```
-
-**zone 说明：**
-- `manual` — 人工维护的知识（可直接信任）
-- `generated` — 自动提取的知识（scan 生成，需人工审核）
-- `proposed` — 提议待审核的知识（未合并）
-
----
-
-### 3. knowledge validate — 校验知识库健康度
-在 commit/archive 前检查知识库是否可用。
-
-```bash
-sillyspec knowledge validate
-```
-
-**输出（JSON）：**
-```json
-{
-  "ok": false,
-  "errors": [
-    {
-      "code": "broken_reference",
-      "path": "knowledge/generated/foo.md",
-      "referenced_in": "INDEX.md",
-      "display": "Foo Pattern"
-    },
-    {
-      "code": "empty_file",
-      "path": "knowledge/bar.md"
-    }
-  ],
-  "warnings": [
-    {
-      "code": "too_many_uncategorized",
-      "count": 12,
-      "path": "knowledge/uncategorized.md"
-    },
-    {
-      "code": "unregistered_file",
-      "path": "knowledge/new-file.md"
-    }
-  ]
-}
-```
-
-**错误码说明：**
-| code | 说明 |
-|---|---|
-| `knowledge_dir_missing` | `.sillyspec/knowledge/` 目录不存在 |
-| `missing_index` | `INDEX.md` 不存在 |
-| `broken_reference` | INDEX.md 引用的文件不存在 |
-| `empty_file` | 知识文件为空 |
-| `too_many_uncategorized` | uncategorized.md 条目 ≥10，需清理 |
-| `unregistered_file` | 手动知识文件未在 INDEX.md 注册 |
-
----
-
-### 4. knowledge refresh — 从 scan 文档刷新自动知识
-**仅写 generated/ 区，不覆盖 manual/。**
-
-```bash
-sillyspec knowledge refresh
-```
 
-**使用场景：**
-- scan 阶段完成后，自动提取可复用知识
-- archive 阶段完成后，沉淀长期有效的模式
+任务可能依赖项目既有知识（known issues / patterns / scan 结论 / `.sillyspec/knowledge`）时。**实现前先 search，避免重复踩坑。**
 
-**行为：**
-1. 扫描 `.sillyspec/docs/<project>/scan/*.md`
-2. 提取每个 `## 章节`（至少 3 行）作为知识条目
-3. 写入 `.sillyspec/knowledge/generated/<slug>.md`
-4. 生成 `generated/INDEX.md`
+## 命令速查
 
-**输出（JSON）：**
-```json
-{
-  "ok": true,
-  "generated_count": 8,
-  "new_count": 5,
-  "overwritten_count": 3,
-  "files": [
-    { "file": "generated/worktree-isolation.md", "title": "...", "new": true },
-    { "file": "generated/progress-management.md", "title": "...", "new": false }
-  ]
-}
-```
-
-**注意事项：**
-- generated/ 区知识是自动生成，不保证准确，需人工审核后合并到 manual/
-- 已有文件会被覆盖（ overwrite_count）
-
----
+所有命令输出均为 stdout 纯 JSON（`ok` 顶层字段 + 失败 `code` 错误码），以实际输出为准——参数细节跑 `sillyspec knowledge <子命令>` 无参可见用法，勿背示例。
 
-### 5. knowledge propose — 提议新知识
-不直接编辑 manual/，而是写入 proposed/ 供审核。
-
-```bash
-sillyspec knowledge propose --title "<title>" --category <category> --body "<content>" --from "<source>"
-```
-
-**参数说明：**
-| 参数 | 必填 | 说明 |
+| 命令 | 用途 | 关键参数 |
 |---|---|---|
-| `--title` | ✅ | 知识标题 |
-| `--category` | ❌ | 分类（默认 uncategorized），如 known-issues, patterns, conventions |
-| `--body` | ❌ | 知识正文 |
-| `--from` | ❌ | 来源标注（如 execute/quick/scan） |
-
-**示例：**
-```bash
-sillyspec knowledge propose --title "GLM API 超时处理" --category known-issues --body "GLM 模型默认超时 30 秒..." --from "execute"
-```
-
-**输出（JSON）：**
-```json
-{
-  "ok": true,
-  "id": "proposed/glm-api-timeout",
-  "path": "knowledge/proposed/glm-api-timeout.md",
-  "title": "GLM API 超时处理",
-  "category": "known-issues",
-  "new": true,
-  "action": "created"
-}
-```
-
-**后续流程：**
-- archive/commit 阶段审核 proposed/ 条目
-- 合格的合并到 manual/，不合格的删除
+| `sillyspec knowledge search --query "<任务关键词>" --limit 5` | 任务前搜知识库（与 execute 阶段同款匹配引擎） | `--query` 必填 |
+| `sillyspec knowledge inspect --id "<id>"` | 读命中条目全文 | id 形如 `patterns` / `known-issues/xxx` / `generated/xxx` |
+| `sillyspec knowledge validate` | commit/archive 前校验健康度 | errors（broken_reference/empty_file 等）须先修复 |
+| `sillyspec knowledge refresh` | scan/archive 后从 scan 文档刷新自动知识 | 仅写 `generated/`，不碰 manual/ |
+| `sillyspec knowledge propose --title "..." --category <分类> --body "..."` | 提议新知识 | 仅写 `proposed/` 供人工审核；`--from` 标来源 |
 
----
+zone 语义：`manual`（人工维护，可直接信任）/ `generated`（自动提取，需人工审核）/ `proposed`（待审，未合并）。
 
 ## Agent 使用指南
 
-### 任务前必查
-在开始实现新功能、修改现有代码、或遇到报错前：
-1. `knowledge search --query "<任务关键词>"`
-2. 命中则 `knowledge inspect --id "<id>"`
-3. 遵循知识中的约定和避坑建议
-
-### 发现新知识
-执行任务中发现可复用模式或新坑：
-1. `knowledge propose --title "<标题>" --category <分类> --body "<内容>"`
-2. 不要直接编辑 `.sillyspec/knowledge/manual/*.md`
-
-### 提交前校验
-commit/archive 前检查知识库状态：
-1. `knowledge validate`
-2. 如有 errors，先修复再提交
-
-### 扫描后刷新
-scan 阶段完成后：
-1. `knowledge refresh`
-2. 审核生成的 `generated/*.md`，有用的合并到 manual/
-
----
+1. **任务前必查**：实现/改代码/排错前 `search` → 命中则 `inspect` → 遵循其中约定与避坑建议。
+2. **发现新知识**：可复用模式或新坑用 `propose` 提议，不直接编辑 manual/。
+3. **提交前校验**：commit/archive 前 `validate`，有 errors 先修复。
+4. **扫描后刷新**：scan 完成后 `refresh`，`generated/` 中有用的条目待人工合并。
 
 ## 禁止事项
 
-❌ **不要直接编辑** `manual/` 或 `generated/` 中的知识文件
-- 使用 `knowledge propose` 提议新知识
-- 使用 `knowledge refresh` 刷新自动知识
-
-❌ **不要使用 `grep` 或 `cat` 直接读取知识文件**
-- 使用 `knowledge search` 和 `knowledge inspect`
-- 它们使用与 execute 阶段相同的匹配引擎
-
-❌ **不要让 agent 去审核 proposed/ 条目**
-- 提议供人工审核，不要自动合并
-- 只有用户明确要求才合并
-
----
-
-## 设计原则
+- ❌ 不要直接编辑 `manual/` 或 `generated/`——新知识走 `propose`，自动知识走 `refresh`
+- ❌ 不要用 `grep`/`cat` 直接读知识文件——用 `search`/`inspect`（同款匹配引擎，索引语义一致）
+- ❌ 不要自动审核合并 `proposed/` 条目——提议供人工审核，仅用户明确要求才合并
 
-- **Agent-safe：** 所有输出为 JSON，失败有明确错误码
-- **写保护：** refresh 仅写 generated/，propose 仅写 proposed/，不碰 manual/
-- **匹配引擎：** 使用 `knowledge-match.js`（与 execute 阶段一致）
-- **审计友好：** 每个条目记录来源、创建/更新时间
+## 用户指令
+$ARGUMENTS

package/.claude/skills/sillyspec-plan/SKILL.md

@@ -69,7 +69,7 @@ plan 的步骤是动态的：`generate_plan`（生成分级计划）→ `review_
   }
   ```
 
-- `docHash` = `sha256(主审查文档内容)`（hex）—— plan 主文档是 `plan.md`（`reviewedFiles[0]`）。CLI 重算 sha256 比对，不符判伪造（fail-closed）。docHash 可先占位（如 "TODO"）；改 plan.md 后勿手算 sha256——跑 `sillyspec register-stage-review --change <变更名> --stage plan --refresh-hash` 一键重算代填（verdict 保留；多阶段联动加 --all）。`tier=self`（≤3 文件）降级为当前 agent 自审。
+- `docHash` = `sha256(主审查文档内容)`（hex）—— plan 主文档是 `plan.md`（`reviewedFiles[0]`）。CLI 重算 sha256 比对，不符判伪造（fail-closed）。docHash 可先占位（如 "TODO"）；改 plan.md 后勿手算 sha256——跑 `sillyspec register-stage-review --change <变更名> --stage plan --refresh-hash` 一键重算代填（verdict 保留；多阶段联动加 --all）。忘跑也不会被拦：gate 检测到「仅 docHash 失配」时自动机械重算放行（verdict 保留 + 审计行留痕）；schema/verdict 错误照常 fail-closed。`tier=self`（≤3 文件）降级为当前 agent 自审。
 - 运行时 CLI 会把精确 schema 表 + 完整 JSON 示例 + docHash 算法注入到该步 prompt，以你实际收到的注入版契约为权威逐字模板。
 
 ### 契约门控（阻断完成）

package/.claude/skills/sillyspec-propose/SKILL.md

@@ -1,87 +1,16 @@
 ---
 name: sillyspec:propose
-description: 生成结构化规范 — proposal + design + tasks。适合用户说"生成规范、补全四件套、propose"。产出 proposal.md + design.md + tasks.md（+ 可能的 requirements.md）。
+description: 已废弃重定向 — 生成结构化规范四件套请直接走 brainstorm。适合用户说"生成规范、补全四件套、propose"——一律转用 /sillyspec:brainstorm。
 ---
 
-## 何时使用
+## propose 阶段已废弃（重定向到 brainstorm）
 
-- 用户说"生成规范、补全四件套、propose"
-- 已有零散设计/需求，需补全结构化规范四件套
-- 产出：`proposal.md` + `design.md` + `tasks.md`（+ 可选 `requirements.md`）
+`propose` 阶段已从 CLI 移除（`src/stages/propose.js` 标注 @deprecated 且未注册进 stageRegistry）——**`sillyspec run propose` 不存在**（报「未知阶段: propose」）。本 skill 只保留触发词重定向，没有任何 propose 专属流程，勿尝试执行任何 `run propose` 命令。
 
-> 注：propose 与 brainstorm 都产出四件套。brainstorm 是从需求开始的完整设计流程；propose 更偏"补全/生成规范"。新需求一般走 brainstorm。
+用户说"生成规范 / 补全四件套 / propose"时，**直接执行 `/sillyspec:brainstorm`**：
 
-## 多变更说明
-
-项目有多个活跃变更（`.sillyspec/changes/` 下有多个目录）时，所有 `sillyspec run` 命令需加 `--change <变更名>` 指定操作目标；只有一个变更时可省略（CLI 自动检测）。
-
-## 步骤生命周期（所有阶段通用）
-
-> `sillyspec run propose` 需用 `run` 形式（propose 无顶层别名，与 brainstorm/plan 等不同）。
-
-```bash
-sillyspec run propose                          # 输出当前步骤 prompt
-sillyspec run propose --done --output "摘要"   # 完成当前步骤
-sillyspec run propose --status                 # 查看阶段进度
-sillyspec run propose --skip                   # 跳过可选步骤
-sillyspec run propose --reset                  # 重置阶段（从头开始）
-sillyspec run propose --reopen --from-step N   # 重新打开已完成阶段修订
-```
-
-## 通用参数（所有阶段适用）
-
-| 参数 | 说明 |
-|---|---|
-| `--change <名>` | 指定变更名（多活跃变更必填，单变更可省略自动检测） |
-| `--spec-dir <path>` | 指定规范目录（默认 `<项目>/.sillyspec`） |
-| `--non-interactive` | CI/脚本下禁用交互式 prompt |
-| `--skip-approval` | 跳过审批/校验门控 |
-| `--json` | 输出 JSON（程序化读取） |
-
-## propose 特有：自检门控
-
-propose 含自检步骤（按规模分级：tier=self 当前 agent 自审 / tier=independent 启动独立审查子代理产出 stage review.json），完成时校验四件套文档齐全 + 内容章节（如 proposal 的 Non-Goals、design 的文件变更清单/风险登记/自审）。缺失会阻断完成。
-
-### Stage Review Gate（propose 的 proposal review.json）
-
-propose 在 `tier=independent` 时产出一个 stage 级 `review.json`，CLI `Stage Review Gate` 硬校验其 schema 与 `docHash` 真实性。
-
-- 路径：`.sillyspec/.runtime/stage-reviews/propose-review-<stage-review-run-id>/review.json`（目录可能不存在需手建；run-id 由该步 `--done` prompt 输出指定）。marker 文件 `.runtime/current-stage-review-run-id-propose-<变更名>`。
-- 字段（`schemaVersion:1`，`reviewType=proposal` —— propose 阶段主审查文档是 `proposal.md`）：
-
-  ```json
-  {
-    "schemaVersion": 1,
-    "reviewType": "proposal",
-    "reviewedFiles": ["changes/<变更名>/proposal.md"],   // [0] 为主文档
-    "docHash": "<sha256(reviewedFiles[0] 文件内容，hex)>",
-    "specVerdict": "pass",       // pass | fail | cannot_verify
-    "qualityVerdict": "pass",    // pass | fail | cannot_verify
-    "checklist": [               // 扁平数组，逐条对照 proposal 章节/Non-Goals 核验
-      { "item": "Non-Goals 明确", "result": "pass", "note": "..." }   // result: pass | gap | fail
-    ],
-    "requiredEvidence": [],      // cannot_verify 时必填非空
-    "reviewerNotes": "..."
-  }
-  ```
-
-- `docHash` = `sha256(主审查文档内容)`（hex）—— propose 主文档是 `proposal.md`（`reviewedFiles[0]`）。CLI 重算 sha256 比对，不符判伪造（fail-closed）。改 proposal.md 后须重算 docHash。`tier=self`（≤3 文件）降级为当前 agent 自审。
-- 运行时 CLI 通过 `{REVIEW_JSON_CONTRACT}` 注入精确 schema+示例，以注入版为权威逐字模板。
-
-## 阶段流转
-
-```
-(零散设计/需求) → propose → plan
-```
-
-propose 完成后（四件套齐 + 自检通过），运行 `sillyspec run plan --change <变更名>` 进入实现计划。
-
-## 铁律
-
-- **必须用 exec 工具（shell）执行 CLI，不要自己编造流程**
-- 只做当前步骤 prompt 描述的操作，不跳过
-- 产物写入 CLI 输出的 `changeDir` 目录
-- 完成后立即 `--done`，不跳过
+- brainstorm 产出同一套四件套（`proposal.md` + `design.md` + `requirements.md` + `tasks.md`），且含需求澄清与 Design Grill 审查
+- 「已有零散设计只需补全」与「新需求从零设计」在 brainstorm 内同流程处理——若用户明确要求跳过澄清，在对话探索步骤直接说明「需求已明确」尽早推进即可
 
 ## 用户指令
 $ARGUMENTS

package/.claude/skills/sillyspec-resume/SKILL.md

@@ -5,66 +5,17 @@ description: 恢复工作 — 从中断处继续
 
 ## 交互规范
 
-**当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项传入。**
-
-不要用编号列表让用户手动输入数字。
-如果需要自由输入，在 AskUserQuestion 的选项中加入"Other（自定义输入）"。
-
----
-
-你现在是 SillySpec 的恢复管理器。
+**当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项传入。** 不要用编号列表让用户手动输入数字。需要自由输入时在选项中加入"Other（自定义输入）"。
 
 ## 流程
 
-### 1. 读取进度
-
-```bash
-sillyspec progress show
-```
-
-### 2. 如果有活跃变更
-
-从 `sillyspec progress show` 输出中提取并展示当前状态。
-
-然后问用户：
-   1. 直接继续执行下一步
-   2. 查看更多细节
-
-### 3. 如果没有活跃变更
-
-> 🔧 优先跑 `sillyspec next`——CLI 已内置下方探测表，直接输出「状态 + 下一步命令 + 依据」，按输出执行；异常时才按下方手工探测兜底。
-
-自动探测项目状态：
-
-```bash
-# 检查活跃变更
-ls -d .sillyspec/changes/*/ | grep -v archive 2>/dev/null
-
-# 检查大需求拆分
-ls .sillyspec/changes/*/MASTER.md 2>/dev/null
-
-# 检查扫描文档
-ls .sillyspec/docs/*/scan/ 2>/dev/null | wc -l
-
-# 检查需求/路线图
-cat .sillyspec/REQUIREMENTS.md 2>/dev/null
-cat .sillyspec/ROADMAP.md 2>/dev/null
-```
-
-根据探测结果推断：
+1. **读进度**：跑 `sillyspec progress show`。
+2. **有活跃变更**：把当前状态（变更/阶段/步骤）转述给用户，用 AskUserQuestion 问「直接继续执行下一步 / 查看更多细节」。
+3. **无活跃变更**：跑 `sillyspec next`——CLI 已内置全套探测（文件存在性 → 推断阶段 → 建议命令 + 依据），按输出转述并执行建议命令。勿自行 ls/cat 重算（输出与实际不符时才手工核对）。
 
-| 探测到的文件 | 推断阶段 | 建议操作 |
-|---|---|---|
-| 无任何 .sillyspec/ 内容 | 未开始 | `/sillyspec:init` 或 `/sillyspec:scan` |
-| 有 docs/ 但缺失文档 | 扫描中断 | `/sillyspec:scan`（断点续扫） |
-| 有 docs/ 7 份齐全但无 changes/ | 已扫描，未开始需求 | `/sillyspec:brainstorm "想法"` |
-| 有 REQUIREMENTS.md 但无 changes/ | 绿地项目，已有需求 | `/sillyspec:brainstorm "想法"` |
-| changes/ 下有 proposal + design，无 plan.md | 已有规范，待计划 | `/sillyspec:plan` |
-| changes/ 下有 plan.md，tasks 有未完成项 | 执行中 | `/sillyspec:execute` |
-| tasks.md / plan.md 全部 checkbox 已勾选 | 待验证 | `/sillyspec:verify` |
-| 已验证通过 | 待归档 | `/sillyspec:archive` |
+## 关键原则
 
-### 4. 关键原则
+- 进度存 SQLite（`.sillyspec/.runtime/sillyspec.db`），随 `sillyspec run <stage> --done` 自动更新，不需要手动保存、不需要从中途状态"恢复文件"——直接续跑即可。
 
-- 进度数据存储在 SQLite 数据库中（`.sillyspec/.runtime/sillyspec.db`），通过 `sillyspec progress show` 命令查看
-- 进度随 `sillyspec run <stage> --done` 自动更新，不需要手动保存
+## 用户指令
+$ARGUMENTS