用途：以测试驱动开发（TDD）方式构建功能或修复缺陷，围绕红-绿-重构循环展开，适合用户明确要求采用 TDD 或提到 red-green-refactor 的工作流。
核心原则：测试应通过公共接口验证行为，而不是耦合实现细节。好的测试是集成风格，走真实代码路径，读起来像规范，能在重构后存活；坏测试会 mock 内部协作者、测试私有方法或绕过接口直接查库，一旦重命名内部函数就失败，说明它测的是实现而非行为。资料中提及 tests.md 有示例、mocking.md 有 mock 指南，但未给出内容。
反模式：禁止横向切片，即不要先写全部测试再写全部实现。那会产生测试臆想行为、只测数据结构和函数签名、对真实变化不敏感的问题。正确做法是纵向切片（tracer bullet）：一条测试→一份实现→重复。
工作流：一、计划阶段，探索代码库时使用项目领域词汇表，让测试名与接口用词一致，并遵守所触及区域的 ADR；写代码前要与用户确认需要的接口变更、优先测试哪些行为、识别深模块（小接口、深实现）机会、针对可测试性设计接口、列出要测的行为清单，并获得用户对计划的批准。二、tracer bullet：写一条确认单一行为的测试，红：失败；绿：写最小代码通过。三、增量循环：对剩余每个行为，红：写下一测试使其失败；绿：写最小代码通过。规则是一次一条测试、只写够通过当前测试的代码、不预判未来测试、测试聚焦可观察行为。四、重构：全部测试通过后寻找重构点，例如消除重复、加深模块（把复杂度移到简单接口后面）、自然应用 SOLID 原则、思考新代码对既有代码的启示，每步重构后运行测试。处于 RED 时绝不重构，先到 GREEN。
每轮检查清单：测试描述行为而非实现；只用公共接口；重构内部后测试仍能通过；代码对当前测试而言是最小的；没有加入投机性功能。
限制与来源：资料未提供安装命令或具体运行命令，也未说明支持的编程语言、平台或收费标准，暂未提供。该技能基于 Matt Pocock 的工作（原始仓库：https://github.com/mattpocock/skills，MIT License），由 webconsulting.at 适配。