用途
TDD Planning 用于创建遵循严格测试驱动开发（TDD）方法的实现计划。每个实现步骤都遵循 TDD 循环：RED（红）→ GREEN（绿）→ COMMIT/ROLLBACK（提交/回滚）。该技能在用户调用 TDD-planning 命令、其他技能引用它、用户明确要求基于 TDD 的规划，或所实现功能属于测试关键/安全关键时激活。
核心原则
该技能强制一套规范化的 TDD 工作流：
- RED：先写失败测试（测试必须因正确的原因失败）
- GREEN：编写最小代码使测试通过（不多写）
- COMMIT/ROLLBACK：若通过则提交；若卡住则回滚到上一个绿色状态。
在没有失败测试之前，不编写任何实现代码，这一点不可妥协。
工作约定
- AskUserQuestion 是主要沟通工具：每当需要向用户询问（澄清、设计决策、偏好、批准）时，使用该结构化工具而非纯文本提问。
- 提前确定偏好：在工作流开始时询问用户偏好，而非在结束时。
- 自主模式引导交互程度：用户选择的自主级别决定检查频率，但所有问题仍通过 AskUserQuestion 提出。
用户偏好
在开始规划前（除非自主模式为 Autopilot），确定以下偏好：
- 提交粒度（Commit Granularity）：选项为 1. 每个 GREEN 后提交（严格 TDD 推荐）；2. 每个功能/阶段完成后提交；3. 用户手动处理提交。
- 回滚策略（Rollback Strategy）：选项为 1. git checkout . 回到上次提交（推荐）；2. git stash 改动以供后续分析；3. 保留失败代码并请求指导。
- 文件评审偏好（File Review Preference）：检查 file-review 插件是否可用（查找 file-review:file-review 命令）。若已安装，询问是否希望在计划就绪时使用 file-review 进行内联反馈，选项为 1. 是（推荐）；2. 否，仅展示计划。
将这些偏好存储下来，并在实现时据此执行。
自主模式
规划开始时，根据自主模式调整交互级别：
- Autopilot：独立研究，创建完整 TDD 计划，仅在最终评审时呈现。
- Critical（默认）：在主要决策点获取确认，验证测试策略。
- Verbose：每一步都检查，在每个循环前确认测试方法。
自主模式由调用命令传入。若未指定，默认使用 Critical。
流程步骤
步骤 1：上下文收集与测试基础设施分析
立即完整读取所有提及的文件（研究文档、相关计划、JSON/数据文件等），使用 Read 工具时不带 limit/offset 参数；在派生子任务前亲自读取文件。分析测试基础设施：使用什么测试框架（Jest、pytest、Go testing 等）？测试放在哪里（同目录、tests/、tests/ 等）？测试命令是什么（npm test、make test、pytest 等）？是否有可遵循的现有测试模式？派生初始研究任务：使用 codebase-locator 查找测试文件和测试工具，使用 codebase-analyzer 理解当前测试模式，使用 codebase-pattern-finder 查找类似的测试实现，使用 context7 MCP 获取测试库洞察。若不是 Autopilot，先以文本呈现发现（总结、测试框架、测试位置、测试命令、现有模式），再通过 AskUserQuestion 提问。
步骤 2：测试策略设计
识别可测试单元：哪些是最小的可测试片段？可验证哪些输入/输出？哪些边界情况重要？设计测试推进顺序：从最简单用例（happy path）开始，推进到边界情况，最后处理错误处理。若不是 Autopilot，通过 AskUserQuestion 验证方法（是否从最简单用例开始并推进到更复杂情况），选项为 1. 是，继续；2. 讨论顺序；3. 增加更多测试用例。
步骤 3：计划结构开发
创建 TDD 循环大纲，每个功能/阶段拆分为 TDD 循环，例如：
## Feature: [Name]
### Cycle 1: [Simplest behavior]
- RED: Test for [specific behavior]
- GREEN: Implement [minimal code]
- COMMIT: "[descriptive message]"
### Cycle 2: [Next behavior]
...
在编写细节前获取对结构的反馈（除非 Autopilot）。
步骤 4：详细计划编写
在继续前，退出 plan 模式以写入计划文件。将计划写入 thoughts/<username|shared>/plans/YYYY-MM-DD-tdd-description.md。路径选择：若从上下文得知用户名（如 thoughts/taras/plans/），使用用户名；不确定时回退到 thoughts/shared/plans/。关键：每个 TDD 循环必须包含要编写的确切测试代码和预期失败消息。QA 规格（可选）：改变用户可见行为的功能应在 Feature 级别包含可选的 QA Spec 段落（位于功能标题之后、第一个 TDD 循环之前）。遵循模板 cc-plugin/base/skills/tdd-planning/template.md。
步骤 5：评审与迭代
呈现草稿计划位置并请求评审。若不是 Autopilot，根据反馈迭代。提供结构化评审：询问是否希望运行 /review 对 TDD 计划进行完整性与缺口分析；若是，则在计划文档上调用 desplega:reviewing 技能。学习捕获（可选子技能）：若工作流中出现重要见解、模式、注意事项或决策，可考虑使用 desplega:learning 通过 /learning capture 捕获。工作流交接：计划定稿（并可选择评审）后，询问下一步，选项为 1. 实现此计划（→ /implement-plan）；2. 先运行评审（→ /review）；3. 暂时完成（暂存计划）。据此建议或调用相应命令，将计划状态设为 ready 或 parked。最终确定计划，不要开始实现。
评审集成
若 file-review 插件可用且用户在偏好设置中选择了「是」：在创建计划后，调用 /file-review:file-review <path>。若用户选择「否」或自主模式为 Autopilot，则跳过此步骤。
TDD 循环要求（强制）
每个实现步骤都必须遵循 TDD 循环，缺少正确 TDD 循环的计划不完整。每个循环的必需结构：
- RED 阶段：要编写的测试（确切测试代码）；预期失败（预期错误消息或失败输出）；验证 RED：测试命令应以上述消息失败。
- GREEN 阶段：实现方法（所需最小代码的简述）；要修改的文件（路径及增改内容）；验证 GREEN：测试命令现在应通过。
- COMMIT/ROLLBACK：若 GREEN，提交消息（遵循约定式提交）与命令 git add -A && git commit -m "[message]"；若 STUCK（合理努力后仍无法达到 GREEN），回滚 git checkout .（或依据偏好 git stash），并重新评估（考虑测试是否太大，或设计是否需要重新思考）。
验证清单：定稿任何 TDD 计划前，确认每个实现步骤都有 RED → GREEN → COMMIT/ROLLBACK 结构；RED 阶段包含确切测试代码；RED 阶段包含预期失败消息；GREEN 阶段描述最小实现；每个循环足够小，可一次完成；循环逐步递进；每个循环的回滚策略清晰。
重要指南
- 测试优先，始终如此：绝不在没有驱动它的测试的情况下描述实现。
- 最小 GREEN：只写足够让测试通过的代码，不多写。
- 小循环：若某循环显得过大，拆分为更小的循环。
- 递进复杂度：从简单开始，通过新测试增加复杂度。
- 清晰回滚点：每次提交都是可安全返回的点。
- 无投机代码：不要因为「以后会用到」而添加代码。
适用场景与限制
适用于测试关键或安全关键的开发工作，尤其是需要以 TDD 方式规划实现的场景。具体支持的测试框架、文件路径约定等取决于项目现有基础设施，资料未提供固定适用范围之外的更多细节。除上述已说明的提交与回滚命令及选项外，暂未提供其他收费、平台或效果相关信息。