用途：这是一个测试驱动开发（TDD）技能，用于在构建功能或修复缺陷时按红-绿-重构循环推进。核心理念是测试应通过公共接口验证行为，而非实现细节；代码可以整体变化，测试不应随之失效。
主要能力与原则：好的测试是集成风格的，走真实代码路径、读起来像规格说明，例如“用户可用有效购物车结账”，因此能经受重构。坏测试耦合实现，如 mock 内部协作者、测试私有方法或绕过接口直接查库，其信号是重构后行为未变但测试失败。资料另附 tests.md 示例与 mocking.md 的 mock 指引。
明确反模式：不要先写全部测试再写全部实现（水平切片）。这会产出批量想象行为、关注数据结构与函数签名、对真实变化不敏感的劣质测试，并在理解实现前就锁定测试结构。正确做法是垂直切片加曳光弹：一条测试对应一段实现，循环往复。
工作流程：一是规划，先查代码库时使用项目领域词汇表，让测试命名与接口用词匹配项目语言，并遵守相关 ADR；写代码前与用户确认接口变更、要测试的行为并按优先级排序，识别深模块机会，设计可测试接口，列出待测行为（不是实现步骤）并获得用户批准，可提问“公共接口长什么样？哪些行为最重要？”因为无法测试一切，需聚焦关键路径与复杂逻辑。二是曳光弹：写一个测试确认系统一件事，红（失败）→绿（最小代码通过），证明路径端到端可行。三是增量循环：对每个剩余行为重复红→绿，规则是一次一个测试、只写刚好通过的代码、不预判未来测试、测试聚焦可观察行为。四是重构：全部通过后消除重复、加深模块、自然应用 SOLID，并考虑新代码揭示的旧代码问题，每一步重构后跑测试；绝不在红灯时重构，先到绿灯。
每轮检查清单：测试描述行为而非实现；只用公共接口；能经受内部重构；代码对当前测试最小；不添加投机功能。
适用场景与限制：适合用户明确要求用 TDD 构建功能或修缺陷、提及 red-green-refactor 的情形；需用户参与确认接口与优先级。价格、平台支持、安装方式等资料暂未提供。