用途
TDD 是一个测试驱动开发技能，适用于用户希望以测试先行（test-first）方式构建功能或修复缺陷、提到“red-green-refactor”（红—绿—重构），或需要集成测试的场景。
它的核心是红 → 绿循环，并作为一份参考，让这个循环产出值得保留的测试：什么是好测试、测试放在哪里、有哪些反模式，以及循环的规则。资料指出，每一节都适用于每一个循环周期：应在循环之前和循环进行中查阅，而不是循环之后。
主要能力
什么是好测试
测试通过公共接口验证行为，而不是验证实现细节。代码可以完全改变，测试不应随之改变。好测试读起来像一份规格说明：“user can checkout with valid cart”明确告诉你存在什么能力，并且它能经受重构，因为它不关心内部结构。
资料提到可参阅 tests.md 获取示例，参阅 mocking.md 获取模拟（mocking）指南。
接缝：测试放在哪里
接缝（seam）是你进行测试的公共边界：在这个接口上观察行为，而不深入内部。测试位于接缝处，绝不针对内部实现。
只在事先商定的接缝上测试。在编写任何测试之前，写下待测试的接缝并与用户确认。没有在未确认的接缝上编写测试。你无法测试一切，因此事先商定接缝，是让测试工作落在关键路径和复杂逻辑上、而不是每个边界情况上的方式。
需要询问：“公共接口是什么，我们应该测试哪些接缝？”
当接口本身的形态存在疑问时（模块有多深、接缝应位于何处、接口应暴露什么），可调用 Skill 工具并传入 "codebase-design" 以获取相关词汇。它是模块、接口、深度、接缝、适配器、杠杆和局部性等术语的共享来源，是一份供查阅的参考，而不是要运行的一次会话。
反模式
- 与实现耦合：模拟内部协作者、测试私有方法，或通过旁路验证（例如查询数据库而不是使用接口）。识别信号是：重构时测试失败，但行为并未改变。
- 同义反复：断言以与代码相同的方式重新计算期望值（例如 expect(add(a, b)).toBe(a + b)，手工以同样方式推导的快照，或断言一个常量等于它自身），因此它按构造就会通过，永远无法与代码产生分歧。期望值必须来自独立的事实来源：已知正确的字面量、已演算的示例、规格说明。
- 横向切片：先写所有测试，再写所有实现。批量测试验证的是想象出来的行为：你测试的是事物的形状而不是面向用户的行为，测试对真实变化变得不敏感，并且在理解实现之前就锁定了测试结构。应改为纵向切片：一个测试 → 一个实现 → 重复，每个测试都是一颗曳光弹，回应上一个循环教给你的东西。
使用方式
循环规则
- 先红后绿：先写失败的测试，然后只写足够让它通过的代码。不要预判未来的测试，也不要添加推测性的功能。
- 一次一个切片：每个循环一个接缝、一个测试、一个最小实现。
- 重构不属于该循环：重构属于评审阶段（参见 code-review 技能），而不是红 → 绿实现循环。
探索代码库时
阅读 GLOSSARY.md（如果存在），使测试名称和接口词汇与项目的领域语言一致，并尊重你正在触及领域的 ADR。
适用场景
- 用户希望以测试先行方式构建功能或修复缺陷。
- 用户提到“red-green-refactor”。
- 用户需要集成测试。
限制
资料未提供该技能的具体安装命令、支持的平台、收费或价格信息，这些内容暂未提供。