sillyspec 3.8.0 → 3.8.2

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

@@ -1,5 +1,5 @@
 ---
-description: 自动模式 — 专精子代理驱动全流程
+description: 自动模式 — 全流程自动推进（通用版）
 argument-hint: "<需求描述>"
 ---
 
@@ -12,117 +12,66 @@ $ARGUMENTS
 
 ---
 
-## 架构
-
-你是编排器，不亲自干活。每个阶段启动专精子代理执行，通过文件契约传递信息。
-
-## 阶段 personas
-
-### brainstorm — 资深架构师
-```
-你是一位有 15 年经验的系统架构师。
-思维模式：先理解业务本质，再设计技术方案。善于从模糊需求中提炼关键约束。
-关注点：系统边界、模块划分、扩展性、技术选型的 trade-off。
-沟通风格：直接、提问犀利、不给模糊方案。不确定就说不确定，不猜。
-输出习惯：决策要附理由，方案要列 trade-off，不用"可能""也许"。
-```
-
-### plan — 技术项目经理
-```
-你是一位经验丰富的技术项目经理。
-思维模式：任务拆解要粒度均匀（每个任务 1-2 小时可完成），依赖关系要明确。
-关注点：任务优先级、风险点、验证标准、里程碑。
-沟通风格：条理清晰，用 checkbox 和编号，不做模糊描述。
-输出习惯：每个任务有明确的完成标准，Wave 间有依赖说明。
-```
-
-### execute — 高级工程师
-```
-你是一位严谨的高级工程师。
-思维模式：先读规范再写代码，严格遵循 CONVENTIONS.md。代码要有清晰的职责划分。
-关注点：代码质量、边界处理、错误处理、命名规范。
-沟通风格：少说多做，遇到规范冲突优先问，不自作主张。
-输出习惯：每个函数有注释，改动要解释原因，测试要覆盖边界。
-```
-
-### verify — QA 专家
-```
-你是一位吹毛求疵的 QA 专家。
-思维模式：假设所有代码都有 bug，用最坏情况测试。关注边界、异常、并发。
-关注点：规范一致性、边界条件、回归风险、性能隐患。
-沟通风格：有问题直说，不放过任何可疑点，用证据说话。
-输出习惯：bug 要有复现步骤，验证要有具体标准，不写"看起来没问题"。
-```
-
 ## 执行流程
 
+你是全流程编排器，按 brainstorm → plan → execute → verify 顺序自动推进。
+
 ### 启动
 1. 运行 `sillyspec run auto --input "<用户需求>"`
-2. CLI 输出当前状态概览和第一步 prompt
+2. 读取 CLI 输出的 step prompt（包含你的角色描述）
+3. 执行 prompt 中的操作
 
-### 阶段循环
+### 步骤循环
+重复以下循环直到 CLI 输出"全部流程已完成"：
 
-按 brainstorm → plan → execute → verify 顺序，**每个阶段启动子代理**：
-
-1. 读取 CLI 输出的 step prompt
+1. **读取 CLI 输出的 step prompt**
 2. **判断是否需要用户确认：**
    - prompt 中包含"请用户选择""等待用户回答""展示给用户""用户确认" → **暂停，等用户回复**
-   - 纯内部操作 → **继续**
-3. 启动子代理执行（注入对应 persona + 当前 step prompt）
-4. 子代理完成后，运行 `sillyspec run auto --done --output "<摘要>"`
-5. 读取 CLI 输出的下一步 prompt
-6. 当前阶段所有 step 完成后，自动进入下一阶段，换 persona 启动新子代理
-
-### 子代理启动格式
-
-```
-## 你的角色
-{对应阶段的 persona}
-
-## 当前任务
-{sillyspec CLI 输出的 step prompt}
-
-## 项目上下文
-请先读取以下文件了解项目背景：
-- `.sillyspec/docs/<project>/scan/CONVENTIONS.md`
-- `.sillyspec/docs/<project>/scan/ARCHITECTURE.md`
-- `.sillyspec/changes/<变更名>/design.md`（如果存在）
-
-## 规则
+   - 纯内部操作 → **直接执行**
+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 子命令
-- 不要自动 commit，只 git add
-- 完成后汇报结果，不要自行推进下一步
-```
-
-## 子代理交互协议
-
-子代理遇到需要用户确认的问题时，**不要自己猜测**，输出以下标记后暂停：
-
-```
-### ❓ 需要用户确认
-**问题：** xxx
-**选项：** A) xxx  B) xxx  C) xxx
-**建议：** B（因为 xxx）
-```
-
-主代理（你）看到 ❓ 标记后：
-1. 暂停当前流程
-2. 把问题转发给用户
-3. 等用户回复
-4. 把用户回复发送给子代理（sessions_send），子代理继续执行
-
-### CLI prompt 中的用户确认点
-
-sillyspec CLI 的 step prompt 本身可能包含"请用户选择""等待用户回答"等要求。
-主代理（你）在把 prompt 发给子代理前，先扫描这些关键词。
-如果有 → 先自己处理（询问用户），拿到答案后再发给子代理。
-这样子代理不需要处理交互，只管干活。
+- 遇到命令报错 → 展示错误，暂停等用户介入
 
-## 异常处理
-- 命令执行失败 → 展示错误，暂停等用户介入
-- 用户说"停止"/"暂停" → 立即停止
-- 子代理失败 → 展示错误，可重试或跳过
+### 异常处理
+- 命令执行失败 → 展示错误信息，暂停等待用户指示
+- 用户说"停止"或"暂停" → 立即停止，报告当前进度
 
-## 完成条件
-CLI 输出"全部流程已完成"后，提示用户 `/sillyspec:commit` 提交改动
+### 完成条件
+CLI 输出"全部流程已完成"后，输出完整流程总结，提示用户提交改动。

package/README.md

@@ -8,6 +8,8 @@
 > Claude Code / Cursor / Codex / OpenCode / OpenClaw 都能用。
 >
 > 📖 **在线文档**：https://sillyspec.ppdmq.top/
+>
+> 💡 **核心理念：Code is Cheap, Context is Expensive.** 规范（Spec）才是核心资产，代码只是规范的衍生物。
 
 ## 安装
 

package/package.json

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

package/src/run.js

@@ -8,6 +8,7 @@ import { existsSync, readdirSync, mkdirSync, writeFileSync, appendFileSync, read
 import { ProgressManager } from './progress.js'
 import { stageRegistry, getNextStage, auxiliaryStages } from './stages/index.js'
 import { buildExecuteSteps } from './stages/execute.js'
+import { buildPlanSteps } from './stages/plan.js'
 
 /**
  * 获取阶段的步骤定义（execute 需要动态构建）
@@ -49,6 +50,19 @@ async function getStageSteps(stageName, cwd, progress) {
     }
     return buildExecuteSteps(planFile)
   }
+  if (stageName === 'plan') {
+    const changesDir = join(cwd, '.sillyspec', 'changes')
+    let changeDir = null
+    if (progress.currentChange) {
+      const target = join(changesDir, progress.currentChange)
+      if (existsSync(target)) changeDir = target
+    }
+    if (!changeDir && existsSync(changesDir)) {
+      const entries = readdirSync(changesDir, { withFileTypes: true }).filter(e => e.isDirectory() && e.name !== 'archive')
+      if (entries.length === 1) changeDir = join(changesDir, entries[0].name)
+    }
+    return buildPlanSteps(changeDir)
+  }
   const def = stageRegistry[stageName]
   return def ? def.steps : null
 }
@@ -101,9 +115,11 @@ function outputStep(stageName, stepIndex, steps, cwd) {
     plan: `### 📋 你的角色：技术项目经理
 你是一位经验丰富的技术项目经理。任务拆解粒度均匀，依赖关系明确。每个任务有完成标准，Wave 间有依赖说明。条理清晰，不做模糊描述。`,
     execute: `### 💻 你的角色：高级工程师
-你是一位严谨的高级工程师。先读规范再写代码，严格遵循 CONVENTIONS.md。代码有清晰职责划分，边界处理完善。少说多做，遇到规范冲突优先问。`,
+你是一位严谨的高级工程师。先读规范再写代码，严格遵循 CONVENTIONS.md 和 plan.md。**你不是设计师，是执行者——按 plan 搬砖，禁止发散思维。** 发现 plan 不合理就停下来反馈，不要自己改方案。代码有清晰职责划分，边界处理完善。少说多做，遇到规范冲突优先问。`,
     verify: `### 🔍 你的角色：QA 专家
-你是一位吹毛求疵的 QA 专家。假设所有代码都有 bug，用最坏情况测试。关注边界、异常、并发。有问题直说，用证据说话，不写"看起来没问题"。`
+你是一位吹毛求疵的 QA 专家。假设所有代码都有 bug，用最坏情况测试。关注边界、异常、并发。有问题直说，用证据说话，不写"看起来没问题"。`,
+    quick: `### 💻 你的角色：全栈老兵
+你是一位实战经验丰富的全栈工程师。不纠结架构和流程，理解需求就直接干。不确定的地方先问清楚再动手，先读后写，改完就收。问题排查思路开阔，前端报错不一定是前端问题——可能是后端数据、浏览器兼容、甚至设备硬件。解决方案实用接地气，用户描述有误敢于直接指出。`
   }
 
   console.log(`---`)
@@ -335,6 +351,31 @@ async function completeStep(pm, progress, stageName, cwd, outputText, inputText
   }
 
   // 检查是否还有下一步
+  // plan 阶段 Step 4（展开任务）完成后，动态追加 task 蓝图步骤
+  if (stageName === 'plan' && currentIdx === 3 && progress.currentChange) {
+    const planFile = join(cwd, '.sillyspec', 'changes', progress.currentChange, 'plan.md')
+    if (existsSync(planFile)) {
+      const planContent = readFileSync(planFile, 'utf8')
+      const { buildPlanSteps } = await import('./stages/plan.js')
+      const fullSteps = buildPlanSteps(join(cwd, '.sillyspec', 'changes', progress.currentChange), planContent)
+      // fullSteps[0..4] = fixedPrefix, fullSteps[-2..-1] = fixedSuffix
+      // 中间的是 task 蓝图步骤，插入到当前 steps 中
+      // 当前 steps 已有 5 个 fixedPrefix，找到需要插入的 task 步骤
+      const taskSteps = fullSteps.slice(5, -2) // 排除 5 个前缀和 2 个后缀
+      if (taskSteps.length > 0) {
+        // 插入审查一致性 + 保存步骤（后缀）
+        const suffixSteps = fullSteps.slice(-2)
+        for (const ts of taskSteps) {
+          steps.push({ name: ts.name, status: 'pending', prompt: ts.prompt, outputHint: ts.outputHint, optional: false })
+        }
+        for (const ss of suffixSteps) {
+          steps.push({ name: ss.name, status: 'pending', prompt: ss.prompt, outputHint: ss.outputHint, optional: false })
+        }
+        // 重新查找下一步
+      }
+    }
+  }
+
   const nextPendingIdx = steps.findIndex(s => s.status === 'pending')
 
   if (nextPendingIdx === -1) {

package/src/stages/execute.js

@@ -1,4 +1,5 @@
 import { existsSync, readFileSync } from 'fs'
+import path from 'path'
 
 export const definition = {
   name: 'execute',
@@ -167,10 +168,14 @@ function parseWavesFromPlan(planContent) {
 /**
  * 为 Wave 生成 prompt
  */
-function buildWavePrompt(wave, waveIndex) {
-  const taskList = wave.tasks.map(t => {
+function buildWavePrompt(wave, waveIndex, changeDir) {
+  const taskList = wave.tasks.map((t, ti) => {
+    const taskNum = String(t.index || (ti + 1)).padStart(2, '0')
+    const taskFile = changeDir ? `${changeDir}/tasks/task-${taskNum}.md` : ''
     let s = `- [ ] ${t.name}`
     if (t.file) s += ` (${t.file})`
+    if (taskFile) s += `
+  📋 **执行前必须读取任务蓝图：\`cat ${taskFile}\`**`
     if (t.reference) s += `\n  参考: ${t.reference}`
     if (t.steps) s += `\n  步骤: ${t.steps}`
     return s
@@ -181,6 +186,10 @@ function buildWavePrompt(wave, waveIndex) {
 1. 读取 design.md 的「编码铁律」章节（如果存在），严格遵守
 2. 确认本 Wave 的输入/输出契约（前置 Wave 产出了什么，本 Wave 需要消费什么）
 3. 检查前置 Wave 的产出是否完整（文件是否存在、测试是否通过）
+4. **上下文分层加载**：
+   - 🔥 热上下文：design.md 编码铁律 + 当前 Wave 任务（必须加载）
+   - 🌡️ 温上下文：CONVENTIONS.md + ARCHITECTURE.md（需要时加载）
+   - ❄️ 冷上下文：其他变更的 design.md、历史 plan.md（不要主动加载，除非明确需要）
 
 ### 本 Wave 任务
 ${taskList}
@@ -188,6 +197,8 @@ ${taskList}
 ### 执行要求
 1. 按任务顺序执行，同一 Wave 内任务可并行
 2. 铁律：先读后写、grep 确认方法存在、不编造、TDD
+3. **禁止发散思维**：你是代码搬运工，严格按 plan 执行，不要自行发挥"更好的方案"。如果发现 plan 不合理，**停下来反馈**，不要自己改方案。问题归因：实现困难 → plan 没做好；plan 做不好 → design 有缺陷。链路可追溯，不要在中途偷偷修设计。
+4. **Reverse Sync**：发现 Bug 或实现与 design.md 不一致时，先检查是代码错了还是 design.md 有遗漏，有遗漏则先修 design.md 再修代码。design.md 是唯一 truth source。
 3. **不要频繁编译！** 编译很慢，只在以下情况运行：
    - 写了大量代码后需要验证语法正确性
    - 最后一个 Wave 完成后做一次全量编译验证
@@ -209,10 +220,13 @@ ${taskList}
  */
 export function buildExecuteSteps(planFilePath = null) {
   let waves
+  let changeDir = null
 
   if (planFilePath && existsSync(planFilePath)) {
     const planContent = readFileSync(planFilePath, 'utf8')
     waves = parseWavesFromPlan(planContent)
+    // 从 planFilePath 推导 changeDir: .sillyspec/changes/<name>/plan.md
+    changeDir = path.dirname(planFilePath)
   }
 
   // 如果没解析出 Wave，生成默认 3 个
@@ -225,7 +239,7 @@ export function buildExecuteSteps(planFilePath = null) {
 
   const waveSteps = waves.map((wave, i) => ({
     name: `Wave ${i + 1} 执行`,
-    prompt: buildWavePrompt(wave, i + 1),
+    prompt: buildWavePrompt(wave, i + 1, changeDir),
     outputHint: `Wave ${i + 1} 执行结果`,
     optional: false
   }))

package/src/stages/plan.js

@@ -1,11 +1,18 @@
+import { existsSync, readFileSync } from 'fs'
+import path from 'path'
+
 export const definition = {
   name: 'plan',
   title: '实现计划',
-  description: '编写实现计划 — 按 Wave 分组，TDD 步骤，精确到文件路径',
-  steps: [
-    {
-      name: '状态检查',
-      prompt: `检查当前状态，确认可以执行 plan。
+  description: '编写实现计划 — 按 Wave 分组，每个任务独立文档',
+  steps: null // 动态生成
+}
+
+// 固定前缀步骤
+const fixedPrefix = [
+  {
+    name: '状态检查',
+    prompt: `检查当前状态，确认可以执行 plan。
 
 ### 操作
 1. 运行 \`sillyspec progress show\`
@@ -13,12 +20,12 @@ export const definition = {
 
 ### 输出
 当前状态摘要`,
-      outputHint: '状态摘要',
-      optional: false
-    },
-    {
-      name: '加载上下文',
-      prompt: `加载所有规范文件和代码库上下文。
+    outputHint: '状态摘要',
+    optional: false
+  },
+  {
+    name: '加载上下文',
+    prompt: `加载所有规范文件和代码库上下文。
 
 ### 操作
 1. 读取 CODEBASE-OVERVIEW.md + 各子项目上下文
@@ -28,143 +35,225 @@ export const definition = {
 
 ### 输出
 已加载的文件清单`,
-      outputHint: '文件清单',
-      optional: false
-    },
-    {
-      name: '锚定确认',
-      prompt: `确认已读取的文件。
+    outputHint: '文件清单',
+    optional: false
+  },
+  {
+    name: '锚定确认',
+    prompt: `确认已读取的文件。
 
 ### 操作
 列出已读取的文件，标注存在/不存在。
 
 ### 输出
 文件加载确认清单`,
-      outputHint: '文件确认清单',
-      optional: false
-    },
-    {
-      name: '展开任务并分组',
-      prompt: `把 tasks.md 每个 checkbox 展开为任务描述，按 Wave 分组组织。
+    outputHint: '文件确认清单',
+    optional: false
+  },
+  {
+    name: '展开任务并分组',
+    prompt: `把 tasks.md 每个 checkbox 展开为任务描述，按 Wave 分组，产出 plan.md 总览。
 
-### 输出格式要求（必须严格遵守）
-
-每个 Task 必须保留 \`- [ ]\` checkbox，这是 execute 阶段勾选完成状态的依据。禁止写成纯文本列表。
-
-每个 Task 必须包含「步骤」字段，列出 TDD 执行顺序：
-1. 写测试 → 2. 运行确认失败 → 3. 写代码 → 4. 运行确认通过
-
-纯配置/数据/文档类任务可跳过 TDD，步骤简化为：1. 实现 → 2. 验证
+### plan.md 格式（轻量总览，PM 视角）
+\`\`\`markdown
+# 实现计划
 
-注意：不需要写精确方法签名和代码示例。方法签名和代码风格由 execute 阶段先读后写确认。plan 专注"做什么"和"执行顺序"。
+## Wave 1（并行，无依赖）
+- [ ] task-01: 添加用户创建接口
+- [ ] task-02: 添加角色创建接口
 
-### 示例
+## Wave 2（依赖 Wave 1）
+- [ ] task-03: 用户创建接口联调
 
-\`\`\`markdown
-### Wave 1（并行，无依赖）
-
-- [ ] 添加用户创建接口
-  - 修改: \`UserController.java\`、\`UserService.java\`
-  - 参考: \`RoleController.createRole\`
-  - 步骤:
-    1. 写测试 UserControllerTest.testCreateUser
-    2. 运行 <test-cmd> 确认失败
-    3. 写 UserController.createUser
-    4. 运行 <test-cmd> 确认通过
-
-- [ ] 添加角色创建接口
-  - 修改: \`RoleController.java\`
-  - 步骤:
-    1. 写测试 RoleControllerTest.testCreateRole
-    2. 运行 <test-cmd> 确认失败
-    3. 写 RoleController.createRole
-    4. 运行 <test-cmd> 确认通过
-
-### Wave 2（依赖 Wave 1）
-
-- [ ] 用户创建接口联调
-  - 修改: \`UserController.java\`
-  - 依赖: Wave 1 的用户创建接口 + 角色创建接口
-  - 步骤:
-    1. 写集成测试 UserControllerTest.testCreateUserIntegration
-    2. 运行 <test-cmd> 确认失败
-    3. 补充联调逻辑
-    4. 运行 <test-cmd> 确认通过
-
-### Wave 3（纯配置）
-
-- [ ] 配置用户创建接口路由
-  - 修改: \`application.yml\`
-  - 步骤:
-    1. 实现路由配置
-    2. 验证: 运行 <test-cmd> 确认通过
+## 全局验收标准
+- [ ] 所有单元测试通过
 \`\`\`
 
-### 每个 Task 必须包含
-- 精确文件路径（修改哪个文件）
-- 任务描述（做什么，一两句话说清楚）
-- 涉及已有类调用时，标注参考文件（如"参考 \`RoleController.createRole\`"）
-- 依赖关系（无依赖可省略）
-
-### 分组规则
-1. 分析 Task 间依赖
-2. 无依赖的 Task 归入同一 Wave（可并行）
-3. 有依赖的 Task 按顺序排列
-4. Wave 编号从 1 开始
+### 关键规则
+- plan.md 只放任务列表 + Wave 划分 + 全局验收标准，**不放实现细节**
+- 实现细节写到后续的 tasks/task-NN.md 中
+- 每个任务编号格式：task-01、task-02 ...
 
 ### 批量模式指引
-如果 design.md 或需求中包含批量特征（关键词：批量/模板/引擎/100个/50个/N个相似/Excel×数据），按以下原则规划：
-❌ 不要列出每个实例作为独立任务（不要写 100 个 checkbox）
-❌ 不要在 plan.md 中嵌入数据（Excel 内容、表单字段列表等）
-✅ 设计通用架构（引擎/模板/配置格式），Wave 1 聚焦架构
-✅ 数据转换用脚本完成（Excel → 配置文件），单独一个 Wave
+如果 design.md 或需求中包含批量特征（关键词：批量/模板/引擎/N个相似），按以下原则规划：
+❌ 不要列出每个实例作为独立任务
+❌ 不要在文档中嵌入数据
+✅ 设计通用架构，Wave 1 聚焦架构
+✅ 数据转换用脚本完成，单独一个 Wave
 ✅ 总任务数控制在 10 个以内
-✅ 在 design.md 中增加「编码铁律」章节（3-5 条不可违反的约束）
 
 ### 操作
 1. 读取 tasks.md 获取任务列表
 2. 读取 design.md 获取文件变更清单
-3. 逐个展开为详细任务描述
+3. 逐个展开为任务描述
 4. 分析依赖关系，按 Wave 分组
-5. 每个任务独立 \`git add\` 暂存，不 commit
+5. 保存到 \`.sillyspec/changes/<变更名>/plan.md\`
 
 ### 输出
-按 Wave 分组的完整计划`,
-      outputHint: 'Wave 分组计划',
-      optional: false
-    },
-    {
-      name: '自检门控',
-      prompt: `自检计划质量。
+plan.md 总览内容`,
+    outputHint: 'plan.md 总览',
+    optional: false
+  },
+  {
+    name: '自检总览',
+    prompt: `自检 plan.md 总览质量。
 
 ### 操作
 检查以下各项：
-- [ ] 每个 task 有 \`- [ ]\` checkbox
-- [ ] 每个 task 有精确文件路径
-- [ ] 代码类 task 有 TDD 步骤（写测试→确认失败→写代码→确认通过）
-- [ ] 配置/文档类 task 步骤简化为（实现→验证）
+- [ ] 每个 task 有编号（task-01、task-02 ...）
+- [ ] 每个 task 有 checkbox
 - [ ] 已标注 Wave 分组和依赖关系
-- [ ] plan 与 design.md 的文件变更清单一致
-- [ ] 没有写精确方法签名和代码示例
+- [ ] 有全局验收标准
+- [ ] 没有实现细节（接口定义、代码示例等不应该在 plan.md 里）
+- [ ] plan.md 与 design.md 的文件变更清单一致
 
 ### 输出
 自检通过/不通过`,
-      outputHint: '自检结果',
-      optional: false
-    },
-    {
-      name: '保存并更新进度',
-      prompt: `保存计划文件，更新进度。
+    outputHint: '自检结果',
+    optional: false
+  }
+]
+
+// 固定后缀步骤
+const fixedSuffix = [
+  {
+    name: '审查一致性',
+    prompt: `审查所有 task-N.md 的一致性。
 
 ### 操作
-1. 确认变更目录存在：\`mkdir -p .sillyspec/changes/<变更名>\`
-2. 保存到 \`.sillyspec/changes/<变更名>/plan.md\`
-3. \`git add .sillyspec/\` — **不要 commit**
+1. 读取所有 tasks/task-NN.md
+2. 检查：
+   - 文件路径有没有冲突（两个任务改同一个文件）
+   - 依赖关系和 plan.md 的 Wave 分组是否一致
+   - 验收标准和 plan.md 的全局标准是否矛盾
+   - 接口定义是否自洽
+3. 发现问题 → 列出问题清单，暂停等用户决定是否修复
 
 ### 输出
-计划文件路径 + 下一步命令`,
-      outputHint: '计划文件路径',
-      optional: false
+一致性审查结果`,
+    outputHint: '审查结果',
+    optional: false
+  },
+  {
+    name: '保存并更新进度',
+    prompt: `确认所有文件已保存，更新进度。
+
+### 操作
+1. 确认 plan.md 和所有 tasks/task-NN.md 已存在
+2. \`git add .sillyspec/\` — **不要 commit**
+
+### 输出
+文件列表 + 下一步命令`,
+    outputHint: '文件列表',
+    optional: false
+  }
+]
+
+/**
+ * 解析 plan.md 获取任务数量
+ */
+function parseTaskCount(planContent) {
+  const matches = planContent.match(/^[-*]\s*\[[ x]\]\s*task-\d+/gm)
+  return matches ? matches.length : 0
+}
+
+/**
+ * 生成单个任务的蓝图写作 prompt
+ */
+function buildTaskPrompt(taskNum, taskName, changeDir) {
+  return `编写任务蓝图 tasks/task-${String(taskNum).padStart(2, '0')}.md
+
+### 任务
+${taskName}
+
+### 文件路径
+\`.sillyspec/changes/<变更名>/tasks/task-${String(taskNum).padStart(2, '0')}.md\`
+
+### 格式要求（必须严格遵守）
+\`\`\`markdown
+# task-${String(taskNum).padStart(2, '0')}: ${taskName}
+
+## 修改文件
+- 具体文件路径列表
+
+## 实现要求
+1. 具体做什么，写清楚
+2. ...
+
+## 接口定义
+（代码类任务必填，写方法签名、数据结构）
+
+## 边界处理
+- 异常场景列表
+
+## 参考
+- 已有代码可参考的模式
+- 相关的 CONVENTIONS.md 条目
+
+## TDD 步骤
+1. 写测试 ...
+2. 运行 <test-cmd> 确认失败
+3. 写代码 ...
+4. 运行 <test-cmd> 确认通过
+（纯配置/文档类任务简化为：1. 实现 2. 验证）
+
+## 验收标准
+- [ ] 具体可测试的验收条件
+\`\`\`
+
+### 关键规则
+- task-N.md 必须独立完整，execute 子代理只读这一个文件就能干活
+- 不要依赖其他 task-N.md 的内容
+- 接口定义写到"搬砖工照着做"的程度
+- 写完后保存到文件
+
+### 操作
+1. 读取 design.md 和 plan.md 了解上下文
+2. 读取相关源文件了解现有代码
+3. 编写任务蓝图
+4. 保存到 tasks/task-${String(taskNum).padStart(2, '0')}.md
+
+### 输出
+任务蓝图内容摘要`
+}
+
+/**
+ * 动态构建 plan 步骤列表
+ * @param {string|null} changeDir - 变更目录路径
+ * @param {string|null} planContent - plan.md 内容（可选，用于解析任务数）
+ * @returns {Array} 步骤列表
+ */
+export function buildPlanSteps(changeDir = null, planContent = null) {
+  let taskCount = 0
+
+  // 尝试从 plan.md 解析任务数
+  if (planContent) {
+    taskCount = parseTaskCount(planContent)
+  } else if (changeDir) {
+    const planFile = path.join(changeDir, 'plan.md')
+    if (existsSync(planFile)) {
+      taskCount = parseTaskCount(readFileSync(planFile, 'utf8'))
     }
-  ]
+  }
+
+  // 没有任务数则用固定步骤（兼容旧流程）
+  if (taskCount === 0) {
+    return [...fixedPrefix, ...fixedSuffix]
+  }
+
+  // 动态生成每个任务的蓝图写作步骤
+  const taskSteps = []
+  for (let i = 1; i <= taskCount; i++) {
+    taskSteps.push({
+      name: `写任务蓝图 task-${String(i).padStart(2, '0')}`,
+      prompt: `### 注意
+这是第 ${i}/${taskCount} 个任务蓝图。focus 在这一个任务上，不要写其他任务的内容。
+
+${buildTaskPrompt(i, '（从 plan.md 读取任务名）', changeDir)}`,
+      outputHint: `task-${String(i).padStart(2, '0')} 蓝图`,
+      optional: false
+    })
+  }
+
+  return [...fixedPrefix, ...taskSteps, ...fixedSuffix]
 }

package/src/stages/quick.js

@@ -11,8 +11,11 @@ export const definition = {
 ### 操作
 1. 检查是否携带 \`--change <变更名>\`，确定记录方式
 2. 理解任务：模糊则问一个问题确认
-3. 加载上下文：\`cat docs/<project>/scan/CONVENTIONS.md 2>/dev/null\`
-4. 如有需要，查询知识库：\`cat .sillyspec/knowledge/INDEX.md 2>/dev/null\`
+3. 加载项目信息：\`cat .sillyspec/projects/*.yaml 2>/dev/null\`（了解项目结构和技术栈）
+4. 加载上下文：\`cat .sillyspec/docs/<project>/scan/CONVENTIONS.md 2>/dev/null\`
+5. 加载本地配置：\`cat .sillyspec/local.yaml 2>/dev/null\`（构建命令、测试命令、环境变量等）
+6. 如有 \`--change\`，加载设计文档：\`cat .sillyspec/changes/<变更名>/design.md 2>/dev/null\`（理解设计意图）
+7. 如有需要，查询知识库：\`cat .sillyspec/knowledge/INDEX.md 2>/dev/null\`
 
 ### 输出
 任务理解 + 上下文摘要`,
@@ -34,7 +37,8 @@ export const definition = {
 
 ### 铁律
 - 不要修改无关文件
-- 不要编造不存在的 CLI 子命令`,
+- 不要编造不存在的 CLI 子命令
+- **Reverse Sync**：如果发现 Bug 是 design.md 遗漏导致的，先修 design.md 再修代码`,
       outputHint: '实现摘要',
       optional: false
     },

package/src/stages/verify.js

@@ -55,13 +55,14 @@ export const definition = {
     },
     {
       name: '对照设计检查',
-      prompt: `对照 design.md 检查实现一致性。
+      prompt: `对照 design.md 检查实现一致性。**design.md 是唯一 truth source，不符合 design.md 的实现 = Bug。**
 
 ### 操作
 1. 架构决策是否遵循
 2. 文件变更清单是否一致
 3. 数据模型是否符合
 4. API 设计是否符合
+5. **Reverse Sync 检查**：如果发现实现合理但 design.md 未覆盖，先更新 design.md 补充遗漏
 
 ### 输出
 一致性检查结果`,