核心用法
该技能为纯文档型指导规范，不提供可执行代码，而是建立一套完整的 TDD 实施框架。使用者需遵循 11 步任务生命周期：从选取任务、标记进行中状态，严格执行 RED（编写失败测试）→ GREEN（最小实现通过）→ REFACTOR（重构优化）的三阶段循环，最终完成覆盖率验证、文档更新和 Git 提交。每个阶段结束时必须通过质量门禁（测试通过、80% 覆盖率、无 Lint 错误），并在获得用户显式批准后方可进入下一阶段。
显著优点
- 质量内建：强制先写测试后实现，从根本上提升代码可维护性
- 过程可追溯：要求每个任务关联 Git SHA，建立从需求到代码的完整链路
- 风险控制：阶段检查点机制防止问题累积，80% 覆盖率硬性门槛拦截技术债务
- 标准化协作：统一的 Git 提交格式（Conventional Commits 风格）和任务状态符号，降低团队沟通成本
- 灵活适配：支持范围变更（Scope Addition/Reduction）和技术偏离的规范化文档流程
潜在缺点与局限性
- 学习曲线陡峭：对不熟悉 TDD 的开发者存在认知负担，RED 阶段的"故意失败"可能引发抵触
- overhead 较高：11 步流程对小改动或紧急修复显得笨重，技能文档明确建议"快速修复或原型探索场景跳过使用"
- 工具链依赖：预设 pytest、Git、覆盖率工具等环境，对非 Python 技术栈或非 Git 工作流的项目需要额外适配
- 人工瓶颈：阶段检查点必须等待用户显式批准，可能阻塞自动化流水线
适合的目标群体
- 追求代码质量的中小团队，尤其是需要从"救火式开发"向"可持续交付"转型的组织
- 教学场景中的软件工程课程，作为 TDD 实践的标准操作手册
- 个人开发者建立规范的 side project 工作流程
- 不适合：需要快速验证想法的初创项目、无测试基础设施的遗留系统维护、纯前端原型开发
使用风险
- 流程僵化风险：过度遵循步骤可能导致"流程正确但业务价值延迟"，需结合实际调整严格程度
- 版本号不一致：当前 skill 存在 _meta.json（1.0.0）与 SKILL.md frontmatter（2.0.0）版本号不一致的维护问题
- 许可证缺失：skill-card.md 中 License 区域为空，商业使用需自行确认授权条款
- 外部工具版本漂移：文档中引用的 pytest、Git 命令可能随工具版本更新而行为变化，建议定期复核