sillyspec 3.8.5 → 3.8.6

package/templates/status.md

@@ -0,0 +1,75 @@
+## 交互规范
+**当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项以参数传入。**
+
+## 核心约束（必须遵守）
+- ❌ 修改任何文件（只读）
+
+---
+
+## 流程
+
+### Step 1: 检查工作区模式
+
+```bash
+ls .sillyspec/projects/*.yaml 2>/dev/null | grep -q .
+```
+
+**工作区模式：** 读取每个 `projects/*.yaml` 子项目列表，对每个子项目检查 PROJECT.md、docs/<project>/scan/ 文档数、进行中变更、归档数。**同时检查工作区根目录 `.sillyspec/changes/` 下的未归档变更。** 检查共享规范和工作区概览。输出汇总后结束，不执行单项目流程。
+
+工作区变更检查命令：
+```bash
+# 工作区根目录的变更
+ls .sillyspec/changes/ 2>/dev/null | grep -v archive
+ls .sillyspec/changes/archive/ 2>/dev/null | wc -l
+
+# 每个子项目的变更
+for f in .sillyspec/projects/*.yaml; do
+  [ -f "$f" ] || continue
+  proj_name=$(basename "$f" .yaml)
+  proj_path=$(grep '^path:' "$f" | head -1 | sed 's/^path:[[:space:]]*//')
+  echo "=== $proj_name changes ==="
+  ls "$proj_path"/.sillyspec/changes/ 2>/dev/null | grep -v archive
+  ls "$proj_path"/.sillyspec/changes/archive/ 2>/dev/null | wc -l
+done
+```
+
+**汇总输出格式：**
+```
+📊 SillySpec 状态
+📋 工作区模式 — N 个子项目
+
+工作区变更：
+  🔄 进行中：sec-bonus-penalty（tasks: 3/5）
+  ✅ 已归档：1 个
+
+主项目（工作区根目录）：
+  📂 代码库文档：— （主项目通常无独立代码）
+  🔄 进行中：N 个变更
+  ✅ 已归档：N 个变更
+
+┌───────────────────┬────────────┬────────────┬────────┬────────┐
+│ 子项目            │ PROJECT.md │ 代码库文档 │ 进行中 │ 已归档 │
+├───────────────────┼────────────┼────────────┼────────┼────────┤
+│ back-service      │ ✗          │ 7 份       │ 1      │ 0      │
+└───────────────────┴────────────┴────────────┴────────┴────────┘
+```
+
+**单项目模式：** 继续 Step 2。
+
+### Step 2-5: 单项目检查
+
+1. **项目基础：** PROJECT.md、docs/<project>/scan/ 文档、REQUIREMENTS.md、ROADMAP.md
+2. **进行中变更：** 对每个变更检查 design/tasks 完成度
+3. **归档历史：** `ls .sillyspec/changes/archive/ | wc -l`
+4. **代码库文档：** `ls .sillyspec/docs/<project>/scan/`
+
+### Step 6: 输出
+
+```
+📊 SillySpec 状态
+📋 项目：xxx（已初始化/未初始化）
+📂 代码库：已扫描（7 份文档）/ 未扫描
+🔄 进行中：N 个变更
+✅ 已归档：N 个变更
+💡 下一步：/sillyspec:continue
+```

package/templates/verify.md

@@ -0,0 +1,253 @@
+## 交互规范
+**当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项以参数传入。**
+
+> **可选阶段。** execute 完成后会询问是否需要 verify，也可以手动调用。
+
+## 核心约束（必须遵守）
+- ❌ 修改任何代码（只做检查和报告）
+- ❌ 跳过状态检查
+- ❌ 自行推进到下一阶段
+
+## 状态检查（必须先执行）
+
+```bash
+cat .sillyspec/STATE.md 2>/dev/null
+```
+
+检查当前阶段。如果没有 STATE.md，检查是否有未归档变更：
+
+```bash
+ls .sillyspec/changes/ 2>/dev/null | grep -v archive
+```
+
+无 STATE.md 且无未归档变更 → 提示用户先完成 execute 或用 `/sillyspec:status` 查看状态。
+
+---
+
+## 工作区模式处理
+
+如果 `.sillyspec/projects/` 目录下有 yaml 文件：
+
+1. 检查工作区根目录 `.sillyspec/changes/` 下的未归档变更
+2. 检查每个子项目 `<子项目路径>/.sillyspec/changes/` 下的未归档变更
+3. 列出所有未归档变更，让用户选择要验证哪个
+4. 根据 $ARGUMENTS 或用户选择，cd 到对应目录执行验证
+
+---
+
+## 流程
+
+### 1. 加载规范
+
+```bash
+# 确定变更目录
+if [ -n "$ARGUMENTS" ]; then
+  CHANGE_DIR=".sillyspec/changes/$ARGUMENTS"
+else
+  CHANGE_DIR=$(ls -d .sillyspec/changes/*/ 2>/dev/null | grep -v archive | tail -1)
+fi
+cat "$CHANGE_DIR"/{design,tasks}.md 2>/dev/null
+cat .sillyspec/local.yaml 2>/dev/null
+```
+
+锚定确认实际存在的文件。
+
+### 2. 逐项检查 tasks.md
+
+对每个 checkbox 报告：✅ 已完成 / ❌ 未完成 / ⚠️ 部分完成
+
+### 3. 对照 design.md
+
+架构决策？文件变更一致性？数据模型？API 设计？
+
+### 4. 运行测试套件
+
+```bash
+pnpm test 2>/dev/null || npm test 2>/dev/null || pytest 2>/dev/null || go test ./... 2>/dev/null
+```
+
+### 4b. E2E 测试
+
+检测项目中是否有 E2E 测试或测试步骤文件：
+```bash
+ls tests/e2e/ e2e/ cypress/e2e/ 2>/dev/null | head -5
+cat .sillyspec/changes/*/e2e-steps.md 2>/dev/null | head -5
+```
+
+**无任何测试** → 跳过此步骤。
+
+**有测试** → 确认修复策略（AskUserQuestion）：
+1. 自动修复，同一用例最多 5 次（超过停止，提示人工介入）
+2. 一直修复直到全绿
+3. 只报告，不自动修复
+
+**按优先级执行：**
+
+**优先级 1：专业 E2E 框架（Playwright/Cypress）**
+```bash
+npx playwright test 2>/dev/null || npx cypress run 2>/dev/null
+```
+
+**优先级 2：通用测试框架（jest/vitest）**
+```bash
+npx vitest run 2>/dev/null || npx jest 2>/dev/null
+```
+
+**优先级 3：浏览器 MCP + e2e-steps.md（兜底）**
+读取 `.sillyspec/changes/<变更名>/e2e-steps.md`，按步骤逐条执行。每条标注 ✅/❌，断言失败记为 FAILED。
+> ⚠️ 使用 MCP 执行时 AI 判断可能不如测试框架精确。追求可靠性建议安装 Playwright。
+
+**自动修复循环（选了策略 1 或 2 时）：**
+
+必须按以下流程严格执行，不可跳过：
+
+```
+ROUND = 1
+MAX_ROUNDS = 策略1时为5，策略2时为50
+
+while ROUND <= MAX_ROUNDS:
+    1. 运行失败测试，捕获完整输出（错误信息、堆栈、期望值 vs 实际值）
+    2. 如果全部通过 → 跳出循环，标记 ✅
+    3. 读取 .sillyspec/local.yaml 中当前变更的 fixAttempts
+    4. 对每个失败测试：
+       a. 如果 fixAttempts >= MAX_ROUNDS → 跳过，标记 ❌ MAX_REACHED
+       b. 否则 → 调 /sillyspec:quick 修复，prompt 必须包含：
+          - 失败的测试文件路径和测试名
+          - 完整错误信息（含期望值 vs 实际值）
+          - 相关源文件路径
+          - "只修复这个测试失败，不要改其他代码"
+       c. 修复后重跑该测试确认是否通过
+       d. 通过 → fixAttempts 保持不变；仍失败 → fixAttempts + 1
+    5. 写入 .sillyspec/local.yaml 更新 fixAttempts
+    6. ROUND++
+    7. 如果本轮无任何修复（所有失败都已 MAX_REACHED）→ 跳出循环
+```
+
+**quick 修复 prompt 模板：**
+```
+/sillyspec:quick "修复测试失败：<测试文件路径>:<测试名>
+
+错误信息：
+<完整错误输出，包含期望值和实际值>
+
+相关文件：
+<被测源文件路径>
+
+只修复这个测试失败，不要改其他代码。修完后运行该测试确认通过。"
+```
+
+**禁止行为：**
+- ❌ 只看错误摘要就修复（必须看完整输出）
+- ❌ 跳过 fixAttempts 计数
+- ❌ 一次 quick 修复多个不相关的失败（逐个修复，每次修复后重跑确认）
+- ❌ 主代理直接修改代码（verify 阶段禁止改代码，必须通过 /sillyspec:quick）
+
+**更新测试结果到 `.sillyspec/local.yaml`（按变更名隔离，覆盖写入）：**
+```yaml
+e2e:
+  {变更名}:
+    login.spec.ts:
+      status: passed
+      fixAttempts: 0
+    form-submit.spec.ts:
+      status: failed
+      fixAttempts: 3
+```
+
+### 5. 代码质量扫描
+
+```bash
+grep -r "TODO\|FIXME\|HACK\|XXX" src/ lib/ app/ --include="*.ts" --include="*.tsx" --include="*.py" --include="*.js" 2>/dev/null | head -20
+```
+
+审查 design.md「文件变更」中列出的文件：安全问题（输入校验、SQL拼接、硬编码敏感信息）、潜在 bug（空值、边界条件）、与 CONVENTIONS.md 一致性。每个问题标 🔴必须 / 🟡建议 / 🔵优化。
+
+### 5.5 MCP 基础设施验证
+
+检测已配置的 MCP 服务，利用它们做实际验证（不只查文档）：
+
+**MCP 能力检测：**
+
+不要只检查配置文件路径（不同客户端配置位置不同），直接检查当前可用工具列表中是否存在以下工具：
+
+- 数据库相关工具（包含 postgres/sqlite/mysql/redis 关键词）
+- 浏览器相关工具（包含 browser/chrome/puppeteer/playwright/devtools 关键词）
+- 搜索相关工具（包含 search/web_search 关键词）
+
+**判断方式：** 尝试调用或列出当前可用的 MCP 工具，有就用来验证，没有就跳过。
+
+**按检测结果执行对应验证：**
+
+**数据库 MCP（postgres/sqlite/mysql/redis）：**
+- 对照 design.md 中的数据模型，验证表/集合是否存在
+- 验证字段类型、约束（主键、外键、唯一索引）是否与设计一致
+- 验证新增的 API 是否能正确读写对应数据
+- ⚠️ 只执行 SELECT 查询，禁止任何写操作
+
+**浏览器 MCP（chrome-devtools/puppeteer/playwright）：**
+- 验证页面能否正常加载（无 404/500 错误）
+- 验证关键 UI 元素是否存在（导航、表单、按钮等）
+- 验证基础交互（点击、提交、跳转）
+
+**API MCP：**
+- 验证新增接口是否可达
+- 验证请求/响应格式是否与设计一致
+
+**无 MCP → 跳过此步骤，不影响验证结论。**
+
+将验证结果纳入验证报告。
+
+### 6. Lint / Format 检查
+
+自动检测并运行项目配置的 lint/format 工具，验证代码是否符合规范：
+
+```bash
+# ESLint
+if [ -f .eslintrc -o -f .eslintrc.js -o -f .eslintrc.cjs -o -f .eslintrc.json -o -f .eslintrc.yml ] || grep -q '"eslint"' package.json 2>/dev/null; then
+  echo "=== ESLint ==="
+  npx eslint . --max-warnings 0 2>&1 | tail -50
+fi
+
+# Prettier（检查而非修复）
+if [ -f .prettierrc -o -f .prettierrc.js -o -f .prettierrc.json -o -f .prettierrc.yml ] || grep -q '"prettier"' package.json 2>/dev/null; then
+  echo "=== Prettier ==="
+  npx prettier --check . 2>&1 | tail -30
+fi
+
+# TypeScript 类型检查
+if [ -f tsconfig.json ]; then
+  echo "=== TypeScript ==="
+  npx tsc --noEmit 2>&1 | tail -30
+fi
+
+# Stylelint
+if [ -f .stylelintrc -o -f .stylelintrc.js -o -f .stylelintrc.json ] || grep -q '"stylelint"' package.json 2>/dev/null; then
+  echo "=== Stylelint ==="
+  npx stylelint "**/*.{css,scss,less}" 2>&1 | tail -30
+fi
+```
+
+**处理策略（AskUserQuestion）：**
+1. **自动修复** — 对支持 `--fix` 的工具（ESLint、Prettier、Stylelint）自动修复后重跑检查，同一问题最多修复 3 次
+2. **只报告** — 仅列出所有 lint 错误，不修改代码
+
+将 lint 结果纳入验证报告（步骤 7）。
+
+### 7. 输出验证报告
+
+```markdown
+# SillySpec 验证报告
+## 任务完成度：X/Y
+## 设计一致性
+## 测试结果：passed N, failed N
+## 技术债务标记
+## 代码审查：🔴 N / 🟡 N / 🔵 N
+## Lint 检查：ESLint ✅/❌ | Prettier ✅/❌ | TypeScript ✅/❌ | Stylelint ✅/❌
+## MCP 基础设施验证：数据库 ✅/❌/跳过 | 页面 ✅/❌/跳过 | API ✅/❌/跳过
+## E2E 测试：passed N / failed N / fixAttempts 详情
+## 结论：✅ PASS / ⚠️ PASS WITH NOTES / ❌ FAIL
+```
+
+### 7. 完成
+
+更新 `.sillyspec/STATE.md`（如存在）：阶段改为 `verify ✅` 或 `verify ⚠️`，记录精确到秒的时间戳。

package/templates/workspace-sync.md

@@ -0,0 +1,99 @@
+## 交互规范
+**当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项以参数传入。**
+
+## 核心约束（必须遵守）
+- ❌ 修改子项目的代码
+- ❌ 删除已有文件（clone 前必须确认）
+- ❌ 跳过冲突检查直接覆盖
+
+## 流程
+
+### Step 1: 读取配置
+
+```bash
+ls .sillyspec/projects/*.yaml 2>/dev/null | grep -q .
+```
+
+无子项目配置 → 提示先执行 `/sillyspec:workspace` 初始化工作区。
+
+### Step 2: 逐个子项目检查
+
+对每个子项目配置文件，按顺序执行：
+
+```bash
+for f in .sillyspec/projects/*.yaml; do
+  [ -f "$f" ] || continue
+  proj_name=$(basename "$f" .yaml)
+  proj_path=$(grep '^path:' "$f" | head -1 | sed 's/^path:[[:space:]]*//')
+  proj_repo=$(grep '^repo:' "$f" | head -1 | sed 's/^repo:[[:space:]]*//')
+  # ... 检查逻辑
+done
+```
+
+```bash
+# 检查目录是否存在
+ls -d <path> 2>/dev/null && echo "EXISTS" || echo "MISSING"
+```
+
+#### 情况 A：目录不存在
+
+```bash
+# 检查是否有 repo 配置
+grep '^repo:' .sillyspec/projects/<name>.yaml
+```
+
+- **有 repo** → AskUserQuestion："子项目 `<name>` 不存在，是否从 `<repo>` clone 到 `<path>`？"
+  - 用户确认 → `git clone <repo> <path>` → ✅ 成功
+  - clone 失败 → ❌ 报错，提示用户手动 clone
+- **无 repo** → ⚠️ 提示用户："子项目 `<name>` 不存在且无 repo 配置，请手动放置到 `<path>`"
+
+#### 情况 B：目录已存在
+
+```bash
+# 检查是否是 git 仓库
+git -C <path> rev-parse --is-inside-work-tree 2>/dev/null
+
+# 如果是，检查 remote 是否匹配
+git -C <path> remote get-url origin 2>/dev/null
+```
+
+- **不是 git 仓库** → AskUserQuestion："目录 `<path>` 存在但不是 git 仓库，可能和其他项目冲突。"
+  - 跳过此子项目
+  - 让用户指定正确路径
+- **是 git 仓库，remote 匹配 repo** → ✅ 跳过，状态正常
+- **是 git 仓库，remote 不匹配 repo** → ⚠️ AskUserQuestion：
+  - "目录 `<path>` 是 git 仓库但 remote 不匹配（期望 `<repo>`，实际 `<actual>`）。可能是不同项目。"
+  - 跳过 / 用户确认覆盖
+
+#### 情况 C：路径冲突
+
+检查两个子项目的 path 是否指向同一目录或互相包含：
+
+```bash
+# 将相对路径转为绝对路径后比较
+realpath <path1>
+realpath <path2>
+```
+
+冲突 → ❌ 报错："子项目 A 和 B 的路径冲突，请修改对应的 projects/*.yaml"
+
+### Step 3: 汇总报告
+
+```
+📊 工作区同步结果
+
+┌───────────────────┬──────────┬────────────────────────────────────┐
+│ 子项目            │ 状态     │ 说明                               │
+├───────────────────┼──────────┼────────────────────────────────────┤
+│ back-service      │ ✅ 正常   │ 目录存在，git remote 匹配         │
+│ sub-grid-security │ 🔄 已克隆 │ 从 https://... clone 成功         │
+│ frontend          │ ⚠️ 缺失   │ 无 repo 配置，请手动放置           │
+└───────────────────┴──────────┴────────────────────────────────────┘
+```
+
+全部正常 → 提示 `/sillyspec:brainstorm '你的需求'` 继续。
+有异常 → 提示用户处理后再 sync。
+
+### Step 4: 更新子项目配置
+
+如果 clone 过程中实际 remote 和 `projects/<name>.yaml` 中的 repo 不一致，更新对应 yaml 文件的 repo 字段为实际值。

package/templates/workspace.md

@@ -0,0 +1,70 @@
+## 交互规范
+**当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项以参数传入。**
+
+## 核心约束（必须遵守）
+- ❌ 修改子项目目录下的任何文件
+- ❌ 写非法 YAML
+- ❌ 使用绝对路径（必须是相对路径）
+
+## 用户指令
+$ARGUMENTS
+
+---
+
+## 流程
+
+### Step 1: 检查配置
+
+```bash
+ls .sillyspec/projects/*.yaml 2>/dev/null | grep -q .
+```
+
+不存在 → 询问是否初始化工作区。
+
+### Step 2: 解析指令
+
+- 无参数 / `status` → 显示状态
+- `add` → 添加子项目
+
+**添加流程：**
+1. AskUserQuestion 询问子项目名称、目录路径、角色描述
+2. **自动检测 git 远程地址：**
+```bash
+git -C <path> remote get-url origin 2>/dev/null
+```
+检测到则写入 repo 字段，检测不到则留空
+3. 创建 `.sillyspec/projects/<name>.yaml` 文件
+- `remove` → 删除 `.sillyspec/projects/<name>.yaml` 文件
+- `sync` → 同步子项目（clone 缺失的，检查冲突）
+
+### Step 3: 执行操作
+
+**初始化工作区：** 询问名称 → 逐个添加子项目（名称、路径、角色描述，验证路径存在）→ 共享规范 → 创建 `projects/*.yaml` + `.sillyspec/shared/`
+
+**添加/移除子项目：** 创建或删除 `projects/<name>.yaml`，Git 提交。
+
+**状态显示：** 读取每个子项目的 `.sillyspec/` 内容（PROJECT.md、docs/<project>/scan/ 文档数、进行中变更），输出格式：
+
+```
+🏢 工作区：<name>
+📦 子项目（N 个）：
+  ✅ frontend  ./frontend    前端 - Vue3+TS    已扫描（7 份文档）
+  ⚠️ backend   ./backend     后端 - Node.js     已初始化（未扫描）
+📄 共享规范：2 份
+💡 操作：/sillyspec:workspace add | /sillyspec:init | /sillyspec:scan
+```
+
+### 读取子项目信息
+
+```bash
+for f in .sillyspec/projects/*.yaml; do
+  [ -f "$f" ] || continue
+  proj_name=$(basename "$f" .yaml)
+  proj_path=$(grep '^path:' "$f" | head -1 | sed 's/^path:[[:space:]]*//')
+  proj_role=$(grep '^role:' "$f" | head -1 | sed 's/^role:[[:space:]]*//')
+  proj_repo=$(grep '^repo:' "$f" | head -1 | sed 's/^repo:[[:space:]]*//')
+  # 检查文档数、变更数等
+  doc_count=$(ls "$proj_path"/.sillyspec/docs/$proj_name/scan/*.md 2>/dev/null | wc -l)
+  echo "  $proj_name  $proj_path    $proj_role    docs:$doc_count"
+done
+```

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

@@ -1,17 +0,0 @@
----
-name: sillyspec:archive
-description: 归档变更 — 规范沉淀，可追溯
----
-
-## 执行
-
-**你必须使用 exec 工具（shell）执行以下命令，不要自己编造流程：**
-
-1. 运行 `sillyspec run archive` — 读取输出的步骤 prompt
-2. 按照输出的 prompt **严格执行**，不要跳过或自行添加步骤
-3. 步骤完成后，运行 `sillyspec run archive --done --output "你的摘要"`
-4. 重复 2-3 直到阶段完成
-5. **禁止**在没有运行 CLI 的情况下自行决定流程
-
-## 用户指令
-$ARGUMENTS

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

@@ -1,77 +0,0 @@
----
-description: 自动模式 — 全流程自动推进（通用版）
-argument-hint: "<需求描述>"
----
-
-## 用法
-- /sillyspec:auto 实现用户登录功能
-- /sillyspec:auto 修复搜索结果的排序问题
-
-## 任务
-$ARGUMENTS
-
----
-
-## 执行流程
-
-你是全流程编排器，按 brainstorm → plan → execute → verify 顺序自动推进。
-
-### 启动
-1. 运行 `sillyspec run auto --input "<用户需求>"`
-2. 读取 CLI 输出的 step prompt（包含你的角色描述）
-3. 执行 prompt 中的操作
-
-### 步骤循环
-重复以下循环直到 CLI 输出"全部流程已完成"：
-
-1. **读取 CLI 输出的 step prompt**
-2. **判断是否需要用户确认：**
-   - prompt 中包含"请用户选择""等待用户回答""展示给用户""用户确认" → **暂停，等用户回复**
-   - 纯内部操作 → **直接执行**
-3. **执行 prompt 要求的操作**
-4. **完成后运行** `sillyspec run auto --done --output "<你的摘要>"`
-5. **读取 CLI 输出的下一步 prompt**，回到步骤 1
-
-### 阶段审核门控
-
-**brainstorm 完成后：**
-评估需求复杂度（参考 brainstorm Step 5 的判断结果），根据复杂度决定：
-
-| 复杂度 | 审核策略 |
-|--------|---------|
-| 简单（无拆分、无批量） | 不审核，直接进入 plan |
-| 中等（有拆分或批量） | 启动 1 个审核子代理（QA 视角）审查 design.md |
-| 复杂（拆分 + 批量/多角色） | 启动 2-3 个审核子代理多角度审查 |
-
-多角度审核子代理分工：
-- **架构师** — 审查设计合理性、技术选型 trade-off、模块划分
-- **安全专家** — 审查安全隐患、权限设计、数据校验
-- **QA 专家** — 审查需求覆盖率、边界场景遗漏、验收标准
-
-审核流程：
-1. 暂停，提示用户当前复杂度等级和建议审核策略
-2. 用户确认后，启动审核子代理（读取 design.md + requirements.md + tasks.md）
-3. 子代理输出问题清单
-4. 汇总问题，询问用户"是否需要修改后再继续"
-5. 需要修改 → 修复后重新审核；不需要 → 进入下一阶段
-
-**plan 完成后：**
-同样评估复杂度，启动审核子代理审查 plan.md：
-- **项目经理** — 审查任务拆解粒度、依赖关系、优先级
-- **工程师** — 审查任务可行性、工作量评估是否合理
-- **QA** — 审查验收标准是否具体可测试
-
-### 关键规则
-- 不要跳过任何步骤
-- 不要手动修改 progress.json
-- 不要自动 commit，只 git add
-- 不要使用 npx
-- 不要编造不存在的 CLI 子命令
-- 遇到命令报错 → 展示错误，暂停等用户介入
-
-### 异常处理
-- 命令执行失败 → 展示错误信息，暂停等待用户指示
-- 用户说"停止"或"暂停" → 立即停止，报告当前进度
-
-### 完成条件
-CLI 输出"全部流程已完成"后，输出完整流程总结，提示用户提交改动。

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

@@ -1,17 +0,0 @@
----
-name: sillyspec:brainstorm
-description: 需求探索 — 结构化头脑风暴，含技术方案输出（创建性工作前必用）
----
-
-## 执行
-
-**你必须使用 exec 工具（shell）执行以下命令，不要自己编造流程：**
-
-1. 运行 `sillyspec run brainstorm` — 读取输出的步骤 prompt
-2. 按照输出的 prompt **严格执行**，不要跳过或自行添加步骤
-3. 步骤完成后，运行 `sillyspec run brainstorm --done --output "你的摘要"`
-4. 重复 2-3 直到阶段完成
-5. **禁止**在没有运行 CLI 的情况下自行决定流程
-
-## 用户指令
-$ARGUMENTS

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

@@ -1,44 +0,0 @@
----
-name: sillyspec:continue
-description: 自动判断并执行下一步
----
-
----
-
-你现在是 SillySpec 的自动推进器。
-
-## 判断逻辑
-
-按顺序检查，第一个未完成的就执行：
-
-```
-1. 有 HANDOFF.json？→ 执行 /sillyspec:resume
-
-2. .sillyspec/changes/ 有进行中的变更？
-   2a. 没有任何文件 → 提示检查 proposal 是否需要完善
-   2b. 没有 design.md → 提示补充 design
-   2c. 没有 tasks.md → 执行 /sillyspec:propose（补全规范）
-   2d. tasks.md 有未完成项 + 有计划文件 → 执行 /sillyspec:execute
-   2e. tasks.md 全完成 + 没验证 → 执行 /sillyspec:verify
-   2f. 已验证通过 → 执行 /sillyspec:archive
-
-3. 有设计文档但没有对应变更？
-   → 提示运行 /sillyspec:propose <name>
-
-4. 有 docs/*/scan/ 但没有进行中的工作？
-   → 提示运行 /sillyspec:brainstorm "你的想法"
-
-5. 什么都没有？
-   → 提示运行 /sillyspec:init（新项目）或 /sillyspec:scan（棕地项目）
-```
-
-## 输出
-
-先报告检测结果，再执行：
-
-> 🤖 SillySpec 自动检测
-> 
-> 当前状态：[描述]
-> 下一步：[执行的命令]
-> 
-> [开始执行...]

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

@@ -1,22 +0,0 @@
----
-name: sillyspec:doctor
-description: 项目自检 — 检查 CLI、配置、构建环境和外部依赖
----
-
-## 前置检查
-
-**在执行任何检查之前，先确认 SillySpec CLI 是否可用：**
-
-1. 运行 `sillyspec --version`
-2. 如果失败：
-   - 输出：❌ SillySpec CLI 未安装
-   - 给出安装命令：`npm install -g sillyspec`
-   - 停止，不要继续后续步骤
-
-## 执行
-
-CLI 可用后，运行 `sillyspec run doctor`，按提示逐步执行。
-每步完成后运行 `sillyspec run doctor --done --output "摘要"`。
-
-## 用户指令
-$ARGUMENTS