TCR Commit Skill
TCR = Test && Commit || Revert
The core loop is simple: run the tests. If they pass, commit immediately. If they fail, revert the change. This forces small, safe steps and makes every commit a known-good state.
The TCR Loop
1. Make a small change (test or production code)
2. Run the relevant tests
3. GREEN? → git add <specific-files> + git commit (Conventional Commit message)
4. RED? → git checkout -- <changed-files> (revert to last green state)The discipline is in the size of the step. If reverting feels painful, the step was too big.
Commit Format
Use the git-commit skill conventions for message format: BRANCH-ID <type>: brief description with Co-Authored-By trailer via HEREDOC.
Types by TCR context:
| Context | Type | Example |
|---|---|---|
| New test (characterization or unit) | test | COMPANY-1234 test: add characterization test for calculateTotal |
| Test passes after refactor step | refactor | COMPANY-1234 refactor: extract calculateDiscount method |
| Bug fix confirmed by test | fix | COMPANY-1234 fix: correct null handling in getItems |
| New functionality via Sprout/Wrap | feat | COMPANY-1234 feat: add loyalty discount calculation |
TCR During Refactoring
When refactoring, the commit order matters. Follow this sequence:
Phase 1: Commit the safety net first
Before touching production code, ensure tests exist and are committed:
- Write or verify characterization/unit tests for the code you will refactor
- Run tests → GREEN
- Commit the tests separately:
BRANCH-ID test: add tests for <behavior> - This commit is your safety net. If anything goes wrong later, you can always return here.
Phase 2: Refactor in micro-steps
Each refactoring technique becomes one or more TCR cycles:
- Apply one small mechanical step (e.g., extract a method, rename a variable, move a field)
- Run tests → GREEN →
BRANCH-ID refactor: <what you did> - RED → revert immediately, try a smaller step
- Repeat until the technique is fully applied
Example — Extract Method in 3 TCR cycles:
COMPANY-1234 refactor: extract calculateSubtotal method signature
COMPANY-1234 refactor: move subtotal logic into calculateSubtotal
COMPANY-1234 refactor: inline temp variable after extractionPhase 3: Harden
After refactoring is complete:
- Add new unit tests for the refactored structure
- Run tests → GREEN →
BRANCH-ID test: add tests for <new structure>
When to Revert vs. When to Fix
- Revert when the change was a refactoring step and tests fail — the refactoring introduced a behavioral change, which means it was wrong. Start over with a smaller step.
- Fix forward only when you are writing a new test and the test itself has a bug (typo in assertion, wrong setup). In this case, fix the test, not the production code.
Integration with Refactoring Agents
When used inside a refactoring workflow (e.g., the java-refactoring-expert agent):
| Workflow Step | TCR Behavior |
|---|---|
| Cover (Step 3) | Write tests → run → GREEN → commit with BRANCH-ID test:... |
| Refactor (Step 4) | Each micro-step → run → GREEN → commit with BRANCH-ID refactor:... |
| Harden (Step 5) | New tests → run → GREEN → commit with BRANCH-ID test:... |
| Any RED | Revert the last uncommitted change immediately |
The agent should announce each commit to the user so they can see the trail of safe steps.
Key Principles
- Every commit is green — no broken commits, ever
- Tests before production code — always commit the safety net first
- Revert is not failure — it means you tried a step that was too big, try smaller
- One concern per commit — a test commit and a refactor commit are separate
- Specific file staging — never use
git add., always name the files - Never skip hooks — no
--no-verify, no amending published commits unless explicitly asked