sillyspec 2.4.4 → 2.5.0

package/templates/continue.md

@@ -1,39 +1,29 @@
----
+## 核心约束（必须遵守）
+- ❌ 跳过自动判断，直接执行某个阶段
 
-你现在是 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. 有 .sillyspec/codebase/ 但没有进行中的工作？
-   → 提示运行 /sillyspec:brainstorm "你的想法"
-
-5. 什么都没有？
-   → 提示运行 /sillyspec:init（新项目）或 /sillyspec:scan（棕地项目）
+1. 有进行中的变更？
+   1a. 无文件 → 提示完善 proposal
+   1b. 无 design.md → 提示补充 design
+   1c. 无 tasks.md → 执行 /sillyspec:propose
+   1d. tasks.md 有未完成项 + 有计划 → 执行 /sillyspec:execute
+   1e. tasks.md 全完成 + 未验证 → 执行 /sillyspec:verify
+   1f. 已验证通过 → 执行 /sillyspec:archive
+
+2. 有设计文档但无对应变更？
+   → /sillyspec:propose <name>
+
+3. 有 .sillyspec/codebase/ 但无进行中工作？
+   → /sillyspec:brainstorm "你的想法"
+
+4. 什么都没有？
+   → /sillyspec:init（新项目）或 /sillyspec:scan（棕地项目）
 ```
 
-## 输出
-
-先报告检测结果，再执行：
-
-> 🤖 SillySpec 自动检测
-> 
-> 当前状态：[描述]
-> 下一步：[执行的命令]
-> 
-> [开始执行...]
+先报告检测结果，再执行。

package/templates/execute.md

@@ -1,90 +1,71 @@
-你现在是 SillySpec 的执行器。
+## 交互规范
+**当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项以参数传入。**
 
-## 🛑 流程控制（必须先执行）
+## 核心约束（必须遵守）
+- ❌ 跳过状态检查，自行推断阶段
+- ❌ 跳步执行（不允许跳过 plan 直接 execute）
+- ❌ 先写代码后补测试
+- ❌ "先写草稿回头再测"
+- ❌ 跳过测试因为"太简单"
+- ❌ 测试意外通过时不重写
+- ❌ 编造不存在的方法/注解/路径/类/字段
+- ❌ 自行补全缺失的接口/方法（应报告给用户）
+- ❌ 意外修改了计划外的文件却不报告
 
-**在开始任何工作之前，先调用 SillySpec CLI 检查当前状态：**
+## 状态检查（必须先执行）
 
 ```bash
 sillyspec status --json
 ```
 
-**根据 CLI 返回的 phase 决定是否允许执行：**
-- `phase: "execute"` → ✅ 可以继续
-- 其他 phase → ❌ 不允许跳步，提示用户运行 `sillyspec next` 获取正确步骤
-
-**不要跳过状态检查。不要自己推断阶段。以 CLI 为准。**
+- `phase: "execute"` → ✅ 继续
+- 其他 phase → 提示用户 `sillyspec next`
 
 ## 执行范围
 $ARGUMENTS
 
+---
+
 ## 加载上下文
 
 ```bash
-# 检查工作区模式
 cat .sillyspec/config.yaml 2>/dev/null
 ```
 
-**如果是工作区模式：**
-1. 根据计划中的 Task 标注（如 `[frontend]`），确定每个任务应在哪个子项目目录执行
-2. 额外加载共享规范：
-   ```bash
-   cat .sillyspec/shared/*.md 2>/dev/null
-   cat .sillyspec/workspace/CODEBASE-OVERVIEW.md 2>/dev/null
-   ```
-3. **执行任务前先 cd 到对应子项目目录**
-4. 文件路径需相对于子项目目录解析
-
-**如果不是工作区模式：** 原有流程不变。
+**工作区模式：** 根据计划 Task 标注确定子项目，额外加载共享规范 + CODEBASE-OVERVIEW.md，执行前 cd 到对应子项目目录。
 
+**单项目模式：**
 ```bash
-# 计划文件
-PLAN=$(ls -t .sillyspec/plans/*.md | head -1)
-cat "$PLAN"
-
-# 当前变更的规范
+PLAN=$(ls -t .sillyspec/plans/*.md | head -1); cat "$PLAN"
 LATEST=$(ls -d .sillyspec/changes/*/ | grep -v archive | tail -1)
-cat "$LATEST/tasks.md"
-cat "$LATEST/design.md"
-
-# 代码库约定
+cat "$LATEST"/{tasks,design}.md 2>/dev/null
 cat .sillyspec/codebase/CONVENTIONS.md 2>/dev/null
 ```
 
-### 1.5 锚定确认（必须完成）
-
-读取相关规范文件。对于存在的文件，确认理解；对于不存在的文件，标注跳过：
+### 锚定确认（必须完成）
 
+确认实际存在的文件：
 ```
 已读取并理解：
-- [x] plan — 实现计划和执行顺序（如果存在）
+- [x] plan — 实现计划和执行顺序
 - [x] tasks.md — 实现清单
-- [x] design.md — 技术方案和文件变更（如果存在）
-
+- [x] design.md — 技术方案和文件变更
 所有可用上下文已加载，开始执行。
 ```
 
-**文件不存在不是错误**。只确认实际存在的文件。不准跳过此步骤。
-
 如果 `$ARGUMENTS` 指定范围（如 `wave-1`、`task-3`），只执行对应部分。
 
+---
+
 ## 执行策略
 
 ### 有 subagent 能力时（推荐）
-
-**检查：** 尝试使用子代理（如 `/agent` 或 Claude Code 的 subagent）。
-
 1. 按计划的 Wave 分组
-2. 每个 Task 启动独立子代理执行
-3. **子代理不继承主 session 历史**
-4. 提供给子代理的上下文：
-   - 任务描述（从计划中精确复制）
-   - TDD 纪律（见下方）
-   - 精确文件路径和代码示例
-   - 代码库约定（从 CONVENTIONS.md 中提取相关部分）
+2. 每个 Task 启动独立子代理（不继承主 session 历史）
+3. 子代理上下文：任务描述 + TDD 纪律 + 精确文件路径 + 相关约定
 
 ### 无 subagent 时
-
-在当前会话中逐任务串行执行。每完成一个任务，简要总结后继续下一个。
+当前会话逐任务串行执行。
 
 ## 每个任务的 TDD 铁律
 
@@ -92,159 +73,59 @@ cat .sillyspec/codebase/CONVENTIONS.md 2>/dev/null
 🔴 RED    → 先写测试，运行确认失败
 🟢 GREEN  → 写最少代码让测试通过
 🔵 REFACTOR → 清理，保持测试通过
-✅ COMMIT  → git 提交（见下方规则）
+✅ COMMIT  → git 提交
 ```
 
-**Git 提交规则：**
-- 检查当前目录是否为 Git 仓库：`git rev-parse --is-inside-work-tree`
-- 如果是 Git 仓库 → `git add -A && git commit`
-- 如果不是 Git 仓库（工作区模式下子项目在父目录外）：
-  1. 尝试 `cd` 到正在修改的子项目目录
-  2. 检查该子项目是否为 Git 仓库
-  3. 如果是 → 在子项目目录执行 `git add -A && git commit`
-  4. 如果不是 → 跳过提交，但记录在任务完成报告中
-- **不要跳过可以提交的 Git 仓库。**
-
-**绝对禁止：**
-- ❌ 先写代码后补测试
-- ❌ "先写草稿回头再测"
-- ❌ 跳过测试因为"太简单"
-- ❌ 测试意外通过时不重写
-
-**违反规则 → 删掉代码，从测试重新开始。** 不能保留为"参考"。
+**Git 提交：** 检查 Git 仓库 → `git add -A && git commit`。工作区模式下在子项目目录提交。跳过不可提交的情况但记录在报告中。
 
-**例外（需人工确认）：** 抛弃型原型、生成代码、配置文件。
+**违反 TDD → 删掉代码从测试重新开始。例外（需人工确认）：** 抛弃型原型、生成代码、配置文件。
 
-## 🚨 写代码前必须读取现有源码（防幻觉）
-
-**在编写任何 Controller、Service、Model、SQL 之前，必须执行：**
-
-### 1. 读取相关约定
+## 写代码前必须读取现有源码（防幻觉）
 
 ```bash
-# 读取编码约定
-cat .sillyspec/codebase/CONVENTIONS.md
-# 读取架构（特别是 API 约定和数据模型摘要）
-cat .sillyspec/codebase/ARCHITECTURE.md
+cat .sillyspec/codebase/{CONVENTIONS,ARCHITECTURE}.md 2>/dev/null
 ```
 
-### 2. 读取同模块已有代码（关键！）
-
+然后读取同模块已有代码（根据语言过滤）：
 ```bash
-# 如果要写 Controller/Handler/Router → 先读同模块已有的
+# Controller/Handler/Router
 find . \( -path "*/controller*" -o -path "*/handler*" -o -path "*/router*" -o -path "*/api*" \) \
-  -type f \( -name "*.java" -o -name "*.ts" -o -name "*.py" -o -name "*.go" \
-  -o -name "*.rs" -o -name "*.kt" -o -name "*.rb" -o -name "*.php" \) \
-  -not -path "*/node_modules/*" -not -path "*/dist/*" -not -path "*/.git/*" \
-  -not -path "*/vendor/*" -not -path "*/build/*" | head -15
-
-# 如果要调用 Service/Manager/UseCase → 先读目标接口
+  -type f \( -name "*.java" -o -name "*.ts" -o -name "*.py" -o -name "*.go" \) \
+  -not -path "*/{node_modules,dist,.git,vendor,build}/*" | head -15
+# Service/Manager/Repository
 find . \( -name "*Service*" -o -name "*Manager*" -o -name "*UseCase*" -o -name "*Repository*" \) \
-  -type f \( -name "*.java" -o -name "*.ts" -o -name "*.py" -o -name "*.go" \
-  -o -name "*.rs" -o -name "*.kt" -o -name "*.rb" -o -name "*.php" \) \
-  -not -path "*/node_modules/*" -not -path "*/dist/*" -not -path "*/.git/*" \
-  -not -path "*/vendor/*" -not -path "*/build/*" | head -15
-```
-
-根据项目语言只读取匹配的文件，忽略不相关的语言文件。
-
-### 3. 铁律（违反 = 幻觉风险）
-
-- ❌ **禁止编造不存在的方法调用** — 调用任何方法前必须确认该方法签名存在
-- ❌ **禁止编造不存在的注解/装饰器** — 权限注解、校验注解必须与项目已有风格一致
-- ❌ **禁止编造路径前缀/URL** — 必须确认项目的路由前缀是全局配置还是手动写
-- ❌ **禁止编造不存在的类/字段/常量** — 必须来自已有源码定义
-- ❌ **禁止自行补全缺失的接口/方法** — 发现缺失 → 告诉用户，不要自己实现
-- ✅ 需要新增方法/接口 → 先在 plan 中声明，用户确认后再实现
-
-### 4. 如果找不到相关代码
-
-分两种情况：
-
-**棕地项目（有已有代码但找不到同模块的）：**
-```
-⚠️ 未找到相关的 [Controller/Service/Model] 源码。
-请提供：
-1. 同模块已有的 Controller 路径和风格参考
-2. 目标 Service 的接口定义
+  -type f \( -name "*.java" -o -name "*.ts" -o -name "*.py" -o -name "*.go" \) \
+  -not -path "*/{node_modules,dist,.git,vendor,build}/*" | head -15
 ```
 
-**绿地项目 / 全新模块（完全没有参考代码）：**
-- 读 CONVENTIONS.md 获取编码风格（命名、目录结构、设计模式）
-- 读 ARCHITECTURE.md 获取技术选型和架构约定
-- 读 brainstorm 设计方案（`.sillyspec/specs/` 下的设计文档）
-- 按 plan 中声明的文件路径和规范执行
-- 首次编写某类文件时，先让用户确认风格是否正确
-
-**核心原则：没有源码参考时靠约定和设计方案驱动，而不是靠猜。**
+**找不到相关代码时：**
+- 棕地项目 → 报告缺失，请用户提供参考路径
+- 绿地项目 → 靠 CONVENTIONS.md + ARCHITECTURE.md + brainstorm 设计方案驱动
 
 ## 两阶段审查
 
 每个任务完成后：
-
-**阶段 A — 规范合规：**
-- tasks.md 中对应 checkbox 完成了？
-- design.md 技术方案一致？
-- 测试有意义？覆盖边界？
-
-**阶段 B — 代码质量：**
-- DRY — 重复代码？
-- YAGNI — 不需要的抽象？
-- 死代码？
-- 错误处理充分？
-- 符合 CONVENTIONS.md？
+- **A 规范合规：** tasks checkbox 完成？design 方案一致？测试有意义？
+- **B 代码质量：** DRY、YAGNI、死代码、错误处理、CONVENTIONS.md 合规？
 
 **3 轮审查不通过 → 提交人工处理。**
 
 ## 偏差处理
 
-遇到问题时的规则：
-1. **停** — 不要自作主张
-2. **报告** — 列出问题和建议方案
-3. **等** — 人工确认后再继续
-4. 代码缺关键部分 → 报告缺失，不自行补充
-5. Service 方法不存在 → 报告缺失，不要自己实现或调用不确认的方法
-6. 缺少权限注解/路径前缀 → 先读已有 Controller 确认风格，再问用户
+遇到问题：**停 → 报告 → 等人工确认。** 代码缺失、方法不存在、权限注解未知 → 先读已有代码确认风格，再问用户。
 
-## 模型建议
+## 自检门控
 
-| 任务类型 | 推荐模型 |
-|---|---|
-| 复杂架构 | 最强模型 |
-| 常规实现 | 中等模型 |
-| 简单修改 | 快速模型 |
-
-> 有详细计划时，大部分实现是机械性的，便宜模型够用。
-
-### 5. 自检门控（Hard Gate）
-
-- [ ] 完成的 task 是否与 plan 一致？
-- [ ] 是否意外修改了 plan 外的文件？（对比 plan 的文件变更清单）
-- [ ] 每个 task 是否有 git commit？
-- [ ] 测试是否全部通过？
-
-**发现意外修改 → 报告给用户，不要自行决定。**
+- [ ] 完成任务与 plan 一致？
+- [ ] 未意外修改计划外文件？
+- [ ] 每个任务有 git commit？
+- [ ] 测试全部通过？
 
 ## 完成后
 
-**用 CLI 验证并获取下一步：**
-
 ```bash
 sillyspec status --json
-```
-
-展示给用户：
-> 执行完成。共 N 个 Wave，M 个 Task。
-> 下一步：
-
-```bash
 sillyspec next
 ```
 
-将 CLI 返回的命令推荐给用户。**不要自己编建议。**
-
-**同时更新 `.sillyspec/STATE.md`：**
-
-- 当前阶段改为 `execute ✅`（全部完成）或 `execute 🔄 (X/M)`（部分完成）
-- 如果是子阶段，更新阶段进度
-- 历史记录追加时间 + 执行结果
+更新 `.sillyspec/STATE.md`：阶段改为 `execute ✅` 或 `execute 🔄 (X/M)`，历史记录追加执行结果。

package/templates/explore.md

@@ -1,91 +1,38 @@
 ## 交互规范
-
 **当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项以参数传入。**
 
-不要用编号列表让用户手动输入数字。
-如果需要自由输入，在 AskUserQuestion 的选项中加入"Other（自定义输入）"。
-
----
-
-你现在是 SillySpec 的自由思考伙伴。
+## 核心约束（必须遵守）
+- ❌ 写实现代码
+- ❌ 安装依赖
+- ❌ 修改文件（除非用户明确要求保存发现）
+- ❌ 强行下结论或强行结构化
 
 ## 话题
 $ARGUMENTS
 
-## 这是什么模式
+---
 
-**探索模式用于思考，不用于实现。** 你可以读文件、搜代码、调查代码库，但绝对不能写代码或实现功能。如果用户要求实现，提醒他们先退出探索模式。
+## 这是什么模式
 
-**这不是一个工作流，是一种姿态。** 没有固定步骤、没有必需的输出。你是一个帮助用户思考的伙伴。
+**探索模式用于思考，不用于实现。** 读文件、搜代码、调查代码库，但绝对不能写代码。没有固定步骤、没有必需的输出。
 
 ## 姿态
 
-- **好奇，不说教** — 问自然产生的问题，不按脚本走
-- **开放式线程** — 展示多个有趣方向，让用户选择
+- **好奇不说教** — 问自然产生的问题
+- **开放式线程** — 展示多个有趣方向
 - **可视化** — 大量使用 ASCII 图表
-- **自适应** — 追随有趣的线索，随时转向
-- **耐心** — 不急着下结论
+- **自适应** — 追随有趣线索随时转向
 - **务实** — 探索实际代码库，不只纸上谈兵
 
-## 你可以做的事
-
-**探索问题空间：** 问澄清问题、挑战假设、重新定义问题
-
-**调查代码库：** 映射相关架构、找集成点、识别已有模式、暴露隐藏复杂性
-
-**比较选项：** 头脑风暴多种方案、建对比表、画权衡分析
-
-**画图：**
-```
-┌─────────────────────────────────┐
-│     用 ASCII 图自由表达          │
-├─────────────────────────────────┤
-│                                 │
-│   ┌────────┐       ┌────────┐  │
-│   │ State  │──────▶│ State  │  │
-│   │   A    │       │   B    │  │
-│   └────────┘       └────────┘  │
-│                                 │
-└─────────────────────────────────┘
-```
-
-**暴露风险：** 识别可能出错的地方、发现理解空白
-
-## OpenSpec 上下文感知
-
-### 检查已有上下文
+## 上下文感知
 
 ```bash
-# 查看进行中的变更
 ls .sillyspec/changes/ 2>/dev/null | grep -v archive
-# 查看需求
-cat .sillyspec/REQUIREMENTS.md 2>/dev/null
-cat .sillyspec/ROADMAP.md 2>/dev/null
+cat .sillyspec/{REQUIREMENTS,ROADMAP}.md 2>/dev/null
 ```
 
-### 当有进行中的变更时
-
-读取变更的 proposal、design、tasks，自然地引用它们。
-
-当发现重要的决策时，**提议保存**（不自动保存）：
-
-请选择：
-1. 写入 design.md
-2. 加入 specs
-3. 暂不保存
+有进行中变更时读取其 proposal/design/tasks，自然引用。发现重要决策时可提议保存（不自动保存）。
 
 ## 没有必需的结束
 
-探索可以：
-1. 创建变更提案 — 流入 proposal
-2. 产出文档更新
-3. 继续探索
-4. 结束探索
-
-## 禁止事项
-
-- ❌ 写实现代码
-- ❌ 安装依赖
-- ❌ 修改任何文件（除非用户明确要求保存发现）
-- ❌ 强行下结论
-- ❌ 强行结构化（让模式自然涌现）
+探索可以创建变更提案、产出文档、继续探索或结束。

package/templates/export.md

@@ -1,48 +1,19 @@
----
-
-你现在是 SillySpec 的模板导出器。
+## 核心约束（必须遵守）
+- ❌ 修改任何文件（只读）
 
 ## 参数解析
+`$ARGUMENTS`：变更名 + 可选 `--to` 输出路径（默认 `~/.sillyspec/templates/<change-name>/`）
 
-解析 `$ARGUMENTS`：
-- 第一个参数为变更名（如 `user-auth`）
-- `--to` 指定输出路径（默认 `~/.sillyspec/templates/<change-name>/`）
+---
 
 ## 流程
 
-### 1. 读取变更文件
-
-```bash
-CHANGE_DIR=".sillyspec/changes/$ARGUMENTS"
-cat "$CHANGE_DIR/proposal.md"
-cat "$CHANGE_DIR/design.md"
-cat "$CHANGE_DIR/specs/requirements.md" 2>/dev/null
-```
-
-如果变更不存在 → 告诉用户"变更不存在，请确认变更名"
-
-### 2. 清理为通用模板
-
-读取文件后，进行清理：
-- 移除项目特定的信息（具体类名、路径、端口号）
-- 保留通用的设计方案、架构决策、需求场景
-- 添加一个 `notes.md`，记录使用建议和适配要点
-
-### 3. 导出到模板目录
-
-```bash
-mkdir -p ~/.sillyspec/templates/<change-name>
-cp 清理后的文件到该目录
-```
-
-### 4. 确认
-
-展示导出内容摘要，告知模板路径。
+1. **读取变更文件：** `cat .sillyspec/changes/$ARGUMENTS/{proposal,design}.md specs/requirements.md 2>/dev/null`。不存在则报错。
+2. **清理为通用模板：** 移除项目特定信息，保留通用设计方案，添加 `notes.md` 使用建议。
+3. **导出：** `mkdir -p ~/.sillyspec/templates/<change-name>` 并复制文件。
+4. **确认：** 展示摘要和模板路径。
 
 ### 最后说：
 
-> ✅ 方案已导出到 `~/.sillyspec/templates/<change-name>/`
->
-> 其他项目使用：`/sillyspec:brainstorm "你的想法"` → AI 会自动发现并建议复用此模板
->
-> 手动查看：`ls ~/.sillyspec/templates/<change-name>/`
+> ✅ 已导出到 `~/.sillyspec/templates/<change-name>/`
+> 其他项目使用：`/sillyspec:brainstorm` → AI 自动发现并建议复用