TDD 是一个面向单人实现工作的验收优先测试驱动开发工作流技能。它被设计为单用户工作流，不引入 worker、任务分配或团队协作概念。
用途 该技能用于直接处理编码改动时，遵循一套有纪律的流程：先阅读请求、相关代码与约束，再定义完成标准，然后才编写生产代码。它适合希望以验收标准驱动实现、并在可行时先写失败测试的开发者。
主要能力
- 在实现前阅读请求、相关代码与约束。
- 在编写生产代码前定义什么算“完成”。
- 当任务支持自动化测试时，优先进入红灯阶段（先写会失败的测试）。
- 不默认使用 E2E；仅在明确要求、任务契约已要求，或低成本验证无法覆盖验收风险时才使用 E2E。
- 若任务需要测试用例设计、回归规划、验收覆盖或更广泛的 QA 执行，调用 qa-expert，而不是把本技能扩展为完整 QA 工作流。
- 若自动化测试不合适，在实现前定义人工验证。
- 验证完成前不视为工作完成；若跳过验证，明确说明原因与残余风险。
使用方式 工作流按以下顺序执行：
- 阅读上下文：检查请求与周边实现，确认目标、范围、约束、非目标、现有验证选项；若请求含糊，先停止并解决歧义。
- 定义验收标准：在实现前写出验收标准，覆盖预期行为、边界情况、失败情况、可观察的完成条件；若还写不出验收标准，任务尚未准备好实现。
- 可行时编写失败测试：若任务支持自动化验证，在实现前编写或更新测试，目标是真实红灯阶段——新行为被断言、当前代码使该断言失败、预期结果清晰；若自动化测试不合适，先明确定义人工验证步骤。
- 实现：依据验收标准与验证计划实现；除非先更新验收标准，否则不要在实现中扩大范围。
- 验证：按顺序使用最强可用验证路径——现有自动化测试、为本次改动新增的自动化测试、含具体步骤与预期结果的可重复人工验证；仅当当前环境阻塞验证时才跳过。E2E 不是默认验证路径，除非明确要求或验收风险无法以其他方式覆盖，否则优先低成本检查。若验证期间需要专门的测试用例设计、回归执行或更广泛的 QA 覆盖，调用 qa-expert。若验证失败，返回实现并修复后再结论。
- 结论：以 passed、failed 或 skipped 之一结束，并包含改动简要摘要、所用验证、结果、残余风险（如有）；若结果为 skipped，包含原因及未验证引入的具体风险。
适用场景 适用于单人直接处理编码改动、希望遵循“阅读上下文→定义验收标准→写失败测试→实现→验证→结论”这一纪律化序列的场景。
限制
- 不引入 worker、任务分配或团队协作概念。
- 不默认使用 E2E。
- 不把本技能扩展为完整 QA 工作流；需要更广 QA 覆盖时调用 qa-expert。
- 需求不清、缺少验收标准、未定义验证策略时，应在实现前停止并解决。
- 测试意外失败、验证命令失败、人工验证不满足验收标准时，应回环继续工作。
- 可选工件（proposal.md、design.md、tests.md、显式 verify 命令）仅在有用时使用；除非周边项目已有固定目录结构，否则不要求固定目录结构。