用途：该技能是测试驱动开发（TDD）的参考规范，围绕 red → green 循环展开，帮助写出值得保留的测试。当用户希望以测试先行方式构建功能或修复缺陷、提到 red-green-refactor，或需要集成测试时使用。
主要能力：说明什么是好测试、测试应放在哪里、常见反模式以及循环规则。好测试通过公共接口验证行为，而非实现细节；代码可以完全改变，测试不应随之改变。测试应读起来像规格说明，例如“user can checkout with valid cart”，并能在重构后继续存活。
接缝与测试位置：接缝是测试所在的公共边界，即观察行为而不深入内部的接口。测试只写在预先商定的接缝处。写任何测试前，先写下待测接缝并与用户确认；未确认的接缝不写测试。可询问：“What's the public interface, and which seams should we test?”
反模式：实现耦合——模拟内部协作者、测试私有方法或通过侧信道验证，重构时测试会失败但行为未变。同义反复——断言以与代码相同的方式重新计算期望值，例如 expect(add(a, b)).toBe(a + b)，或手工以同样方式推导快照、常量断言等于自身，导致测试按构造通过，永远无法与代码产生分歧；期望值必须来自独立事实来源，如已知正确的字面量、已演算示例或规格。水平切片——先写所有测试再写所有实现，批量测试验证的是想象的行为，测试对真实变化不敏感，并在理解实现前就锁定测试结构；应改用垂直切片，一个测试 → 一个实现 → 重复，每个测试都是响应上一轮所学到的内容的曳光弹。
循环规则：先红后绿，先写失败测试，再只写足够通过的代码，不预判未来测试或添加推测性功能。一次一个切片，每轮一个接缝、一个测试、一个最小实现。重构不属于该循环，它属于评审阶段，而非 red → green 实现循环。
探索代码库时，若存在 CONTEXT.md 应阅读，使测试名称和接口词汇与项目领域语言一致，并尊重所触及区域的 ADR。示例见 tests.md，模拟指南见 mocking.md。
限制：资料未提供具体安装命令、收费、价格、平台或效果信息。