Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious cheap local test target. Skip when the test path is unclear, expensive, integration-heavy, or not requested.
| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-22 | ✗→✓ | ▲ Improved | -12% | 0% |
| case-06 | ✓→✗ | ▼ Worse | -49% | 0% |
| case-12 | ✓→✗ | ▼ Worse | 6% | 0% |
| case-18 | ✓→✗ | ▼ Worse | 3% | 0% |
| case-13 | ✓→✓ | ＝ Same ✓ | 17% | 0% |
When fixing a bug with a clear, cheap test path, make the broken behavior executable before changing production code. The goal is a focused regression test that fails before the fix and passes after it.
Do not force a test when it would be impractical. If the available test would require broad harness setup, brittle mocks, slow end-to-end infrastructure, production-only state, vague reproduction steps, or large unrelated fixture churn, skip adding a new test and use the closest useful verification instead.
Do not silently skip the regression step. Before fixing, explicitly explain why a failing test is impossible or not worth the cost, then choose the closest executable regression check available. Examples include a targeted script, manual reproduction command, browser automation, snapshot comparison, log assertion, or focused integration check.
Prefer no new test over a bad test. A bad test is one that mostly tests mocks, encodes current implementation details, depends on timing or unrelated global state, needs expensive infrastructure for a small fix, or would be deleted immediately after proving the fix.
Report the evidence, not just the outcome:
Other measured skills in the registry, with their headline benchmark lift.