sillyspec 3.28.12 → 3.29.0

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

@@ -1,156 +1,156 @@
----
-name: sillyspec:plan
-description: 用于把 design 拆解为可执行的实现计划。适合用户说"拆任务、做计划、排 wave、规划实现步骤"。产出 plan.md（Wave 分组 + 任务 ID 引用 + 依赖关系）+ tasks.md 任务清单（唯一真相，plan 阶段展开写回）。
----
-
-## 何时使用
-
-- 用户说"拆任务、做计划、排 wave、规划实现步骤"
-- 把 brainstorm 的 design.md 拆成可执行的 Wave + Task
-- 产出：`plan.md`（Wave 分组 + 任务 ID 引用行 + 依赖关系）+ `tasks.md` 任务清单展开写回（唯一真相）+ `tasks/task-NN.md` 任务蓝图
-
-## 多变更说明
-
-项目有多个活跃变更（`.sillyspec/changes/` 下有多个目录）时，所有 `sillyspec run` 命令需加 `--change <变更名>` 指定操作目标；只有一个变更时可省略（CLI 自动检测）。
-
-## 步骤生命周期（所有阶段通用）
-
-> `sillyspec plan` 是 `sillyspec run plan` 的顶层别名，两者等价。
-
-```bash
-sillyspec run plan                             # 输出当前步骤 prompt
-sillyspec run plan --done --output "摘要"      # 完成当前步骤（--input "用户原话" 记录输入）
-sillyspec run plan --status                    # 查看阶段进度
-sillyspec run plan --skip                      # 跳过可选步骤
-sillyspec run plan --reset                     # 重置阶段（从头开始）
-sillyspec run plan --reopen --from-step N      # 重新打开已完成阶段修订（N=序号或名称）
-sillyspec run plan --wait --reason "..." --options "A,B"   # 暂停等用户决策
-sillyspec run plan --continue --answer "..."               # 恢复等待中的步骤
-sillyspec run plan --done --answer "..." --output "..."    # 一步完成 wait+done
-```
-
-## 通用参数（所有阶段适用）
-
-| 参数 | 说明 |
-|---|---|
-| `--change <名>` | 指定变更名（多活跃变更必填，单变更可省略自动检测） |
-| `--spec-dir <path>` | 指定规范目录（默认 `<项目>/.sillyspec`） |
-| `--non-interactive` | CI/脚本下禁用交互式 prompt |
-| `--interactive` | 强制交互（即便 stdin 非 TTY） |
-| `--skip-approval` | 跳过阶段转换/审批检查（不能跳产物校验 gate——review.json/文档产物硬校验仍在） |
-
-## plan 特有
-
-### 动态步骤
-
-plan 的步骤是动态的：`generate_plan`（生成分级计划）→ `review_plan`（审查计划，按规模分级：tier=self 当前 agent 自审 / tier=independent 启动独立审查子代理产出 stage review.json，避免生成+自审同一次输出的偏差）→ CLI 从 `tasks.md` 注册表解析出 task 自动插入"任务蓝图协调器"步骤（per-task；plan.md 只提供 Wave 引用分组）。这是正常行为，不要手动添加。
-
-### Stage Review Gate（plan 的 design review.json）
-
-`review_plan` 步骤在 `tier=independent` 时产出一个 stage 级 `review.json`，CLI `Stage Review Gate` 硬校验其 schema 与 `docHash` 真实性。
-
-- 路径：`.sillyspec/.runtime/stage-reviews/plan-review-<stage-review-run-id>/review.json`（目录可能不存在需手建；run-id 由该步 `--done` prompt 输出指定）。marker 文件 `.runtime/current-stage-review-run-id-plan-<变更名>`。
-- **run-id / marker 由 CLI 自动生成注入**（review step prompt 渲染时 echo 完整目录路径 + 写 marker；撞 gate 报缺 review.json 时 gate 也 echo 完整路径 + 写 marker）。直接用 CLI 给的路径写 review.json，**勿手算 run-id（必须 `review-` 前缀）、勿手写 marker**。卡住时用 `sillyspec register-stage-review --change <名> --stage plan` 一步生成。
-- 字段（`schemaVersion:1`，`reviewType=plan` —— plan 阶段主审查文档是 `plan.md`；execute 阶段才是 `acceptance`）：
-
-  ```json
-  {
-    "schemaVersion": 1,
-    "reviewType": "plan",
-    "reviewedFiles": ["changes/<变更名>/plan.md"],   // [0] 为主文档
-    "docHash": "<sha256(reviewedFiles[0] 文件内容，hex)>",
-    "specVerdict": "pass",       // pass | fail | cannot_verify
-    "qualityVerdict": "pass",    // pass | fail | cannot_verify
-    "checklist": [               // 扁平数组，逐条对照 plan 章节/Wave 结构/task 完整性核验
-      { "item": "Wave 分级合理", "result": "pass", "note": "..." }   // result: pass | gap | fail
-    ],
-    "requiredEvidence": [],      // cannot_verify 时必填非空
-    "reviewerNotes": "..."
-  }
-  ```
-
-- `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，以你实际收到的注入版契约为权威逐字模板。
-
-### 契约门控（阻断完成）
-
-- **plan 启动前**：CLI 校验 `design.md` 是否满足 plan 契约（缺文件变更清单/风险登记/自审章节会阻断）。若失败需先 `sillyspec run brainstorm --reopen --from-step N` 修订设计。
-- **plan 完成时**：CLI 校验 `tasks.md`（任务注册表）× `plan.md`（Wave ID 引用）是否满足 execute 契约（引用存在性/覆盖恰一次/编号连续/旧格式拦）。失败会阻断完成，提示修复后重新 `--done`。
-
-### 生产接线路径检查
-
-plan 完成校验会检查：design 提到入口文件（cli.ts/main.ts/server.ts 等）但 task 的 allowed_paths 不含该文件 → 报 error。若确实不需要改入口，在 design.md 明示理由。
-
-## 跨仓 task 卡片协议（一个 change 改多个仓库）
-
-单个 change 的 task 可以分散到主仓 + 多个跨仓仓实现（典型场景：dogfood 自指、monorepo 多包仓、共享库 + 调用方联合改造）。**单仓 change 不需要任何跨仓配置**（所有 task 不写 `repo:` 即走原流程，零回归）。
-
-### 跨仓 task 卡片字段
-
-在 `tasks/task-NN.md` frontmatter 加：
-
-- `repo: <key>`（可选，缺省='main'=主仓 task）：task 所属仓的 key。key 必须在 `.sillyspec/local.yaml` `repos:` 段注册（`main` 隐式=主仓不用注册）。跨仓 change 缺注册 → execute 启动 fail-closed 阻断。
-- `allowed_paths`：跨仓 task 时指**相对跨仓仓根**的路径（非主仓根）。例如跨仓 task 改 `sillyspec` 仓的 `src/foo.js`，allowed_paths 写 `src/foo.js`（相对 sillyspec 仓根），不是 `../sillyspec/src/foo.js`。
-- `base_commit` / `head_commit`：**不要手写**——CLI 在 execute 派发/回收时自动落盘双锡点（锁 base/head 防 diff 漂移），plan 阶段不写。
-
-### local.yaml `repos:` 段（跨仓注册表）
-
-> 📍 `local.yaml` 恒在 `.sillyspec/local.yaml`——项目根目录**没有**这个文件，别去那里找或新建（hook 会拦）。worktree 内该文件不随 checkout 出现，读配置直接跑 `sillyspec config cat`（自动定位到主仓真实配置）；可用键清单见 `sillyspec config schema`。
-
-跨仓 change 的每个 repo key 都要注册（execute 启动 fail-closed 校验）。**用命令注册，勿手编 YAML**：
-
-```
-sillyspec local register-repo <key> <跨仓仓根路径>
-```
-
-（外科手术式写入，只动 `repos:` 段，其余内容保留；execute 启动报缺注册时，报错文案里就带这条命令。）手写格式参考：
-
-```yaml
-repos:
-  shared-lib: ../shared-lib
-  tool-repo: C:/path/to/your/tool-repo
-```
-
-key = task 卡 `repo:` 引用名，value = 跨仓仓绝对路径（或相对主仓根的路径）。`main` 不用注册。
-
-### design.md 文件变更清单按仓分段
-
-跨仓 change 的 `## 文件变更清单` 段须按仓分段，段头格式 `## <repo> 仓变更`（主仓段头可省略或写 `## main 仓变更`）：
-
-```markdown
-## 文件变更清单
-
-### sillyspec 仓变更
-| 操作 | 文件路径 | 说明 |
-|---|---|---|
-| 修改 | src/task-review.js | 跨仓 task 改的文件 |
-
-### main 仓变更
-| 操作 | 文件路径 | 说明 |
-|---|---|---|
-| 修改 | src/index.js | 主仓 task 改的文件 |
-```
-
-plan 完成校验会按仓分段对账：跨仓仓路径相对跨仓仓根校验 task allowed_paths 覆盖，主仓路径相对主仓根校验。跨仓 task 与主仓 task 同名物理路径分属不同 repo 不判冲突。
-
-### Wave 划分
-
-同 Wave 内允许混合主仓 + 跨仓 task（execute 按 per-task workdir 派发，不强制同 Wave 同 repo）。共享文件的 task 仍须分到不同 Wave（同 Wave 共享文件会被强制并行，子代理互相覆盖）。plan.md 无显式 Wave 划分（light 级无任务区）不再被 postcheck 硬拦——execute 按单隐式 Wave 串行执行（共享文件安全，仅 warning 提示）；显式 Wave 的同 Wave 共享文件硬拦维持。
-
-## 阶段流转
-
-```
-brainstorm → plan → execute
-```
-
-plan 完成后（plan.md 通过 execute 契约校验），运行 `sillyspec run execute --change <变更名>` 开始实现。
-
-## 铁律
-
-- **必须用 exec 工具（shell）执行 CLI，不要自己编造流程**
-- 只做当前步骤 prompt 描述的操作，不跳过、不自行扩展
-- tasks.md 是任务清单唯一真相（checkbox 注册表，plan 阶段展开写回——保留 ql-xxx 等非 task-XX 行）；plan.md Wave 段只写纯 ID 引用行（`- task-XX`），不重抄任务名
-- 完成后立即 `--done`，不跳过
-
-## 用户指令
-$ARGUMENTS
+---
+name: sillyspec:plan
+description: 用于把 design 拆解为可执行的实现计划。适合用户说"拆任务、做计划、排 wave、规划实现步骤"。产出 plan.md（Wave 分组 + 任务 ID 引用 + 依赖关系）+ tasks.md 任务清单（唯一真相，plan 阶段展开写回）。
+---
+
+## 何时使用
+
+- 用户说"拆任务、做计划、排 wave、规划实现步骤"
+- 把 brainstorm 的 design.md 拆成可执行的 Wave + Task
+- 产出：`plan.md`（Wave 分组 + 任务 ID 引用行 + 依赖关系）+ `tasks.md` 任务清单展开写回（唯一真相）+ `tasks/task-NN.md` 任务蓝图
+
+## 多变更说明
+
+项目有多个活跃变更（`.sillyspec/changes/` 下有多个目录）时，所有 `sillyspec run` 命令需加 `--change <变更名>` 指定操作目标；只有一个变更时可省略（CLI 自动检测）。
+
+## 步骤生命周期（所有阶段通用）
+
+> `sillyspec plan` 是 `sillyspec run plan` 的顶层别名，两者等价。
+
+```bash
+sillyspec run plan                             # 输出当前步骤 prompt
+sillyspec run plan --done --output "摘要"      # 完成当前步骤（--input "用户原话" 记录输入）
+sillyspec run plan --status                    # 查看阶段进度
+sillyspec run plan --skip                      # 跳过可选步骤
+sillyspec run plan --reset                     # 重置阶段（从头开始）
+sillyspec run plan --reopen --from-step N      # 重新打开已完成阶段修订（N=序号或名称）
+sillyspec run plan --wait --reason "..." --options "A,B"   # 暂停等用户决策
+sillyspec run plan --continue --answer "..."               # 恢复等待中的步骤
+sillyspec run plan --done --answer "..." --output "..."    # 一步完成 wait+done
+```
+
+## 通用参数（所有阶段适用）
+
+| 参数 | 说明 |
+|---|---|
+| `--change <名>` | 指定变更名（多活跃变更必填，单变更可省略自动检测） |
+| `--spec-dir <path>` | 指定规范目录（默认 `<项目>/.sillyspec`） |
+| `--non-interactive` | CI/脚本下禁用交互式 prompt |
+| `--interactive` | 强制交互（即便 stdin 非 TTY） |
+| `--skip-approval` | 跳过阶段转换/审批检查（不能跳产物校验 gate——review.json/文档产物硬校验仍在） |
+
+## plan 特有
+
+### 动态步骤
+
+plan 的步骤是动态的：`generate_plan`（生成分级计划）→ `review_plan`（审查计划，按规模分级：tier=self 当前 agent 自审 / tier=independent 启动独立审查子代理产出 stage review.json，避免生成+自审同一次输出的偏差）→ CLI 从 `tasks.md` 注册表解析出 task 自动插入"任务蓝图协调器"步骤（per-task；plan.md 只提供 Wave 引用分组）。这是正常行为，不要手动添加。
+
+### Stage Review Gate（plan 的 design review.json）
+
+`review_plan` 步骤在 `tier=independent` 时产出一个 stage 级 `review.json`，CLI `Stage Review Gate` 硬校验其 schema 与 `docHash` 真实性。
+
+- 路径：`.sillyspec/.runtime/stage-reviews/plan-review-<stage-review-run-id>/review.json`（目录可能不存在需手建；run-id 由该步 `--done` prompt 输出指定）。marker 文件 `.runtime/current-stage-review-run-id-plan-<变更名>`。
+- **run-id / marker 由 CLI 自动生成注入**（review step prompt 渲染时 echo 完整目录路径 + 写 marker；撞 gate 报缺 review.json 时 gate 也 echo 完整路径 + 写 marker）。直接用 CLI 给的路径写 review.json，**勿手算 run-id（必须 `review-` 前缀）、勿手写 marker**。卡住时用 `sillyspec register-stage-review --change <名> --stage plan` 一步生成。
+- 字段（`schemaVersion:1`，`reviewType=plan` —— plan 阶段主审查文档是 `plan.md`；execute 阶段才是 `acceptance`）：
+
+  ```json
+  {
+    "schemaVersion": 1,
+    "reviewType": "plan",
+    "reviewedFiles": ["changes/<变更名>/plan.md"],   // [0] 为主文档
+    "docHash": "<sha256(reviewedFiles[0] 文件内容，hex)>",
+    "specVerdict": "pass",       // pass | fail | cannot_verify
+    "qualityVerdict": "pass",    // pass | fail | cannot_verify
+    "checklist": [               // 扁平数组，逐条对照 plan 章节/Wave 结构/task 完整性核验
+      { "item": "Wave 分级合理", "result": "pass", "note": "..." }   // result: pass | gap | fail
+    ],
+    "requiredEvidence": [],      // cannot_verify 时必填非空
+    "reviewerNotes": "..."
+  }
+  ```
+
+- `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，以你实际收到的注入版契约为权威逐字模板。
+
+### 契约门控（阻断完成）
+
+- **plan 启动前**：CLI 校验 `design.md` 是否满足 plan 契约（缺文件变更清单/风险登记/自审章节会阻断）。若失败需先 `sillyspec run brainstorm --reopen --from-step N` 修订设计。
+- **plan 完成时**：CLI 校验 `tasks.md`（任务注册表）× `plan.md`（Wave ID 引用）是否满足 execute 契约（引用存在性/覆盖恰一次/编号连续/旧格式拦）。失败会阻断完成，提示修复后重新 `--done`。
+
+### 生产接线路径检查
+
+plan 完成校验会检查：design 提到入口文件（cli.ts/main.ts/server.ts 等）但 task 的 allowed_paths 不含该文件 → 报 error。若确实不需要改入口，在 design.md 明示理由。
+
+## 跨仓 task 卡片协议（一个 change 改多个仓库）
+
+单个 change 的 task 可以分散到主仓 + 多个跨仓仓实现（典型场景：dogfood 自指、monorepo 多包仓、共享库 + 调用方联合改造）。**单仓 change 不需要任何跨仓配置**（所有 task 不写 `repo:` 即走原流程，零回归）。
+
+### 跨仓 task 卡片字段
+
+在 `tasks/task-NN.md` frontmatter 加：
+
+- `repo: <key>`（可选，缺省='main'=主仓 task）：task 所属仓的 key。key 必须在 `.sillyspec/local.yaml` `repos:` 段注册（`main` 隐式=主仓不用注册）。跨仓 change 缺注册 → execute 启动 fail-closed 阻断。
+- `allowed_paths`：跨仓 task 时指**相对跨仓仓根**的路径（非主仓根）。例如跨仓 task 改 `sillyspec` 仓的 `src/foo.js`，allowed_paths 写 `src/foo.js`（相对 sillyspec 仓根），不是 `../sillyspec/src/foo.js`。
+- `base_commit` / `head_commit`：**不要手写**——CLI 在 execute 派发/回收时自动落盘双锡点（锁 base/head 防 diff 漂移），plan 阶段不写。
+
+### local.yaml `repos:` 段（跨仓注册表）
+
+> 📍 `local.yaml` 恒在 `.sillyspec/local.yaml`——项目根目录**没有**这个文件，别去那里找或新建（hook 会拦）。worktree 内该文件不随 checkout 出现，读配置直接跑 `sillyspec config cat`（自动定位到主仓真实配置）；可用键清单见 `sillyspec config schema`。
+
+跨仓 change 的每个 repo key 都要注册（execute 启动 fail-closed 校验）。**用命令注册，勿手编 YAML**：
+
+```
+sillyspec local register-repo <key> <跨仓仓根路径>
+```
+
+（外科手术式写入，只动 `repos:` 段，其余内容保留；execute 启动报缺注册时，报错文案里就带这条命令。）手写格式参考：
+
+```yaml
+repos:
+  shared-lib: ../shared-lib
+  tool-repo: C:/path/to/your/tool-repo
+```
+
+key = task 卡 `repo:` 引用名，value = 跨仓仓绝对路径（或相对主仓根的路径）。`main` 不用注册。
+
+### design.md 文件变更清单按仓分段
+
+跨仓 change 的 `## 文件变更清单` 段须按仓分段，段头格式 `## <repo> 仓变更`（主仓段头可省略或写 `## main 仓变更`）：
+
+```markdown
+## 文件变更清单
+
+### sillyspec 仓变更
+| 操作 | 文件路径 | 说明 |
+|---|---|---|
+| 修改 | src/task-review.js | 跨仓 task 改的文件 |
+
+### main 仓变更
+| 操作 | 文件路径 | 说明 |
+|---|---|---|
+| 修改 | src/index.js | 主仓 task 改的文件 |
+```
+
+plan 完成校验会按仓分段对账：跨仓仓路径相对跨仓仓根校验 task allowed_paths 覆盖，主仓路径相对主仓根校验。跨仓 task 与主仓 task 同名物理路径分属不同 repo 不判冲突。
+
+### Wave 划分
+
+同 Wave 内允许混合主仓 + 跨仓 task（execute 按 per-task workdir 派发，不强制同 Wave 同 repo）。共享文件的 task 仍须分到不同 Wave（同 Wave 共享文件会被强制并行，子代理互相覆盖）。
+
+## 阶段流转
+
+```
+brainstorm → plan → execute
+```
+
+plan 完成后（plan.md 通过 execute 契约校验），运行 `sillyspec run execute --change <变更名>` 开始实现。
+
+## 铁律
+
+- **必须用 exec 工具（shell）执行 CLI，不要自己编造流程**
+- 只做当前步骤 prompt 描述的操作，不跳过、不自行扩展
+- tasks.md 是任务清单唯一真相（checkbox 注册表，plan 阶段展开写回——保留 ql-xxx 等非 task-XX 行）；plan.md Wave 段只写纯 ID 引用行（`- task-XX`），不重抄任务名
+- 完成后立即 `--done`，不跳过
+
+## 用户指令
+$ARGUMENTS

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

@@ -25,7 +25,7 @@ quick 阶段的 `--change` 语义是「关联变更」**且会触发步骤重置
 > `sillyspec quick` 是 `sillyspec run quick` 的顶层别名，两者等价。
 
 ```bash
-sillyspec run quick --input "<一句话任务描述>"  # 启动新会话（首次启动必带 --input，见下方参数表；输出当前步骤 prompt + 记录 baseline）
+sillyspec run quick                            # 输出当前步骤 prompt（首次会记录 baseline）
 sillyspec run quick --done --output "摘要"     # 完成当前步骤
 sillyspec run quick --status                   # 查看阶段进度
 sillyspec run quick --skip                     # 跳过可选步骤
@@ -50,7 +50,7 @@ sillyspec run quick --done --change quick-<hash> --output "…"  # 完成该会
 | 参数 | 说明 |
 |---|---|
 | `--spec-dir <path>` | 指定规范目录（默认 `<项目>/.sillyspec`） |
-| `--input "<一句话任务描述>"` | 通用参数，**quick 启动必带（agent 视角必填）**：作为 QUICKLOG 条目标题，条目从第一分钟即语义可读。漏带则落「(quick 任务)」占位标题——CLI 启动即警告并建议放弃重启补带（长任务白跑一轮）、平台「快速修复」列表默认隐藏进行中的占位条目、语义标题要到最终 `--done` 才回填。仅两豁免可免传：关联变更有 proposal/design 标题可自动提取；CI/脚本确无语义可描述 |
+| `--input "<一句话任务描述>"` | 通用参数，**quick 启动时强烈建议带**：作为 QUICKLOG 条目标题，条目从第一分钟即语义可读。不带则落「(quick 任务)」占位标题——平台「快速修复」列表默认隐藏进行中的占位条目，语义标题要到最终 `--done` 才回填（关联变更有 proposal/design 标题时可自动提取，免传） |
 | `--non-interactive` | CI/脚本下禁用交互式 prompt |
 | `--interactive` | 强制交互（即便 stdin 非 TTY） |
 | `--skip-approval` | 跳过阶段转换/审批检查（不能跳产物校验 gate——review.json/文档产物硬校验仍在） |
@@ -84,21 +84,21 @@ sillyspec run quick --done --change quick-<hash> --output "…"  # 完成该会
 # 推荐启动：带一句话语义标题（QUICKLOG/平台快速修复列表进行中即可见可读）
 sillyspec run quick --input "修复登录限流 INCR 计数误清" --linked-changes none --files src/auth.ts
 
-# 单变更项目，直接开始（--input 必带）
-sillyspec run quick --input "<一句话任务描述>"
+# 单变更项目，直接开始
+sillyspec run quick
 
 # 多变更项目，显式不关联
-sillyspec run quick --input "<一句话任务描述>" --linked-changes none
+sillyspec run quick --linked-changes none
 
-# 多变更项目，关联到指定变更（关联变更有 proposal/design 标题时可免 --input）
+# 多变更项目，关联到指定变更
 sillyspec run quick --linked-changes 2026-07-03-add-login
 
-# CI/脚本（非交互，避免 prompt 崩溃；无语义可描述时是唯一可省 --input 的场景）
+# CI/脚本（非交互，避免 prompt 崩溃）
 sillyspec run quick --non-interactive
 sillyspec run quick --done --linked-changes none --output "修复手机号校验"
 
 # 限定修改文件范围
-sillyspec run quick --input "<一句话任务描述>" --files src/phone.ts,src/phone.test.ts
+sillyspec run quick --files src/phone.ts,src/phone.test.ts
 ```
 
 ## 铁律

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

@@ -1,91 +1,87 @@
----
-name: sillyspec:verify
-description: 用于验证代码实现是否符合 design 和模块文档。适合用户说"验证下、检查下、跑 verify"。对照 design.md + 模块文档检查任务完成度、设计一致性、运行测试。
----
-
-## 何时使用
-
-- 用户说"验证下、检查下、跑 verify"
-- 对照 design.md + 模块文档检查任务完成度
-- 设计一致性检查 + 运行测试套件
-- 产出 `verify-result.md`（PASS / PASS WITH NOTES / FAIL）
-
-## 多变更说明
-
-项目有多个活跃变更（`.sillyspec/changes/` 下有多个目录）时，所有 `sillyspec run` 命令需加 `--change <变更名>` 指定操作目标；只有一个变更时可省略（CLI 自动检测）。
-
-## 步骤生命周期（所有阶段通用）
-
-> `sillyspec verify` 是 `sillyspec run verify` 的顶层别名，两者等价。
-
-```bash
-sillyspec run verify                           # 输出当前步骤 prompt
-sillyspec run verify --done --output "摘要"    # 完成当前步骤（--input "用户原话" 记录输入）
-sillyspec run verify --status                  # 查看阶段进度
-sillyspec run verify --skip                    # 跳过可选步骤
-sillyspec run verify --reset                   # 重置阶段（从头开始）
-sillyspec run verify --reopen --from-step N    # 重新打开已完成阶段修订（N=序号或名称）
-```
-
-## 通用参数（所有阶段适用）
-
-| 参数 | 说明 |
-|---|---|
-| `--change <名>` | 指定变更名（多活跃变更必填，单变更可省略自动检测） |
-| `--spec-dir <path>` | 指定规范目录（默认 `<项目>/.sillyspec`） |
-| `--non-interactive` | CI/脚本下禁用交互式 prompt |
-| `--skip-approval` | 跳过阶段转换/审批检查（不能跳产物校验 gate——review.json/文档产物硬校验仍在） |
-
-## verify 特有：完成门控（重要）
-
-verify 是只读阶段（**禁止改代码/改 git 状态**，只检查 + 写报告）。
-
-**diff 对账基点**：本变更走 worktree 时，「加载规范并锚定」步骤会注入 worktree 基线锚点（分支名 + `git merge-base` 真实基点）——对照设计做 diff 对账时以它为基点，**不要拿主仓当前 HEAD 当基点**（主仓在 execute 期间可能被并行推进，用错基点会把别人的演进误判为本变更越权改动）。task review 的 base/head 引用分支上的 commit，逐 task 核验用 `git diff <base>..<head>`。完成时有硬校验：
-
-- **必须产出 `verify-result.md`**——不存在则阻断完成（不能跳过报告直接 `--done`）
-- **结论为 `FAIL` 则阻断完成**——不能带着 FAIL 标记 verify 完成
-- **`integration-critical` / `deployment-critical` 变更**（design/plan 含 daemon/session/lease/lifecycle 等关键词）：结论 PASS WITH NOTES 降级为 FAIL，必须有真实集成证据（Runtime Evidence section）——该证据为 Agent 自报告，CLI 仅校验其字面存在、不独立运行时核验，须真实执行过
-- `verify-required-evidence.json`（execute 写入，schema `{items:[{task,verdict,evidence:[]}]}`）中 cannot_verify 任务未在 verify-result.md 体现 → **advisory warn（不阻断归档）**；evidence 是否真满足（satisfied/missing/partial）由 agent 在 verify-result.md 自报告，CLI 只查任务被提及、不替你语义判定。结论能否 PASS 由你诚实判定（有 missing evidence 不应 PASS）。
-
-被阻断时 CLI 打印 ❌ 校验失败，不会提示"验证通过"。修复 `verify-result.md` 后重新 `--done`。
-
-## verify-result.md 格式
-
-> 🔧 **机械探针 + 报告骨架一条命令**：`sillyspec verify-probes --change <变更名> --init`——探针 1（TODO 标记）/3（测试覆盖）/5（API 契约对账）/6（删除对账）CLI 跑完并预填进 verify-result.md 骨架（七章节、已存在不覆盖）；探针 2/4（关键词/决策追踪）与断言抽查、集成盲区标注是语义判断，替换骨架里的 `<!--TODO-->` 完成。结论必须写明 PASS/FAIL——留「待填」会被 gate 判不过。
->
-> 🔧 **test/lint 实测对账**：`--done` 时 CLI 亲自执行 local.yaml 的 `commands.test`（实测失败阻断 verify 完成）与 `commands.lint`（advisory 对账，实测失败会明示）——自报告与实测不符时以实测为准，勿谎报跑过。
->
-> 🔧 探针 7 矩阵 covered/partial 证据锚点三形态：file:line / `.test.` 测试文件名 / 反引号包裹的路径或测试名——行号可省（D-005@v2，与硬门/advisory/预填说明四处同口径）。
->
-> 🔧 verify lint/test 门禁隔离快照缺 gitignored 生成物时，主仓 local.yaml 配 gate_snapshot.copy（junction/复制）与 gate_snapshot.commands（快照内跑生成命令，只放生成物命令——环境目录是活链接，勿改写 node_modules/venv）（D-002@v2）。
-
-```markdown
-# 验证报告
-## 结论
-PASS / PASS WITH NOTES / FAIL      ← 必须有结论章节（标题含"结论/Conclusion/Result/结果"即可，不限于确切"## 结论"），FAIL 会阻断 verify 完成
-## 任务完成度
-## 设计一致性
-## 探针结果
-## 测试结果
-## 变更风险等级
-## Runtime Evidence（integration/deployment-critical 必填；自报告，CLI 仅字面校验、不独立核验）
-```
-
-## 阶段流转
-
-```
-execute → verify → archive
-```
-
-verify 通过（PASS）后，运行 `sillyspec run archive --change <变更名>` 归档。FAIL 则修复后重跑 `sillyspec run verify`。
-
-## 铁律
-
-- **必须用 exec 工具（shell）执行 CLI，不要自己编造流程**
-- verify 阶段**绝对禁止** git checkout/restore/reset、删除/覆盖源码文件——只检查 + 报告
-- 发现问题只报告，不尝试修复（修复回 execute）
-- `verify-result.md` 结论必须基于证据，不写"看起来没问题"
-- 完成后立即 `--done`，不跳过
-
-## 用户指令
-$ARGUMENTS
+---
+name: sillyspec:verify
+description: 用于验证代码实现是否符合 design 和模块文档。适合用户说"验证下、检查下、跑 verify"。对照 design.md + 模块文档检查任务完成度、设计一致性、运行测试。
+---
+
+## 何时使用
+
+- 用户说"验证下、检查下、跑 verify"
+- 对照 design.md + 模块文档检查任务完成度
+- 设计一致性检查 + 运行测试套件
+- 产出 `verify-result.md`（PASS / PASS WITH NOTES / FAIL）
+
+## 多变更说明
+
+项目有多个活跃变更（`.sillyspec/changes/` 下有多个目录）时，所有 `sillyspec run` 命令需加 `--change <变更名>` 指定操作目标；只有一个变更时可省略（CLI 自动检测）。
+
+## 步骤生命周期（所有阶段通用）
+
+> `sillyspec verify` 是 `sillyspec run verify` 的顶层别名，两者等价。
+
+```bash
+sillyspec run verify                           # 输出当前步骤 prompt
+sillyspec run verify --done --output "摘要"    # 完成当前步骤（--input "用户原话" 记录输入）
+sillyspec run verify --status                  # 查看阶段进度
+sillyspec run verify --skip                    # 跳过可选步骤
+sillyspec run verify --reset                   # 重置阶段（从头开始）
+sillyspec run verify --reopen --from-step N    # 重新打开已完成阶段修订（N=序号或名称）
+```
+
+## 通用参数（所有阶段适用）
+
+| 参数 | 说明 |
+|---|---|
+| `--change <名>` | 指定变更名（多活跃变更必填，单变更可省略自动检测） |
+| `--spec-dir <path>` | 指定规范目录（默认 `<项目>/.sillyspec`） |
+| `--non-interactive` | CI/脚本下禁用交互式 prompt |
+| `--skip-approval` | 跳过阶段转换/审批检查（不能跳产物校验 gate——review.json/文档产物硬校验仍在） |
+
+## verify 特有：完成门控（重要）
+
+verify 是只读阶段（**禁止改代码/改 git 状态**，只检查 + 写报告）。
+
+**diff 对账基点**：本变更走 worktree 时，「加载规范并锚定」步骤会注入 worktree 基线锚点（分支名 + `git merge-base` 真实基点）——对照设计做 diff 对账时以它为基点，**不要拿主仓当前 HEAD 当基点**（主仓在 execute 期间可能被并行推进，用错基点会把别人的演进误判为本变更越权改动）。task review 的 base/head 引用分支上的 commit，逐 task 核验用 `git diff <base>..<head>`。完成时有硬校验：
+
+- **必须产出 `verify-result.md`**——不存在则阻断完成（不能跳过报告直接 `--done`）
+- **结论为 `FAIL` 则阻断完成**——不能带着 FAIL 标记 verify 完成
+- **`integration-critical` / `deployment-critical` 变更**（design/plan 含 daemon/session/lease/lifecycle 等关键词）：结论 PASS WITH NOTES 降级为 FAIL，必须有真实集成证据（Runtime Evidence section）——该证据为 Agent 自报告，CLI 仅校验其字面存在、不独立运行时核验，须真实执行过
+- `verify-required-evidence.json`（execute 写入，schema `{items:[{task,verdict,evidence:[]}]}`）中 cannot_verify 任务未在 verify-result.md 体现 → **advisory warn（不阻断归档）**；evidence 是否真满足（satisfied/missing/partial）由 agent 在 verify-result.md 自报告，CLI 只查任务被提及、不替你语义判定。结论能否 PASS 由你诚实判定（有 missing evidence 不应 PASS）。
+
+被阻断时 CLI 打印 ❌ 校验失败，不会提示"验证通过"。修复 `verify-result.md` 后重新 `--done`。
+
+## verify-result.md 格式
+
+> 🔧 **机械探针 + 报告骨架一条命令**：`sillyspec verify-probes --change <变更名> --init`——探针 1（TODO 标记）/3（测试覆盖）/5（API 契约对账）/6（删除对账）CLI 跑完并预填进 verify-result.md 骨架（七章节、已存在不覆盖）；探针 2/4（关键词/决策追踪）与断言抽查、集成盲区标注是语义判断，替换骨架里的 `<!--TODO-->` 完成。结论必须写明 PASS/FAIL——留「待填」会被 gate 判不过。
+>
+> 🔧 **test/lint 实测对账**：`--done` 时 CLI 亲自执行 local.yaml 的 `commands.test`（实测失败阻断 verify 完成）与 `commands.lint`（advisory 对账，实测失败会明示）——自报告与实测不符时以实测为准，勿谎报跑过。
+
+```markdown
+# 验证报告
+## 结论
+PASS / PASS WITH NOTES / FAIL      ← 必须有结论章节（标题含"结论/Conclusion/Result/结果"即可，不限于确切"## 结论"），FAIL 会阻断 verify 完成
+## 任务完成度
+## 设计一致性
+## 探针结果
+## 测试结果
+## 变更风险等级
+## Runtime Evidence（integration/deployment-critical 必填；自报告，CLI 仅字面校验、不独立核验）
+```
+
+## 阶段流转
+
+```
+execute → verify → archive
+```
+
+verify 通过（PASS）后，运行 `sillyspec run archive --change <变更名>` 归档。FAIL 则修复后重跑 `sillyspec run verify`。
+
+## 铁律
+
+- **必须用 exec 工具（shell）执行 CLI，不要自己编造流程**
+- verify 阶段**绝对禁止** git checkout/restore/reset、删除/覆盖源码文件——只检查 + 报告
+- 发现问题只报告，不尝试修复（修复回 execute）
+- `verify-result.md` 结论必须基于证据，不写"看起来没问题"
+- 完成后立即 `--done`，不跳过
+
+## 用户指令
+$ARGUMENTS

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sillyspec",
-  "version": "3.28.12",
+  "version": "3.29.0",
   "description": "SillySpec CLI — 流程状态机，让 AI 严格按步骤来",
   "icon": "logo.jpg",
   "homepage": "https://sillyspec.ppdmq.top/",