用途：以测试驱动开发（TDD）方式推进具有可执行行为、数据转换或运行时可验证契约的改动。核心原则是测试应通过公共接口验证行为，而非实现细节；代码可整体重写而测试不应受影响。
主要能力与流程： 规划。探索代码库时使用领域词汇表（CONTEXT.md，只读）使测试名与接口措辞匹配项目语言，并遵守产品规格（docs/INTENT-AND-DESIGN.md，缺失时用 docs/REQUIREMENTS-AND-NOTES.md，只读）中的架构决策。写代码前需确认接口变更、确认要测试的行为（按优先级）、识别深模块机会、为可测试性设计接口、列出行为清单并取得计划批准。 曳光弹。先写一个测试确认一件事：RED 写测试使其失败；GREEN 写最小代码使其通过，验证路径端到端可用。 增量循环。对每个剩余行为重复 RED→GREEN，一次一个测试，只写够当前测试通过的代码，不预判未来测试，测试聚焦可观察行为。 重构。全部测试通过后消除重复、深化模块（把复杂度移到简单接口之后）、在自然处应用 SOLID 原则，每步重构后运行测试。RED 状态下绝不重构，先到 GREEN。
使用方式：按垂直切片而非水平切片推进。错误做法是先批量写完所有测试再批量写实现；正确做法是一次测试对应一次实现，循环往复。每个循环自检：测试描述行为而非实现、只用公共接口、可在内部重构后存活、代码对当前测试最小、无投机性功能。
无人值守模式：当技能挂载到由 orchestrate-issues 派发的 issue worker 时无用户可问。不要停滞等待批准，也不要自行编造答案。接口变更可从 issue 的“What to build”推导；难逆转的沉默选择取与现有代码最一致的方案，并写入交接的 Drift 报告。要测试的行为以 issue 的验收标准为准，已批准的 issue 文件即计划批准，直接进入曳光弹。原本要问用户的内容放入交接的 Drift 报告，由编排器解决并记录到项目漂移日志（默认 docs/DECISIONS.md），本人绝不直接写入该文件。有真实用户在场时（直接调用），按清单询问。
范围门禁：文档不是运行时行为。对 Markdown、issue、决策、README 或指令类改动，不要写测试、解析器、校验器或夹具来断言标题、关键词、行数或散文结构；使用 git diff --check 和对链接、清单状态、依赖引用的最小结构审查；设计与文档决策由人工验收。只有具备可执行行为、数据转换或可通过公共接口证伪的运行时契约时才用 TDD。不要为了让当前测试通过而膨胀出数千行模块；应停止、缩小范围或拆分，并在漂移交接中报告。
限制：未提供具体的测试框架、语言、安装命令或运行命令；未提供收费与价格信息；未提供 effect 指标或平台支持细节。