sillyspec 3.28.0 → 3.28.3

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

@@ -1,93 +1,54 @@
----
-name: sillyspec:auto
-description: 自动模式 — 全流程自动推进（通用版）
-argument-hint: "<需求描述>"
----
-
-## 交互规范
-
-**当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项以参数传入。** 不要用编号列表让用户手动输入数字。
-
-## 用法
-
-- `/sillyspec:auto 实现用户登录功能`
-- `/sillyspec:auto 修复搜索结果的排序问题`
-
-## 任务
-$ARGUMENTS
-
----
-
-## 执行流程
-
-你是全流程编排器，按 brainstorm → plan → execute → verify 顺序自动推进。
-
-### 启动
-
-```bash
-sillyspec run auto --input "<用户需求>" [--mode <模式>]
-```
-
-2. 读取 CLI 输出的 step prompt（含角色描述）
-3. 执行 prompt 中的操作
-4. **记录 CLI 输出中显示的 Change 名称**（如 `Change: 2026-06-02-xxx`）
-
-### 步骤循环
-
-重复以下循环直到 CLI 输出"全部流程已完成"：
-
-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 为准。
-
-## 关键规则
-
-- 不要跳过任何步骤
-- 不要手动修改进度数据（SQLite 数据库）
-- 不要自动 commit，只 `git add`
-- 不要使用 npx
-- 不要编造不存在的 CLI 子命令
-- 遇到命令报错 → 展示错误，暂停等用户介入
-- **每次 `sillyspec run auto --done` 都必须携带 `--change <变更名>`**（= CLI 首次输出的 Change 名）
-
-## 异常处理
-
-- 命令执行失败 → 展示错误信息，暂停等待用户指示
-- 用户说"停止"/"暂停" → 立即停止，报告当前进度
-
-## 完成条件
-
-CLI 输出"全部流程已完成"后，输出完整流程总结，提示用户提交改动（`/sillyspec:commit`）。
+---
+name: sillyspec:auto
+description: 自动模式 — 全流程自动推进（通用版）
+argument-hint: "<需求描述>"
+---
+
+## 交互规范
+
+**当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项以参数传入。** 不要用编号列表让用户手动输入数字。
+
+## 用法
+
+- `/sillyspec:auto 实现用户登录功能`
+- `/sillyspec:auto 修复搜索结果的排序问题`
+
+## 任务
+$ARGUMENTS
+
+---
+
+## 执行流程
+
+按 brainstorm → plan → execute → verify 顺序自动推进；**编排由 CLI driver 承担，你只执行判断步**。
+
+### 启动
+
+```bash
+sillyspec run auto --input "<用户需求>" [--mode <模式>]
+```
+
+零活跃变更时 CLI 自动创建（也可 `--change <名>` 指定）；多活跃变更 CLI 会列出候选要求显式指定。单活跃自动选中并回显，无需记忆/传递变更名。
+
+### 每步循环（唯一纪律）
+
+1. 跑 CLI 给出的命令（启动时是上面的 run auto；此后每步读上一步输出尾部的 **SS-META 块**）。
+2. 读 prompt 尾部机器可读元数据块：
+
+   ```
+   <!--SS-META:{"stage":...,"requiresUser":true|false,"doneCommand":"...","waitHint":"..."}-->
+   ```
+
+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）同义。
+
+### 边界
+
+- 中断恢复：直接重跑 `sillyspec run auto`（进度已落盘，从断点续）。
+- 分类为 quick 的小变更：CLI 会提示改跑 `sillyspec run quick`，照提示执行。

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

@@ -1,114 +1,114 @@
----
-name: sillyspec:brainstorm
-description: 用于正式开始开发前的需求澄清和技术方案设计。适合用户提出新功能、新模块、架构调整、复杂改造，或说"先做需求分析、输出技术方案、创建变更前先梳理、帮我设计下"。产出结构化方案（design/proposal/requirements/tasks 四件套），但不直接写代码。
----
-
-## 交互规范
-
-**当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项以参数传入。** 不要用编号列表让用户手动输入数字。
-
-## 何时使用
-
-- 用户提出新功能、新模块、架构调整、复杂改造
-- 用户说"先做需求分析、输出技术方案、创建变更前先梳理、帮我设计下"
-- 产出：`design.md` + `proposal.md` + `requirements.md` + `tasks.md`（四件套），不写代码
-
-## 多变更说明
-
-项目有多个活跃变更（`.sillyspec/changes/` 下有多个目录）时，所有 `sillyspec run` 命令需加 `--change <变更名>` 指定操作目标；只有一个变更时可省略（CLI 自动检测）。建议变更名格式：`YYYY-MM-DD-<简短描述>`。
-
-## 步骤生命周期（所有阶段通用）
-
-> `sillyspec brainstorm` 是 `sillyspec run brainstorm` 的顶层别名，两者等价。
-
-```bash
-sillyspec run brainstorm                       # 输出当前步骤 prompt
-sillyspec run brainstorm --done --output "摘要"     # 完成当前步骤（--input "用户原话" 记录输入）
-sillyspec run brainstorm --status              # 查看阶段进度
-sillyspec run brainstorm --skip                # 跳过可选步骤
-sillyspec run brainstorm --reset               # 重置阶段（从头开始）
-sillyspec run brainstorm --reopen --from-step N     # 重新打开已完成阶段修订（N=序号或名称）
-sillyspec run brainstorm --wait --reason "..." --options "A,B"   # 暂停等用户决策
-sillyspec run brainstorm --continue --answer "..."               # 恢复等待中的步骤
-sillyspec run brainstorm --done --answer "..." --output "..."    # 一步完成 wait+done
-```
-
-## 通用参数（所有阶段适用）
-
-| 参数 | 说明 |
-|---|---|
-| `--change <名>` | 指定变更名（多活跃变更必填，单变更可省略自动检测） |
-| `--spec-dir <path>` | 指定规范目录（默认 `<项目>/.sillyspec`） |
-| `--non-interactive` | CI/脚本下禁用交互式 prompt |
-| `--interactive` | 强制交互（即便 stdin 非 TTY） |
-| `--skip-approval` | 跳过阶段转换/审批检查（不能跳产物校验 gate——review.json/文档产物硬校验仍在） |
-
-## brainstorm 特有：requiresWait 步骤
-
-某些步骤（如"对话式探索与需求澄清"）需要用户输入。两种方式：
-
-> 自动去重：若前置 step 已对同一问题（waitReason 归一化后相同）确认过，后续重复 wait 会自动跳过，无需再 `--wait`。
-
-- **方式一（推荐）**：分步——先 `--wait` 记录等待，让用户亲眼看到 CLI 打出的选项再作答，再 `--continue --answer`，最后 `--done`：
-  ```bash
-  sillyspec run brainstorm --wait --change <名> --reason "等待用户回答" --output "探索问题"
-  sillyspec run brainstorm --continue --answer "用户回答" --change <名>
-  sillyspec run brainstorm --done --change <名> --output "需求已澄清"
-  ```
-- **方式二**：AI 自行与用户交互后，一步完成（仅在用户已在对话中明确给出答案、无需再走 CLI 等待展示时用）：
-  ```bash
-  sillyspec run brainstorm --done --change <名> --answer "用户回答" --output "需求已澄清"
-  ```
-
-> ⚠️ 两种方式都要求 `--answer` 是**用户真实的回答**，不是你替用户编的回答。`requiresWait` 门只校验 `--answer` 非空，挡不住「AI 伪造用户回答」——所以对方案选择/设计确认这类关键决策，优先用方式一让用户亲手作答，而不是 AI 中继一句话带过。
-
-## 阶段流转
-
-```
-                ┌─ scale=large → plan（四件套齐）
-scan → brainstorm ┤
-                └─ scale=small → quick --linked-changes（仅 design.md）
-```
-
-brainstorm 完成时按 design.md frontmatter 的 `scale` 分叉：
-- **large**（多文件/跨模块/有状态机或 schema 变更）：四件套齐 + Design Grill 审查通过（tier=independent 时由独立审查子代理产出 stage review.json）→ `sillyspec run plan --change <变更名>`
-- **small**（≤2 文件、单模块、无跨模块依赖）：仅生成 design.md → `sillyspec run quick --linked-changes <变更名>`
-
-> 规模由 AI 在 brainstorm 最后一步评估并写入 design.md frontmatter。判错可手动改 `scale` 后再跑相应阶段。
-
-### Stage Review Gate（brainstorm 末尾的 design review.json）
-
-brainstorm 在 `tier=independent` 规模下除 design.md 等四件套外，还需产出一个 stage 级 `review.json`，CLI `Stage Review Gate` 硬校验其 schema 与 `docHash` 真实性。
-
-- 路径：`.sillyspec/.runtime/stage-reviews/brainstorm-review-<stage-review-run-id>/review.json`（目录可能不存在需手建；run-id 由该步 `--done` prompt 输出指定）。marker 文件 `.runtime/current-stage-review-run-id-brainstorm-<变更名>`。
-- **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 brainstorm` 一步生成。
-- 字段（`schemaVersion:1`，`reviewType=design` —— 区别于 execute 的 `acceptance`）：
-
-  ```json
-  {
-    "schemaVersion": 1,
-    "reviewType": "design",
-    "reviewedFiles": ["changes/<变更名>/design.md"],   // [0] 为主文档
-    "docHash": "<sha256(reviewedFiles[0] 文件内容，hex)>",
-    "specVerdict": "pass",       // pass | fail | cannot_verify
-    "qualityVerdict": "pass",    // pass | fail | cannot_verify
-    "checklist": [               // 扁平数组，逐条对照 design 章节核验
-      { "item": "背景与目标", "result": "pass", "note": "..." }   // result: pass | gap | fail
-    ],
-    "requiredEvidence": [],      // cannot_verify 时必填非空
-    "reviewerNotes": "..."
-  }
-  ```
-
-- `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 自审，不强制独立子代理。
-- 运行时 CLI 会把精确 schema 表 + 完整 JSON 示例 + docHash 算法注入到该步 prompt，以你实际收到的注入版契约为权威逐字模板。
-
-## 铁律
-
-- **必须用 exec 工具（shell）执行 CLI，不要自己编造流程**
-- 只做当前步骤 prompt 描述的操作，不跳过、不自行扩展
-- 产物写入 CLI 输出的 `changeDir` 目录（如 `<changeDir>/design.md`），不要自己拼路径
-- 完成后立即 `--done`，不跳过
-
-## 用户指令
-$ARGUMENTS
+---
+name: sillyspec:brainstorm
+description: 用于正式开始开发前的需求澄清和技术方案设计。适合用户提出新功能、新模块、架构调整、复杂改造，或说"先做需求分析、输出技术方案、创建变更前先梳理、帮我设计下"。产出结构化方案（design/proposal/requirements/tasks 四件套），但不直接写代码。
+---
+
+## 交互规范
+
+**当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项以参数传入。** 不要用编号列表让用户手动输入数字。
+
+## 何时使用
+
+- 用户提出新功能、新模块、架构调整、复杂改造
+- 用户说"先做需求分析、输出技术方案、创建变更前先梳理、帮我设计下"
+- 产出：`design.md` + `proposal.md` + `requirements.md` + `tasks.md`（四件套），不写代码
+
+## 多变更说明
+
+项目有多个活跃变更（`.sillyspec/changes/` 下有多个目录）时，所有 `sillyspec run` 命令需加 `--change <变更名>` 指定操作目标；只有一个变更时可省略（CLI 自动检测）。建议变更名格式：`YYYY-MM-DD-<简短描述>`。
+
+## 步骤生命周期（所有阶段通用）
+
+> `sillyspec brainstorm` 是 `sillyspec run brainstorm` 的顶层别名，两者等价。
+
+```bash
+sillyspec run brainstorm                       # 输出当前步骤 prompt
+sillyspec run brainstorm --done --output "摘要"     # 完成当前步骤（--input "用户原话" 记录输入）
+sillyspec run brainstorm --status              # 查看阶段进度
+sillyspec run brainstorm --skip                # 跳过可选步骤
+sillyspec run brainstorm --reset               # 重置阶段（从头开始）
+sillyspec run brainstorm --reopen --from-step N     # 重新打开已完成阶段修订（N=序号或名称）
+sillyspec run brainstorm --wait --reason "..." --options "A,B"   # 暂停等用户决策
+sillyspec run brainstorm --continue --answer "..."               # 恢复等待中的步骤
+sillyspec run brainstorm --done --answer "..." --output "..."    # 一步完成 wait+done
+```
+
+## 通用参数（所有阶段适用）
+
+| 参数 | 说明 |
+|---|---|
+| `--change <名>` | 指定变更名（多活跃变更必填，单变更可省略自动检测） |
+| `--spec-dir <path>` | 指定规范目录（默认 `<项目>/.sillyspec`） |
+| `--non-interactive` | CI/脚本下禁用交互式 prompt |
+| `--interactive` | 强制交互（即便 stdin 非 TTY） |
+| `--skip-approval` | 跳过阶段转换/审批检查（不能跳产物校验 gate——review.json/文档产物硬校验仍在） |
+
+## brainstorm 特有：requiresWait 步骤
+
+某些步骤（如"对话式探索与需求澄清"）需要用户输入。两种方式：
+
+> 自动去重：若前置 step 已对同一问题（waitReason 归一化后相同）确认过，后续重复 wait 会自动跳过，无需再 `--wait`。
+
+- **方式一（推荐）**：分步——先 `--wait` 记录等待，让用户亲眼看到 CLI 打出的选项再作答，再 `--continue --answer`，最后 `--done`：
+  ```bash
+  sillyspec run brainstorm --wait --change <名> --reason "等待用户回答" --output "探索问题"
+  sillyspec run brainstorm --continue --answer "用户回答" --change <名>
+  sillyspec run brainstorm --done --change <名> --output "需求已澄清"
+  ```
+- **方式二**：AI 自行与用户交互后，一步完成（仅在用户已在对话中明确给出答案、无需再走 CLI 等待展示时用）：
+  ```bash
+  sillyspec run brainstorm --done --change <名> --answer "用户回答" --output "需求已澄清"
+  ```
+
+> ⚠️ 两种方式都要求 `--answer` 是**用户真实的回答**，不是你替用户编的回答。`requiresWait` 门只校验 `--answer` 非空，挡不住「AI 伪造用户回答」——所以对方案选择/设计确认这类关键决策，优先用方式一让用户亲手作答，而不是 AI 中继一句话带过。
+
+## 阶段流转
+
+```
+                ┌─ scale=large → plan（四件套齐）
+scan → brainstorm ┤
+                └─ scale=small → quick --linked-changes（仅 design.md）
+```
+
+brainstorm 完成时按 design.md frontmatter 的 `scale` 分叉：
+- **large**（多文件/跨模块/有状态机或 schema 变更）：四件套齐 + Design Grill 审查通过（tier=independent 时由独立审查子代理产出 stage review.json）→ `sillyspec run plan --change <变更名>`
+- **small**（≤2 文件、单模块、无跨模块依赖）：仅生成 design.md → `sillyspec run quick --linked-changes <变更名>`
+
+> 规模由 AI 在 brainstorm 最后一步评估并写入 design.md frontmatter。判错可手动改 `scale` 后再跑相应阶段。
+
+### Stage Review Gate（brainstorm 末尾的 design review.json）
+
+brainstorm 在 `tier=independent` 规模下除 design.md 等四件套外，还需产出一个 stage 级 `review.json`，CLI `Stage Review Gate` 硬校验其 schema 与 `docHash` 真实性。
+
+- 路径：`.sillyspec/.runtime/stage-reviews/brainstorm-review-<stage-review-run-id>/review.json`（目录可能不存在需手建；run-id 由该步 `--done` prompt 输出指定）。marker 文件 `.runtime/current-stage-review-run-id-brainstorm-<变更名>`。
+- **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 brainstorm` 一步生成。
+- 字段（`schemaVersion:1`，`reviewType=design` —— 区别于 execute 的 `acceptance`）：
+
+  ```json
+  {
+    "schemaVersion": 1,
+    "reviewType": "design",
+    "reviewedFiles": ["changes/<变更名>/design.md"],   // [0] 为主文档
+    "docHash": "<sha256(reviewedFiles[0] 文件内容，hex)>",
+    "specVerdict": "pass",       // pass | fail | cannot_verify
+    "qualityVerdict": "pass",    // pass | fail | cannot_verify
+    "checklist": [               // 扁平数组，逐条对照 design 章节核验
+      { "item": "背景与目标", "result": "pass", "note": "..." }   // result: pass | gap | fail
+    ],
+    "requiredEvidence": [],      // cannot_verify 时必填非空
+    "reviewerNotes": "..."
+  }
+  ```
+
+- `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，以你实际收到的注入版契约为权威逐字模板。
+
+## 铁律
+
+- **必须用 exec 工具（shell）执行 CLI，不要自己编造流程**
+- 只做当前步骤 prompt 描述的操作，不跳过、不自行扩展
+- 产物写入 CLI 输出的 `changeDir` 目录（如 `<changeDir>/design.md`），不要自己拼路径
+- 完成后立即 `--done`，不跳过
+
+## 用户指令
+$ARGUMENTS

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

@@ -1,47 +1,17 @@
----
-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 自动检测
-> 
-> 当前状态：[描述]
-> 下一步：[执行的命令]
-> 
-> [开始执行...]
+---
+name: sillyspec:continue
+description: 自动判断并执行下一步
+---
+
+## 流程
+
+**先跑 `sillyspec next`**——CLI 已内置全套探测（HANDOFF / 活跃变更逐个产物推断 / task 勾选进度 / scan 文档 / 绿地棕地判定），直接输出「状态 + 下一步命令 + 依据」。
+
+1. 把探测结果转述给用户（状态 / 下一步 / 依据三行）。
+2. 按输出的建议命令直接执行对应 skill（如 `sillyspec run brainstorm` / `plan` / `execute` / `verify` / `archive`）。
+3. 仅当 CLI 异常或输出与实际明显不符时，才手工核对 `.sillyspec/` 下的产物文件后重新判断。
+
+勿自行 ls/cat 重算探测表——那就是 `next` 命令本体。
+
+## 用户指令
+$ARGUMENTS