plan-two

[IMPORTANT] 开始前，使用 TaskCreate 将所有工作拆分为小任务——包括为每个文件的读取创建任务。这可以避免长文件导致上下文丢失。对于简单任务，AI 必须主动询问用户是否跳过。

先理解代码 — 硬性门槛：在读取现有代码之前，不得编写、规划或修复。

1. 搜索 3 个以上相似模式（grep/glob）——引用 file:line 证据
2. 阅读目标区域的现有文件——了解其结构、基类和惯例
3. 当 .code-graph/graph.db 存在时，运行 python .claude/scripts/code_graph trace <file> --direction both --json
4. 通过 connections 或 callers_of 梳理依赖关系——了解哪些内容依赖你的目标
5. 对于非简单任务（涉及 3 个以上文件），将调查结果写入 .ai/workspace/analysis/
6. 实施前重新阅读分析文件——绝不可仅凭记忆开展工作
7. 如果现有模式可用，绝不杜撰新模式——严格遵循现有模式，或记录偏离原因

以下条件未满足前不得开始： - [ ] 已阅读目标文件 - [ ] 已搜索 3 个以上模式 - [ ] 已运行图追踪（如果 graph.db 存在）- [ ] 已通过证据验证假设

估算 — 修改版斐波那契数列：1（简单）→ 2（小型）→ 3（中型）→ 5（大型）→ 8（超大型）→ 13（史诗级，应拆分）→ 21（必须拆分）。在计划 frontmatter 中输出 story_points 和 complexity。复杂度自动推导：1-2=低，3-5=中，8=高，13+=严重。

计划质量 — 每个计划阶段都必须包含测试规范。

1. 在每个阶段文件中添加 ## Test Specifications 部分，并使用 TC-{FEAT}-{NNN} ID
2. 将每项功能需求映射到至少 1 个 TC（或明确标注 TBD 并说明理由）
3. TC ID 遵循 TC-{FEATURE}-{NNN} 格式——通过 ID 引用，绝不嵌入完整内容
4. 开始任何新的工作流步骤前：调用 TaskList 并重新阅读阶段文件
5. 上下文压缩时：先调用 TaskList——绝不创建重复任务
6. 阶段标记为完成前，验证其 TC 是否满足（证据必须为 file:line，不能是 TBD）

模式： TDD 优先 → 使用 Evidence: TBD 引用现有 TC。实施优先 → 使用 TBD → 由 /tdd-spec 事后补充。

迭代阶段质量 — 规划前评估复杂度。

复杂度信号： 文件数 >5 +2，跨服务 +3，新模式 +2，数据库迁移 +2 得分 >=6 → 必须拆分为多个阶段。每个阶段：

• 修改文件数 ≤5
• 工作量 ≤3h
• 遵循周期：规划 → 实施 → 评审 → 修复 → 验证
• 阶段 N 未通过 VERIFY 前，不得开始阶段 N+1

阶段成功 = 所有 TC 均通过 + code-reviewer agent 批准 + 无 CRITICAL 级问题。

• docs/test-specs/ — 按模块分类的测试规范（阅读现有 TC，以便在计划中纳入测试策略）

技能变体： /plan 的变体——创建两种备选实施方案以供比较。

快速摘要

目标： 调研并制定包含 2 种不同方案的实施计划，供用户比较和选择。

工作流：

1. 调研 — 深入调查问题领域
2. 方案 A — 设计第一种实施方案并分析权衡
3. 方案 B — 设计备选方案并分析权衡
4. 比较 — 并排呈现方案，供用户决策

关键规则：

• 仅限规划：不得实施，只创建对比计划
• 两种方案都必须切实可行，不能拿稻草人方案与真实方案比较
• 创建计划后始终提供 /plan-review

保持审慎，运用批判性思维和顺序思维。每项主张都必须有可追溯的证据和置信度百分比（Idea 应高于 80%）。

激活 planning 技能。

仅规划模式 — 需要协作

不要使用 EnterPlanMode 工具——你已经处于规划工作流中。 不要实施或执行任何代码更改。 与用户协作：提出决策问题，并提供选项和建议。 创建计划后，始终运行 /plan-review 以验证计划。 进入下一步前，请用户确认计划。

你的任务

使用 planner 子 Agent 为以下任务创建 2 份详细的实施计划： $ARGUMENTS

工作流

1. 首先：使用注入上下文中 ## Naming 部分指定的命名模式创建一个目录。 确保在整个过程中将目录路径传递给每个子 Agent。
2. 严格遵循 planning 技能中的“计划创建与组织”规则。
3. 并行使用多个 researcher Agent 研究此任务的不同方面，每个 Agent 最多执行 5 次研究（最多 5 次工具调用）。
4. 使用 scout Agent 搜索代码库中完成此任务所需的文件。
5. 主 Agent 汇总所有研究报告和 scout 报告的文件路径，并将这些路径与详细指示一并传给 planner 子 Agent，以创建此任务的实施计划。 **输出：**至少提供 2 种实施方案，明确比较取舍，并说明每种方案的优缺点，同时给出推荐方案。
6. 主 Agent 收到 planner 子 Agent 提供的实施计划后，请用户审阅计划。

计划文件规范

每个 plan.md 必须以以下 YAML frontmatter 开头：

```yaml
---
title: '{简短标题}'
description: '{用于卡片预览的一句话描述}'
status: pending
priority: P2
story_points: { 1-21 的修改斐波那契数列 }
effort: { 各阶段总和，例如 4h }
branch: { 当前 Git 分支 }
tags: [相关标签]
created: { YYYY-MM-DD }
---
```

重要任务规划说明（必须遵循）

• 始终使用 TaskCreate 将工作拆分成多个小型待办任务
• 始终添加一个最终审查待办任务，以验证工作质量并找出需要修复或改进的内容
• **必须添加的最终任务：**创建所有规划待办任务后，始终添加以下三个最终任务：
  1. 任务：“为每个阶段编写测试规范”——在每个阶段文件中添加 ## Test Specifications，并使用 TC-{FEAT}-{NNN} ID。如果存在功能文档，则使用 /tdd-spec。TDD 优先模式下使用 Evidence: TBD。
  2. 任务：“运行 /plan-validate”——触发 /plan-validate 技能，通过向用户提出关键问题来验证计划假设
  3. 任务：“运行 /plan-review”——触发 /plan-review 技能，自动审查计划的有效性、正确性和最佳实践

重要说明

**重要：**分析技能目录，并在过程中启用所需技能。 **重要：**撰写报告时，宁可牺牲语法，也要保持简洁。 **重要：**在保证质量的同时注意控制 Token 用量。 **重要：**如果报告中存在未解决的问题，请在末尾列出。

计划创建后的验证

计划创建后，使用 AskUserQuestion 工具询问：“要我运行 /plan-review 来验证，还是继续实施？”并提供以下选项：

• “运行 /plan-review（推荐）”——执行 /plan-review 以验证计划
• “继续实施”——跳过验证并开始实施

提醒——仅规划命令

不要使用 EnterPlanMode 工具。 不要开始实施。 计划创建后始终使用 /plan-review 进行验证。 开始任何实施前，务必请用户确认计划。 存在多种方案时，请向用户提出决策问题并给出建议。

后续步骤（独立调用：必须通过 AskUserQuestion 询问用户。如果在工作流中，则跳过。）

必须注意——无一例外：如果在工作流之外调用此技能，必须使用 AskUserQuestion 提供以下选项。不要因为任务看起来“简单”或“显而易见”就跳过——由用户决定：

• “继续完整工作流（推荐）”——我会从这里开始检测最合适的工作流（已创建计划），确保不会跳过审查、验证、实施和测试步骤。
• “/plan-review”——自动审查计划的有效性和最佳实践
• “/plan-validate”——通过访谈确认计划决策
• “跳过，手动继续”——由用户决定

如果已经在工作流中，则跳过——工作流会处理步骤安排。

收尾提醒

• **重要，必须注意：**开始前使用 TaskCreate 将工作拆分为小型待办任务

• **重要，必须注意：**创建新代码前，在代码库中搜索至少 3 个类似模式

• **重要，必须注意：**每项主张都引用 file:line 证据（置信度 >80% 才采取行动）

• **重要，必须注意：**添加最终审查待办任务，以核验工作质量

• **重要，必须注意：**在计划 frontmatter 中包含 Test Specifications 部分和 story_points

• **重要，必须注意：**任何修改前，搜索至少 3 个现有模式并阅读代码。如果 graph.db 存在，则运行图追踪。

• **重要，必须注意：**在计划 frontmatter 中包含 story_points 和 complexity。SP > 8 时拆分。

• **重要，必须注意：**包含 ## Test Specifications，并为每个阶段添加 TC ID。创建新任务前调用 TaskList。

• **重要，必须注意：**先评估复杂度。得分 >=6 时进行拆解。每个阶段都要经过：计划 → 实施 → 审查 → 修复 → 验证。不得跳过。