用途
ds-tdd 是一个用于缺陷修复的测试驱动开发（TDD）技能。它的目标是在触碰生产代码之前，先让缺陷以可执行的形式呈现出来，使修复过程可被验证，而不是仅凭口头声称。适用于用户要求 TDD 风格修复缺陷的场景。
主要能力与步骤
- 锁定缺陷：明确期望行为、实际行为、涉及的代码路径，以及最小的复现方式。
- 沿用既有测试风格：在对应代码路径附近寻找已有的测试写法并直接使用，不为此缺陷单独搭建新的测试框架。
- 编写最小测试：写一个本应能捕获该缺陷的最小测试，检验的是预期行为，而非当前实现细节。
- 运行并展示输出：测试必须失败，且失败原因必须是该缺陷本身，而非拼写错误或缺失导入；若不是，先修正测试。
- 最小生产改动：做出能让预期行为成立、同时不破坏周边契约的最小修改。
- 验证：运行新测试与周边测试套件，并展示输出。
- 替代校验：若干净的测试不可行（例如初始化负担重、mock 脆弱、仅在成产环境出现），改用最接近的可运行校验，如脚本、复现命令或日志检查，并说明跳过测试的原因。
使用方式
按上述步骤顺序执行：先写失败的测试并展示失败输出，再做最小修复，最后展示新测试与周边套件通过的输出。遇到三次修复尝试后测试仍失败时，停止操作，报告所学到的信息，并运行 /ds-unstick。
停止条件
- 新测试在修复前失败、修复后通过，两者均有输出，且周边套件通过；或
- 经过三次修复尝试测试仍未通过，此时停止并报告，运行 /ds-unstick。
规则与限制
- 绝不为迎合错误实现而修改测试。
- 没有清晰、明确的理由，不得削弱既有断言。
- 坏测试不如没有测试：主要测试 mock、依赖时序、或在修复后立刻会被删除的测试均不可取。
- 该技能聚焦单个缺陷的修复流程；关于具体支持的语言、框架或运行环境，资料未提供。