TCR: Test && Commit || Revert

Automate commit on test pass and revert on test failure.

1|Updated Oct 20, 2025
One-click install
npx skills add https://github.com/colek42/claude-plugins --skill tcr-test-commit-revert
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: TCR: Test && Commit || Revert
Source: https://github.com/colek42/claude-plugins/tree/main/nk-dev-practices/skills/tcr-practice
Command: npx skills add https://github.com/colek42/claude-plugins --skill tcr-test-commit-revert

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

TCR (Test && Commit || Revert) enforces extremely small, atomic code changes by automatically committing passing tests and reverting failing ones. This practice cultivates discipline, ensures high test coverage, and provides immediate feedback on development fatigue, leading to more robust code and a sustainable pace.

Core Features & Use Cases

  • Automated Commit/Revert: Forces "baby steps" by committing code only if tests pass, and reverting if they fail.
  • Failure Documentation: Prompts users to log failures, turning every revert into a valuable learning opportunity for pattern recognition.
  • TRC Variant: Supports the "Red" phase of TDD by committing on test failure and reverting on pass, ensuring tests are written correctly.
  • Use Case: A developer is refactoring a complex function. Using TCR, they make a tiny change, run tests, and if they pass, the change is automatically committed. If tests fail, the code reverts, forcing them to rethink and make an even smaller, safer step, leading to higher quality and less fear of breaking existing functionality.

Quick Start

Basic TCR script (save as tcr.sh and make executable)

<your test command> && git commit -am "TCR $(date +%H:%M:%S)" || git restore.

Example failure documentation (add to TCR-LEARNINGS.md)

TCR Learnings

## Failure Patterns

- Combining extraction + rename: Always fails - do separately

- Refactoring without reading tests first: 70% failure rate

Frequently Asked Questions about TCR: Test && Commit || Revert

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How does test-driven development with automatic commit and revert work?

TCR (Test && Commit || Revert) runs your test command after each code change: if tests pass, it automatically commits; if they fail, it reverts your code. This enforces tiny, atomic steps and immediate feedback, preventing unstable code from accumulating in your repository.

Can I use TCR during refactoring to prevent breaking changes?

Yes. TCR is designed for refactoring workflows where you make small changes, run tests immediately, and either commit the safe change or revert to try a different approach. This reduces fear of breaking existing functionality and forces decomposition into smaller, verifiable steps.

How do I set up TCR with my git repository and test command?

Create a shell script that runs your test command, then uses `git commit` on pass or `git restore` on fail. Execute this script after each code change. TCR integrates with any version control system and any test runner—just pipe your test command into the workflow.

What's the difference between TCR and standard test-driven development?

Standard TDD writes tests first but allows code to remain unstable between commits. TCR enforces atomic commits by reverting immediately on test failure, creating shorter feedback loops and higher discipline. It also supports a 'Red' variant that commits on test failure instead.

Does TCR work for mob programming and team development?

Yes. TCR enforces consistent, tiny steps across team members, making mob programming safer and more deliberate. Every revert becomes a shared learning moment; the Skill documents failures to identify refactoring patterns your team should avoid.

What happens when TCR reverts my code—is there a way to log why it failed?

TCR prompts you to document each failure in a learnings file, turning reverts into pattern recognition. You can record why a change failed (e.g., 'combining extraction + rename always fails'), creating a reference for safer refactoring decisions.