用途
TDD（Test-Driven Development，测试驱动开发）是一个面向软件开发流程的技能，用于在编写功能或修复缺陷时采用测试优先的方式。它围绕经典的红 → 绿循环展开，目标是让这个循环产出的测试真正值得长期保留。
适用时机：当用户希望以测试优先的方式构建功能或修复缺陷、提到“红—绿—重构”，或者需要集成测试时使用本技能。
主要能力
该技能是一份参考指南，涵盖以下内容：
- 什么是好的测试：测试应通过公共接口验证行为，而不是实现细节。代码可以完全改变，但测试不应随之改变。一个好的测试读起来像一份规格说明，例如“用户可以使用有效购物车结账”明确表达存在的能力，并且由于不关心内部结构，它能在重构后继续存活。
- 接缝（Seams）：接缝是你进行测试的公共边界，即在不深入内部的情况下观察行为的接口。测试位于接缝处，绝不针对内部实现。
- 反模式：包括与实现耦合（mock 内部协作者、测试私有方法或通过旁路验证）、同义反复（断言以与代码相同的方式重新计算期望值，从而在构造上必然通过）、水平切片（先写全部测试再写全部实现）。
- 循环规则：先红后绿；一次一个切片；重构不属于该循环。
使用方式
- 在探索代码库时，读取 CONTEXT.md（如果存在），使测试名称和接口词汇与项目的领域语言保持一致，并尊重所涉及区域的 ADR。
- 只在预先商定的接缝处测试。在编写任何测试之前，写下被测接缝并与用户确认。未经确认的接缝不写测试。可以询问：“公共接口是什么，我们应该测试哪些接缝？”
- 当接口本身的形态存疑时（模块深度、接缝位置、接口应暴露什么），通过 Skill 工具调用 "codebase-design" 获取相关词汇。
- 垂直切片推进：一个测试 → 一个实现 → 重复，每个测试都是一发曳光弹，回应上一轮循环带来的认知。
- 先应用于一个狭窄范围，确认输出符合预期形态后，再扩展到完整任务。
- 当某一步需要来自仓库或环境的事实时，应主动查找而不是询问用户。
适用场景
适用于以测试优先方式开发新功能、修复缺陷、进行红绿循环实践，以及需要集成测试的软件开发任务。适合希望获得可维护、面向行为测试的开发流程。
限制与说明
- 重构不属于红 → 绿循环，它属于评审阶段（参见 code-review 技能）。
- 该技能在上游由模型调用，是从 mattpocock/skills（MIT）导入的。
- 上游技能：mattpocock/skills skills/engineering/tdd/SKILL.md（commit 3cca18b，MIT）。
- 配套文档：references/mocking.md、references/tests.md。
- 项目标准：.agent-skills/skill-standardization/SKILL.md。
- 校验脚本：.agent-skills/skill-standardization/scripts/validate_skill.sh。
- 应保持上游流程完整；如偏离需明确记录，而不是默默即兴发挥。
- 在技能标记为属于用户的每个决策点，应停下并把控制权交还给用户。
- 优先采用小型、可逆的改动，并明确陈述假设而非隐藏它们。