用途：在需要以测试驱动开发（TDD）方式构建功能或修复缺陷时使用，也适用于用户提到“red-green-refactor”或希望按该循环推进工作的场景。
核心理念：测试应通过公共接口验证行为，而非实现细节；代码可以整体重写，测试不应随之失效。好的测试偏集成风格，走真实代码路径、读起来像规格说明；差的测试耦合内部实现，如 mock 内部协作者、测试私有方法或绕过接口查询数据库——如果重命名内部函数就导致测试失败，说明它测的是实现而非行为。
反模式：禁止横向切片，即先写完全部测试再写全部实现。这会产生糟糕的测试：批量测试的是想象的行为，测到的是数据结构与函数签名等形态，对真实变化不敏感。正确做法是垂直切片、曳光弹方式：一个测试→一个实现→重复。
工作流：一、规划，先与用户确认接口变更、优先测试的行为、可提取的深模块、可测试的接口设计，并列出待测行为而非实现步骤，取得用户批准。二、曳光弹，写一个测试验证一件事：RED 先写失败测试，GREEN 写最小代码使其通过，证明路径端到端可用。三、增量循环，对每个剩余行为重复 RED→GREEN，一次一个测试，只写够当前测试通过的代码，不预判未来测试。四、重构，全部测试通过后处理重复、加深模块、按需应用 SOLID 原则，每一步重构后运行测试；处于 RED 状态时绝不重构。
每轮检查项：测试描述行为而非实现、仅使用公共接口、能在内部重构后存活、代码对当前测试最小化、未添加投机性功能。
限制与说明：关于示例与 mocking 指南，资料提及见 tests.md 与 mocking.md，但未提供具体内容；技能的安装或调用方式、支持平台、收费情况均暂未提供。