关于 tcrdd
tcrdd 是一项通过原生 Git 执行红灯/绿灯/重构的技能,将工作拆分为小步测试驱动阶段。它会暂存更改、运行测试,并按结果提交或回退每个阶段,同时覆盖交互式和无人值守流程。
主要功能
- 01每阶段只推进一小步
- 02依据实际测试结果决策
- 03自动提交或回退
- 04支持交互与无人值守模式
- 05失败日志与恢复指引
适用场景
- 01逐步进行测试驱动开发
- 02在无人审批时运行编码任务
- 03避免测试失败后遗留部分更改
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ bsene/ skills --skill tcrdd安装后在 Claude Code 中输入/tcrdd确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
references/autonomous-execution.mdbenchmarks.mdexample-and-errors.mdfurther-reading.mdgit-cycle.mdphase-guide.mdpragmatics.md详细介绍
TCRDD
由原生 Git 驱动的红/绿/重构流程:每个阶段都会暂存更改、运行测试,并在结果符合预期时自动提交,否则自动还原(git reset --hard)。无需外部工具。
前置条件:从干净的工作树开始——没有未提交的更改,也没有未跟踪的文件。 还原操作(git add -A + git reset --hard)会删除未跟踪的文件,且无法通过 reflog 恢复,因此在循环开始时存在的任何未跟踪文件都会丢失。请在第一次执行 add -A 前,将想要保留的文件存入 git stash -u(或专用 worktree)。
模式
- 交互式(有人参与):使用以下审批关卡——先审批计划,再在每次暂存并运行测试前审批差异。
- 自主式(没有人可审批,例如无人值守运行):直接运行循环。 审批关卡可选——跳过并继续即可。仍需按阶段提交,每次仍只迈出一小步。不要停下来等待永远不会到来的审批。
关键防护措施
- 在宣布 RED/GREEN 或提交前,检查实际的完整测试运行结果。绝不要根据预测推进。
- 每个阶段只迈出一小步,包括无人值守运行;绝不要批量执行完整测试套件或实现。
- 测试前使用
git add -A暂存,以便失败的步骤也能还原新文件。重置前记录失败详情,然后追加到tcr-failure-log.md,并在重置后单独提交该日志。执行阶段前请阅读Git 循环。 - 只解析一次仓库的测试命令(按顺序检查包脚本、Makefile、语言惯例,然后是 README/CI,或询问用户);除非用户明确限定范围,否则每个阶段都重复运行完整 CI 测试套件。
- 自主运行:设定预算,并发 Agent 使用隔离的 worktree,为阶段提交添加标签,并在预算用尽时停止。同一步骤还原超过两次后,将其拆分;如果再次拆分后仍停滞,则停止并报告阻碍。有关必需的结构化交接,请遵循自主执行。
- 仅对简单代码、GUI 布局调整、可信的第三方内部实现或确实会丢弃的工作跳过或降级处理。对持久的 GUI 逻辑进行提取并使用 TCRDD;在第三方边界测试自己的代码。有关例外和严格限制,请阅读实用性指南。
工作流
GREEN:只编写通过当前失败测试所需的最少代码。 不要泛化,也不要处理未来的情况;使用下方编号最低的转换。
RED → plan test → approval? → write test → diff approval? → stage + run tests
test FAILS (expected)? commit [RED] → GREEN
test PASSES (unexpected)? log → reset --hard → try again
GREEN → plan code → approval? → write code → diff approval? → stage + run tests
tests PASS? commit [GREEN] → REFACTOR
tests FAIL? log → reset --hard → try again
REFACTOR → plan cleanup → approval? → refactor → diff approval? → stage + run tests
tests PASS (no behaviour change)? commit [REFACTOR] → (loop or done or back to RED)
tests FAIL? log → reset --hard → try again
如何编写代码
每个阶段开始前(仅交互模式):用户先审批计划,然后在暂存和运行测试前审批差异。
一次只做一步——绝不一次性完成。 每个阶段只推进一小步:先编写一个失败测试,再编写通过该测试所需的最少代码。不要一次性写完整测试套件或完整实现,即使在自主模式下也不行。如果你在一轮中就产出完整功能,说明你没有运行 TCRDD。
- RED——选择下一个最小行为;只编写足以使测试失败的内容(遇到第一个编译错误或断言失败时就停止)。
- GREEN——为当前失败测试编写最少的生产代码;不添加额外的辅助代码、依赖或未来情况处理。使用转换阶梯上编号最低的操作;如果需要使用编号较高的操作,说明测试过大,应将其拆分。
- REFACTOR——所有测试通过后,自由清理生产代码和测试代码。
- REPEAT——询问功能是否已完成:未完成则回到 RED;已完成则将中间提交压缩为一个干净的提交。
详情、完整的 12 步阶梯、小步与一次性完成的示例,以及错误处理表,请参阅下方的参考资料。
按需阅读
| 何时阅读 | 链接 |
|---|---|
| 编写 RED/GREEN/REFACTOR 阶段或选择转换方式时 | 阶段指南 |
| 查看一个小步示例,或遇到回滚、测试不稳定或工作树不干净的情况时 | 示例与错误 |
| 无人值守运行或向编排器汇报时 | 自主执行 |
| 实现暂存/测试/提交/回滚和故障日志时 | Git 周期 |
| 决定是否跳过或降低循环要求时 | 实用建议 |
| 了解 TCR/TDD/TPP 理论和原始文章(Beck、Uncle Bob)时 | 延伸阅读 |
| 查看基准测试结果时 | 基准测试 |
上游
| 开始 TCRDD 前 | 技能 | 原因 |
|---|---|---|
| 不确定是否值得构建此功能 | kano | 在投入红/绿/重构循环前对功能进行分类 |
评论
支持 Markdown