@zhuan-ai/zhuanspec 2.2.4 → 2.4.8

package/dist/core/templates/slash-command-templates.js

@@ -1,12 +1,77 @@
 const baseGuardrails = `**约束条件**
 - 优先采用简单、最小化的实现，仅在请求或明确需要时添加复杂性。
 - 将更改严格限制在请求的结果范围内。
+- **知识库参考**：开始任何阶段前，先检查 \`zhuanspec/knowledge/\` 目录。使用 \`rg "[关键词]" zhuanspec/knowledge/\` 搜索相关陷阱和最佳实践，避免重复踩坑。阅读 \`zhuanspec/knowledge/index.md\` 了解项目级知识摘要。
 - 如果需要额外的 ZhuanSpec 约定或澄清，请参考 \`zhuanspec/AGENTS.md\`（位于 \`zhuanspec/\` 目录内 - 如果看不到，请运行 \`ls zhuanspec\` 或 \`zhuanspec update\`）。`;
 const proposalGuardrails = `${baseGuardrails}\n- **强制澄清要求**：在创建任何提案文件之前，必须首先分析用户请求，识别所有不确定或模糊的方面（范围、技术选择、优先级、验收标准等）。如果发现任何模糊之处，必须停止并使用**选项式交互**（如 \`AskQuestion\` 工具）提问，获得明确答复后才能继续。严禁在不确定的情况下自行推测、假设或创建提案。严禁要求用户手动输入大段文字来回答澄清问题。
 - 识别任何模糊或歧义的细节，使用带预设选项的选择题在编辑文件之前询问必要的后续问题。
-- 在提案阶段不要编写任何代码。仅创建设计文档（proposal.md、tasks.md、design.md 和规范增量）。实施在批准后的应用阶段进行。`;
+- 在提案阶段不要编写任何代码。先完成 techDesign（需求技术方案）后再创建 proposal/specs/tasks，实施在批准后的应用阶段进行。
+- **TechDesign 目录识别**：proposal 阶段扫描 changes/ 目录，通过 progress.json 的 phase 字段识别 techDesign 目录，交互式确认复用。
+- **Phase 自动更新**：复用 techDesign 目录时，自动运行 \`zhuanspec progress set-phase <change-id> propose\` 更新 phase。`;
+const proposalOutputFormat = `**输出格式要求**
+每个步骤完成后，输出阶段性进度报告：
+\`\`\`
+### 阶段进度报告
+
+**当前阶段**: Propose
+**当前步骤**: [步骤名称]
+**步骤状态**: ✅ 完成 / ⏳ 进行中 / ❌ 失败
+**输出文件**: [创建/修改的文件列表]
+**下一步**: [下一步骤描述]
+\`\`\`
+
+最终输出包含：
+1. **提案摘要** - 变更原因、内容、影响范围
+2. **关键 Requirements** - 列出所有 ADDED/MODIFIED Requirements
+3. **任务分布** - Wave 分布和任务数量
+4. **验证结果** - validate --strict 输出`;
+const applyOutputFormat = `**输出格式要求**
+- 每个任务完成后：\`[x] Task N.M - [完成描述]\`
+- Wave 完成后：\`Wave N 完成 - [任务列表]\`
+- 最终输出包含：
+  1. **实施摘要** - 完成的任务数量、修改的文件
+  2. **偏差检测结果** - 是否有偏离提案范围的修改
+  3. **下一步建议** - Review 阶段或继续任务`;
+const reviewOutputFormat = `**输出格式要求**
+- 每轨完成后：\`[轨名称] ✅ PASS / ❌ FAIL - [关键指标摘要]\`
+- 三轨并行输出汇总格式：
+  \`\`\`
+  ### Review 阶段进度报告
+
+  **轨道 A (Code Review)**: ✅ PASS / ❌ FAIL
+  - Critical Issues: [数量]
+  - Important Issues: [数量]
+
+  **轨道 B (Unit Test)**: ✅ PASS / ❌ FAIL
+  - Coverage: [百分比]
+  - Tests Passed: [数量]/[总数]
+
+  **轨道 C (Spec-Code)**: ✅ PASS / ❌ FAIL
+  - Consistency Rate: [百分比]
+  \`\`\`
+- 最终输出：review-report.md 路径、归档建议`;
 const proposalSteps = `**步骤**
-0. 审查 \`zhuanspec/project.md\`，运行 \`zhuanspec list\` 和 \`zhuanspec list --specs\`，并检查相关代码或文档（例如，通过 \`rg\`/\`ls\`）以将提案建立在当前行为基础上；注意任何需要澄清的空白。
+0. **检查知识库、加载项目知识并识别 TechDesign 目录**：
+   - 运行 \`rg "[关键词]" zhuanspec/knowledge/\` 搜索相关陷阱和最佳实践，避免重复踩坑
+   - 阅读 \`zhuanspec/knowledge/index.md\` 了解项目级知识摘要
+   - **加载项目知识**：调用 \`@skill:load-project-knowledge\` 进行渐进式加载：
+     * 输入：domain（当前项目）、keywords（从需求描述提取）
+     * 获取：matched_services（涉及的服务列表）、search_priority（检索优先路径）、architecture_constraints（架构约束）
+     * 使用：后续代码定位使用 search_priority 限定范围，方案设计检查 architecture_constraints
+   - 审查 \`zhuanspec/project.md\`，运行 \`zhuanspec list\` 和 \`zhuanspec list --specs\`
+   - 检查相关代码或文档（例如，
+   通过 \`rg\`/\`ls\`）以将提案建立在当前行为基础上；注意任何需要澄清的空白。
+   - **TechDesign 目录识别**：
+     * 扫描 changes/ 目录下的所有变更
+     * 检查每个变更的 metrics/progress.json 的 phase 字段
+     * 如果存在 phase=techDesign 的目录，列为候选
+     * 使用 AskQuestion 工具交互式确认：
+       - 选择复用现有 techDesign 目录（列出所有候选）
+       - 创建新目录
+       - 其他（手动指定）
+   - **Phase 初始化**：
+     * 如果复用 techDesign 目录：运行 \`zhuanspec progress set-phase <change-id> propose\`
+     * 如果新建目录：目录创建时自动初始化 phase=propose
 1. **强制澄清检查（必须首先执行，不可跳过）**：
    - 仔细分析用户请求，识别所有不确定或模糊的方面：
      * 范围是否明确？（边界、包含/排除的内容）
@@ -18,10 +83,11 @@ const proposalSteps = `**步骤**
      * 数据获取来源是否明确？（从数据库、API、文件、外部服务、历史逻辑复用）
      * 服务分层是否明确？（前端、后端、数据库、API、服务、4层架构、3层架构、2层架构、领域模型）
      * 依赖关系是否明确？（依赖哪些服务、依赖哪些库、依赖哪些组件）
+     * 测试 case 是否提供？（是否已有现成测试 case、BIC 系统 taskId/bicId）
      * 其他不明确？（其他不明确的情况）
    - 如果发现任何模糊之处，必须停止并使用**选项式交互**提问：
      * 使用编辑器的结构化问答工具（如 \`AskQuestion\`），将每个问题转化为带 2-5 个预设选项的选择题
-     * 每个问题末尾包含"其他"选项作为兖底
+     * 每个问题末尾包含"其他"选项作为兜底
      * 尽量将多个问题合并到一次交互中一次性展示
      * 必须等待用户选择答案，不能继续
      * **严禁**要求用户手动输入大段文字来回答
@@ -35,9 +101,11 @@ const proposalSteps = `**步骤**
    - If no clarification needed: Write "Status: COMPLETED - No clarification needed" with brief justification
    - This section MUST NOT be empty or contain only HTML comments
    - NEVER proceed to proposal writing without completing this checkpoint
-2. 选择一个唯一的动词开头的 \`change-id\`，并在 \`zhuanspec/changes/<id>/\` 下搭建 \`proposal.md\`、\`tasks.md\` 和 \`design.md\`（需要时）。
+   
+2. 选择一个唯一的动词开头的 \`change-id\`，但是必须注意，如果经过了techDesign阶段并且已经提前创建好了提案目录则必须直接复用，并在 \`zhuanspec/changes/<id>/\` 下搭建 \`proposal.md\`、\`tasks.md\` 和 \`design.md\`。
+    -如果复用了techDesign创建的提案目录，需要输出'techDesign阶段已经提前创建好提案目录，我将直接在该目录生成相关提案文件'
 3. 将变更映射为具体的功能或要求，将多范围的工作分解为具有明确关系和顺序的不同规范增量。
-4. 当解决方案跨越多个系统、引入新模式或在提交规范之前需要权衡讨论时，在 \`design.md\` 中捕获架构推理。
+4. 创建 \`design.md\`（必选），记录技术决策、最佳实践、隐式约定。归档时会自动提取这些内容沉淀到项目知识库。
 5. 在 \`changes/<id>/specs/<capability>/spec.md\` 中起草规范增量（每个功能一个文件夹），使用 \`## ADDED|MODIFIED|REMOVED Requirements\`，每个要求至少包含一个 \`#### Scenario:\`，并在相关时交叉引用相关功能。
 6. **发现可用 Skill 并创建 tasks.md**：
    - 运行 \`zhuanspec skills list --json\` 获取当前环境中可用的 skill 列表及其 description
@@ -66,43 +134,307 @@ const proposalSteps = `**步骤**
    4. You MUST add a "## Dependency Analysis" section at the end with "Status: COMPLETED"
    5. validate --strict will verify task ordering matches computed waves
 
-7. 使用 \`zhuanspec validate <id> --strict\` 进行验证，并在分享提案之前解决所有问题。`;
+
+7. **测试 case 来源询问**（强制询问）：
+   - 使用 AskQuestion 工具询问用户是否提供测试 case：
+     * 选项 A：提供测试 case（有现成 case，走 TDD 模式）
+     * 选项 B：暂不提供测试 case
+     * 选项 C：其他（请在后续补充说明）
+   - 用户选择处理：
+     * 选择"提供测试 case"：
+       - 启用 **TDD 模式**：先获取测试 case，再基于 case 设计 spec 和任务
+       - 通过 taskId/bicId 获取测试 case（使用 MCP 工具 \`zzcase_get_api_report_queryBaseCase\`）
+       - 或手动录入测试 case
+       - **【强制】创建 test-cases.md 文件**：
+         * 使用 \`getTestCasesTemplate\` 模板（从 \`src/core/templates/index.ts\` 导出）
+         * 文件路径：\`changes/<change-id>/test-cases.md\`
+         * 填写获取时间、来源（taskId/bicId/manual）、测试 case 详情
+         * 每个 TC-XXX 必须包含：前置条件、测试步骤、预期结果、验收点
+       - 在 \`tasks.md\` 的 **Test Case Coverage** 表格中使用 \`@test-case:TC-XXX\` 关联任务与测试 case
+       - **表格格式要求**（四列）：
+         | Task | 测试 Case ID | 测试 Case 文件路径 | 覆盖场景 |
+         |------|-------------|-------------------|----------|
+         | T1 | TC-001 | \`退货退款 > 创建售后 > 三选一页面 > 组装机弹窗\` | 描述 |
+         * "测试 Case 文件路径" 列填写 BIC 路径层级格式
+       - 任务实施顺序调整为：先写测试 → 再写实现 → 验证测试通过
+     * 选择"暂不提供"：跳过此步骤，按常规流程继续
+     * 选择"其他"：等待用户补充说明后继续
+
+   ⚠️ **CHECKPOINT [TEST-CASE-COVERAGE]**:
+   1. 如果用户提供测试 case，启用 TDD 模式，每个 Requirement 必须对应测试 case
+   2. 测试 case 应覆盖正向和异常场景
+   3. **必须创建 test-cases.md 文件**（使用 \`getTestCasesTemplate\` 模板）
+   4. Test Case Coverage 表格必须包含四列：Task、测试 Case ID、测试 Case 文件路径、覆盖场景
+   5. validate --strict 会验证测试 case 覆盖率（警告级别，不阻塞）
+   6. 记录询问结果到 tasks.md 的 **Test Case Source Log** 段
+
+
+8. 【自动验证与修复】：
+	   运行 \`zhuanspec validate <id> --strict --auto-fix\` 进行验证：
+	   - 如果验证通过（PASS）：继续下一步
+	   - 如果验证失败（FAIL）：自动触发修复循环：
+	     * CLI 自动分析错误原因
+	     * CLI 自动生成修复方案并执行
+	     * 重新验证（最多 3 次循环）
+	     * 循环结束后仍未通过：输出错误报告，等待人工干预
+	   - 验证通过后，输出提案摘要
+
+	9. 【输出提案摘要】：
+	   • 变更原因、内容、影响范围
+	   • 关键 Requirements
+	   • 任务数量和 Wave 分布
+
+	10. 【选项式交互确认】：
+	   使用 AskQuestion 工具弹出确认对话框：
+	   \`\`\`
+	   问题: "请确认是否批准此提案？"
+	   选项：
+	     A) 批准，进入实施阶段
+	     B) 需要修改提案内容
+	     C) 暂不批准，稍后处理
+	     D) 其他（请在后续补充说明）
+	   \`\`\`
+
+	   用户选择处理：
+	   • 选择"批准"：
+	     - 创建 \`.approved\` 文件
+	     - **运行 \`zhuanspec progress set-phase <change-id> apply\`** 写入 phase
+	     - **自动触发 Apply 阶段**：使用 Skill 工具调用 \`zhuanspec:apply\`，传入 change-id 参数
+	   • 选择"修改"：返回步骤 3 修改提案内容
+	   • 选择"暂不"：保持提案状态，等待后续处理
+	   • 选择"其他"：等待用户补充说明后继续
+
+	⚠️ **CHECKPOINT [PLAN-APPROVED]**:
+	- 用户必须明确选择"批准"选项才能进入 Apply 阶段
+	- 未批准前禁止任何代码修改操作
+	- PreToolUse Hook 会阻断未批准状态的 Write/Edit 操作`;
 const proposalReferences = `**参考**
 - 当验证失败时，使用 \`zhuanspec show <id> --json --deltas-only\` 或 \`zhuanspec show <spec> --type spec\` 检查详细信息。
 - 在编写新要求之前，使用 \`rg -n "Requirement:|Scenario:" zhuanspec/specs\` 搜索现有要求。
 - 使用 \`rg <keyword>\`、\`ls\` 或直接文件读取探索代码库，以便提案与当前实现现实保持一致。`;
 const applySteps = `**步骤**
 将这些步骤作为待办事项跟踪，逐一完成。
-1. 阅读 \`changes/<id>/proposal.md\`、\`design.md\`（如果存在）和 \`tasks.md\` 以确认范围和验收标准。
+1. **检查知识库并确认 Phase**：
+   - 运行 \`rg "[关键词]" zhuanspec/knowledge/\` 搜索相关最佳实践和陷阱
+   - **Phase 确认**：运行 \`zhuanspec progress show <change-id>\` 确认 phase=apply
+   - 如果 phase 不为 apply，运行 \`zhuanspec progress set-phase <change-id> apply\`
+   - 阅读 \`changes/<id>/proposal.md\`、\`design.md\`（如果存在）和 \`tasks.md\` 以确认范围和验收标准。
 2. **判断执行模式** - 根据 tasks.md 内容选择执行策略：
-   - **如果 tasks.md 包含 \`@depends\` 依赖声明**（存在 \`<execution_plan>\`）：
-     → 按【任务执行编排】规则执行（见 \`zhuanspec/AGENTS.md\` 中"任务执行编排"章节）
+   - **如果 tasks.md 包含 \`@depends\` 依赖声明**：
+     → **Wave 并行执行**：按 Wave 编号串行，Wave 内任务并行启动 subagent
+     → **Agent 类型选择**：根据任务是否标注 \`@test-case\` 选择：
+       * 无 \`@test-case\` 标注 → 使用 \`applyAgent\`（普通代码实施）
+       * 有 \`@test-case:TC-XXX\` 标注 → 使用 \`tddApplyAgent\`（TDD 模式）
+     → **Rules 和 Knowledge 注入**：编排 Agent MUST 在每个 subagent prompt 中注入：
+       * Rules：根据任务的 \`@skill\` 标注选择性注入 \`api-design.md\`、\`dao-standards.md\`、\`coding-standards.md\` 等
+       * Knowledge：始终注入 \`knowledge/index.md\` 知识索引摘要
+       * Troubleshooting：注入与任务相关的踩坑警告
+     → Subagent 上下文隔离：仅注入当前任务、关联 skill、相关 spec、Rules/Knowledge
    - **如果 tasks.md 无依赖声明**：
      → 按顺序执行（见下方步骤 3-5）
 3. **按顺序实施任务**（无依赖声明时）- 保持编辑最小化并专注于请求的变更。如果任务标注了 \`@skill:<skill-name>\`，直接调用对应 skill 获取指导后再实施。
+   - **阶段职责（按 Agent 类型区分）**：
+     * **applyAgent（普通模式）**：不生成单元测试文件，单测生成与验证统一在 Review 阶段执行
+     * **tddApplyAgent（TDD 模式，任务有 \`@test-case\` 标注）**：基于 test-cases.md 先写测试再实现代码
 4. **确认完成** - 在更新状态之前确保 \`tasks.md\` 中的每个项目都已完成。
 5. **更新清单** - 所有工作完成后，将每个任务设置为 \`- [x]\`，以便列表反映实际情况。
-6. **代码审查**（可选） - 审查已实施的代码，检查代码规范合规性、逻辑正确性、性能和安全性问题。如果发现问题，应在归档之前解决。
-7. 需要额外上下文时，参考 \`zhuanspec list\` 或 \`zhuanspec show <item>\`。`;
+6. **处理 Subagent 状态报告**（Wave 并行执行时）：
+   - **DONE**：继续下一任务
+   - **DONE_WITH_CONCERNS**：记录 concerns 并评估是否需要修复
+   - **BLOCKED**：评估 blocker 类型并决定处理策略（提供上下文/换更强模型/拆分任务）
+   - **NEEDS_CONTEXT**：提供缺失信息并重新启动 subagent
+7. **代码审查**（必选） - 必须执行 \`zhuanspec review <change-id>\`，并确认三项门禁全部通过后才可归档：
+   - 代码审查通过（Critical=0）
+   - 单测生成与验证通过
+   - Spec-Code consistency 通过
+8. 需要额外上下文时，参考 \`zhuanspec list\` 或 \`zhuanspec show <item>\`。`;
+const applyGuardrails = `${baseGuardrails}\n- **Wave 并行执行**：当 tasks.md 包含 \`@depends\` 时，按 Wave 编号串行执行，Wave 内任务通过 Agent tool 并行启动 subagent。
+- **Agent 类型选择**：根据任务 \`@test-case\` 标注选择 subagent 类型：
+  * 无 \`@test-case\` 标注 → \`applyAgent\`（普通模式，单测在 Review 阶段）
+  * 有 \`@test-case:TC-XXX\` 标注 → \`tddApplyAgent\`（TDD 模式，Apply 阶段执行测试用例）
+- **Rules 和 Knowledge 注入**：编排 Agent MUST 在每个 subagent prompt 中注入 Rules（根据 @skill）和 Knowledge（踩坑警告、最佳实践）。
+- **偏差处理**：PreToolUse Hook 检测到提案范围外修改时弹出选项式交互（更新提案/Bug修复豁免/取消）。3次偏差后强制更新提案。`;
 const applyReferences = `**参考**
 - 如果在实施过程中需要提案的额外上下文，请使用 \`zhuanspec show <id> --json --deltas-only\`。`;
-const archiveSteps = `**步骤**
-1. 确定要归档的变更 ID：
+const archiveSteps = `**前置检查**：
+- ⚠️ **CHECKPOINT [REVIEW-PASSED]**: Review 阶段必须通过（三轨全部 PASS）
+  - \`review-report.md\` 存在且显示 passed
+  - \`code-review-result.json\`: critical = 0
+  - \`unit-test-result.json\`: tests passed
+  - \`spec-consistency-result.json\`: passed
+- **Phase 确认**：phase 应为 review（运行 \`zhuanspec progress show <change-id>\`）
+
+**步骤**
+0. **检查知识库**：运行 \`rg "[关键词]" zhuanspec/knowledge/\` 搜索是否有需要沉淀的知识。阅读 \`zhuanspec/knowledge/index.md\` 了解项目级知识摘要。
+1. **确定变更 ID 并设置 Phase**：
    - 如果此提示已包含特定的变更 ID（例如在由斜杠命令参数填充的 \`<ChangeId>\` 块内），请在修剪空白后使用该值。
    - 如果对话中松散地引用了变更（例如通过标题或摘要），运行 \`zhuanspec list\` 以显示可能的 ID，分享相关候选，并确认用户意图是哪一个。
    - 否则，审查对话，运行 \`zhuanspec list\`，并询问用户要归档哪个变更；在继续之前等待确认的变更 ID。
    - 如果您仍然无法识别单个变更 ID，请停止并告诉用户您还无法归档任何内容。
+   - **Phase 设置**：运行 \`zhuanspec progress set-phase <change-id> archive\`
 2. 通过运行 \`zhuanspec list\`（或 \`zhuanspec show <id>\`）验证变更 ID，如果变更缺失、已归档或尚未准备好归档，则停止。
-3. 运行 \`zhuanspec archive <id> --yes\`，以便 CLI 移动变更并应用规范更新，无需提示（仅对仅工具类工作使用 \`--skip-specs\`）。
-4. 审查命令输出以确认目标规范已更新，并且变更已进入 \`changes/archive/\`。
-5. 使用 \`zhuanspec validate --strict\` 进行验证，如果看起来有问题，使用 \`zhuanspec show <id>\` 进行检查。`;
+3. **验证 Review 门禁**：确认上述四个结果文件存在且全部通过。
+4. 运行 \`zhuanspec archive <id> --yes\`，以便 CLI 移动变更并应用规范更新，无需提示（仅对仅工具类工作使用 \`--skip-specs\`）。
+5. 审查命令输出以确认目标规范已更新，并且变更已进入 \`changes/archive/\`。
+6. 使用 \`zhuanspec validate --strict\` 进行验证，如果看起来有问题，使用 \`zhuanspec show <id>\` 进行检查。
+7. **知识沉淀（手动补充）**：调用 \`@skill:zhuanspec:knowledge\` skill 从本次会话记忆中补充知识。
+   - CLI 已自动从变更目录提取结构化知识（design.md/proposal.md/tasks.md 中的决策、注意事项等）
+   - AI 需从会话记忆补充无法自动提取的内容（如对话中发现的隐式约定、调试陷阱等）
+8. **会话分析**：调用 \`@skill:session-analytics\` skill 分析本次会话的指标数据（工具调用、Token消耗、时长等）。
+9. **输出反馈链接**：告知用户填写使用反馈：
+   📋 https://doc.weixin.qq.com/forms/AJ4AfQfgAAwACwAAwaVABsCNqDXIKn8sf`;
 const archiveReferences = `**参考**
 - 在归档之前使用 \`zhuanspec list\` 确认变更 ID。
-- 使用 \`zhuanspec list --specs\` 检查刷新的规范，并在移交之前解决任何验证问题。`;
+- 使用 \`zhuanspec list --specs\` 检查刷新的规范，并在移交之前解决任何验证问题。
+- 知识提取分工：
+  - **CLI 自动**：归档时从变更目录（proposal.md/tasks.md/design.md/specs/*.md）正则提取结构化知识
+  - **AI 手动**：调用 \`zhuanspec:knowledge\` skill 从会话记忆补充隐式约定、调试发现等
+- 会话分析 (\`session-analytics\`)：记录本次会话的效率指标，用于改进工作流。`;
+const designGuardrails = `${baseGuardrails}\n- **独立设计阶段**：techDesign 命令用于在 proposal 之前生成技术设计请求文档，不依赖变更提案。设计文档可作为后续提案的输入。
+- **需求澄清优先**：在生成设计请求前，必须确认需求来源（大神页面、需求描述文本等）。
+- **Skill 调用为主**：技术方案生成主要通过 \`generate-tech-spec-md-skill\` Skill 完成，而非直接运行 CLI 命令。
+- **严格文件约束**：techDesign 阶段只能创建目录和 progress.json（phase=techDesign）。
+- **禁止创建提案文件**：禁止创建 .tech-design、design.md、proposal.md、tasks.md、specs/ 等。
+- **Proposal 复用**：proposal 阶段通过 progress.json 的 phase 字段识别 techDesign 目录。`;
+const designSteps = `**步骤**
+0. **检查知识库并生成 change-id**：
+   - 运行 \`rg "[需求关键词]" zhuanspec/knowledge/\` 搜索相关陷阱和最佳实践，避免重复踩坑。阅读 \`zhuanspec/knowledge/index.md\` 了解项目级知识摘要。
+   - **生成 change-id**（与 proposal 阶段命名规则一致）：
+     * 从用户需求描述中提取核心动词和关键词
+     * 格式：动词开头 + kebab-case 关词组合
+     * 示例："separate-techdesign-proposal-phases"、"add-user-auth"
+     * 使用 AskQuestion 工具交互式确认生成的 change-id
+
+1. **Phase 初始化**：
+     * 使用步骤 0 确认的 change-id 创建提案目录
+     * **仅创建以下内容**：
+       - 目录：changes/{change-id}/
+       - 文件：changes/{change-id}/metrics/progress.json（phase=techDesign）
+     * **禁止创建**：.tech-design、design.md、proposal.md、tasks.md、specs/、Skill 请求文件等
+     * 如果绑定到已存在 change：运行 \`zhuanspec progress set-phase <change-id> techDesign\`
+
+2. **确认需求来源**：
+   - 检查用户是否提供了需求来源（--dashen-page-id、--dashen-url 或 --desc）
+   - 如果没有明确来源，使用 AskUserQuestion 工具询问：
+     * 大神页面 ID 或 URL
+     * 直接提供需求描述文本
+     * 其他来源
+
+3. **目录检查**：
+- 是否已经创建提案目录 没有创建则立刻创建
+
+4. **调用 Skill 生成技术方案**：
+   - 使用 Skill 工具调用 \`generate-tech-spec-md-skill\`
+   - 传入需求来源参数（dashenPageId、dashenUrl 或 desc）
+   - Skill 会自动获取大神页面内容并生成完整技术方案文档
+
+5. **输出摘要**：
+   - 告知用户生成的文档路径
+   - **明确说明**：techDesign 阶段仅保存进度数据（progress.json），不创建 proposal.md 和 tasks.md
+   - 提示 phase=techDesign
+   - 提示下一步可以使用 \`/zhuanspec:proposal\` 创建变更提案（复用目录）`;
+const designReferences = `**参考**
+- 技术方案生成由 \`generate-tech-spec-md-skill\` Skill 完成，支持从大神页面或需求描述生成完整技术方案
+- Skill 输出包含：背景、目标、决策、风险、迁移计划、Mermaid 图表等完整技术方案结构
+- 使用 \`zhuanspec techDesign --help\` 查看 CLI 命令选项（用于生成请求文档或验证现有设计）`;
+const reviewGuardrails = `${baseGuardrails}\n- **门禁审查阶段**：review 命令用于执行三轨并行校验并汇总结论。
+- **强制审查**：所有变更在归档前必须通过三轨门禁，确保代码质量、测试覆盖与 Spec-Code 一致性。
+- **Skill 触发要求**：必须触发 \`code-review-expert\`（代码审查轨）与 \`generate-mockito-unit-test-skill\`（单测轨）。`;
+const reviewSteps = `**步骤**
+1. **确定变更 ID 并设置 Phase**：
+   - 如果此提示已包含特定的变更 ID，请使用该值
+   - 否则运行 \`zhuanspec list\` 显示活跃变更，并询问用户要审查哪个
+   - **Phase 设置**：运行 \`zhuanspec progress set-phase <change-id> review\`
+2. **执行三轨并行校验（强制）**：
+   - **轨道 A：Code Review 轨**
+     - 使用 Skill 工具调用 \`code-review-expert\` skill
+     - 输出 \`code-review-report.md\`，记录 Critical/Important 问题
+   - **轨道 B：Unit Test 轨（Skill）**
+     - 使用 Skill 工具调用 \`generate-mockito-unit-test-skill\`
+     - 对缺失场景补齐单测并执行测试命令，输出单测结果
+   - **轨道 C：Spec-Code 一致性轨**
+     - 运行 \`zhuanspec validate <change-id> --strict\`
+     - 确认 \`spec-code-consistent\` 规则通过
+3. **汇总执行 CLI Review**：
+   - 运行 \`zhuanspec review <change-id>\`
+   - CLI 汇总三轨结果并生成 \`review-report.md\` 及 JSON 结果文件
+4. **审查结果处理**：
+   - **PASS**：三轨全部通过（CR=PASS、UT=PASS、Spec-Code=PASS）且 Critical=0，可以继续归档
+   - **FAIL**：输出问题列表，需要修复后重新审查
+5. **修复循环**（如果失败）：
+   - 根据三轨报告定位问题并修复代码/补充单测/更新提案
+   - 重新执行三轨并再次运行 \`zhuanspec review <change-id>\`
+6. **确认通过后**：
+   - 告知用户审查已通过（三轨并行 + CLI 汇总）
+   - 提示可以使用 \`/zhuanspec:archive\` 进行归档`;
+const reviewReferences = `**参考**
+- 使用 \`zhuanspec review --help\` 查看完整选项
+- 审查报告包含：\`code-review-result.json\`、\`unit-test-result.json\`、\`spec-consistency-result.json\`、\`review-report.md\`
+- 单元测试覆盖率阈值默认 80%，可通过 \`--coverage-threshold\` 调整
+- \`code-review-expert\` Skill 输出保存到 \`zhuanspec/changes/<id>/metrics/code-review-report.md\``;
+const knowledgeGuardrails = `${baseGuardrails}\n- **知识管理阶段**：knowledge 命令用于管理项目级知识库（最佳实践、陷阱、隐式约定）。
+- **跨变更积累**：知识不绑定单个变更，是长期积累的项目资产。
+- **职责分离**：
+  - **CLI 自动提取**：归档时自动从变更目录（proposal.md、tasks.md、design.md、specs/*.md）提取结构化知识
+  - **AI 手动补充**：从本次会话记忆中补充无法自动提取的知识（如隐式约定发现、对话中的关键决策）`;
+const knowledgeSteps = `**步骤**
+1. **选择操作类型**：
+   - 查看：列出当前知识库内容
+   - 添加：从会话记忆手动添加新的知识条目（CLI 无法自动提取的内容）
+   - 搜索：按关键词搜索相关知识
+
+2. **查看知识库**：
+   - 运行 \`ls zhuanspec/knowledge/\` 查看目录结构
+   - 阅读 \`zhuanspec/knowledge/index.md\` 查看索引
+   - 使用 \`cat zhuanspec/knowledge/decisions/*.md\` 查看决策记录
+   - 使用 \`cat zhuanspec/knowledge/best-practices/*.md\` 查看最佳实践
+
+3. **从会话添加知识条目**（手动补充 CLI 无法自动提取的内容）：
+   - 选择分类目录（decisions/best-practices/implicit-conventions）
+   - 基于本次会话中的发现，使用模板创建条目：
+     \`\`\`markdown
+     # [标题]
+
+     **发现时间**: [YYYY-MM-DD]
+     **来源变更**: [change-id]（可选）
+     **关键词**: [关键词列表]
+     **来源**: 会话记忆（AI 补充）
+
+     ## 背景
+
+     [发现该知识点的背景描述 - 来自本次对话]
+
+     ## 问题/经验
+
+     [具体问题或经验描述 - CLI 无法自动提取的内容]
+
+     ## 解决方案/建议
+
+     [解决方案或最佳实践建议]
+
+     ## 相关代码
+
+     - \`[相关文件路径]\` - [说明]
+     \`\`\`
+   - **优先补充**：
+     - 对话中发现但未写入文档的隐式约定
+     - 调试过程中发现的陷阱
+     - 团队特有的最佳实践
+
+4. **搜索知识**：
+   - 使用 \`rg "[关键词]" zhuanspec/knowledge/\` 进行搜索
+   - 结合变更上下文进行知识推荐`;
+const knowledgeReferences = `**参考**
+- CLI 归档时自动从变更目录提取结构化知识（design.md 中的决策、proposal.md 中的注意事项等）
+- 本 skill 用于从会话记忆中补充无法自动提取的知识
+- 知识库目录结构：decisions（决策记录）、best-practices（最佳实践）、implicit-conventions（隐式约定）`;
 export const slashCommandBodies = {
-    proposal: [proposalGuardrails, proposalSteps, proposalReferences].join('\n\n'),
-    apply: [baseGuardrails, applySteps, applyReferences].join('\n\n'),
-    archive: [baseGuardrails, archiveSteps, archiveReferences].join('\n\n')
+    proposal: [proposalGuardrails, proposalOutputFormat, proposalSteps, proposalReferences].join('\n\n'),
+    design: [designGuardrails, designSteps, designReferences].join('\n\n'),
+    apply: [applyGuardrails, applyOutputFormat, applySteps, applyReferences].join('\n\n'),
+    review: [reviewGuardrails, reviewOutputFormat, reviewSteps, reviewReferences].join('\n\n'),
+    archive: [baseGuardrails, archiveSteps, archiveReferences].join('\n\n'),
+    knowledge: [knowledgeGuardrails, knowledgeSteps, knowledgeReferences].join('\n\n')
 };
 export function getSlashCommandBody(id) {
     return slashCommandBodies[id];

package/dist/core/templates/tasks-template.d.ts

@@ -2,6 +2,10 @@
  * Tasks Template
  *
  * Template for generating tasks.md with required checkpoint sections.
+ * This template MUST conform to strict validation rules in strict-rules.ts:
+ * - pre-clarification-completed: Must have valid Pre-Clarification Log section
+ * - skill-tags-valid: Must have Skill Mapping table and @skill tags
+ * - task-ordering-by-wave: Must have Wave headers in correct order
  */
 export interface TasksTemplateOptions {
     changeId: string;
@@ -9,10 +13,13 @@ export interface TasksTemplateOptions {
 }
 /**
  * Get the tasks.md template structure with required checkpoint sections
+ * Template uses valid completion markers to pass strict validation by default
  */
 export declare function getTasksTemplate(options?: TasksTemplateOptions): string;
 /**
  * Get the minimal tasks.md template (for quick scaffolding)
+ * Note: This minimal template will NOT pass strict validation by default
+ * User must fill in the Pre-Clarification Log and Skill Mapping sections
  */
 export declare function getMinimalTasksTemplate(): string;
 declare const _default: {