Skip to content
cccskills
FreePublished on GitHubEnglish overview

tdd-repair

Automatically repair source code against a failing test while preserving the test itself. Set a spending limit and attempt count, then receive verification results and usage costs based on rerunning the test command.

OriginalShow the original description

Test-Driven Repair — given a failing test, spawn a bounded headless `claude -p` (Read/Edit/Bash only) that makes the test pass without modifying it. Modeled on agent-harness-generator's ADR-175 Test-Driven Repair mode. Bounded cost via --max-budget-usd, bounded capability via --allowedTools. Closes the loop the TDD plugins didn't — we generate tests, this fixes the code to satisfy them.

AI rating90/ 100See how to install

Good for

  • Repairing a failing CI test after a commit
  • Implementing code to pass a test written first
  • Investigating a regression within a fixed budget

Overview

What it does

tdd-repair uses a failing test to guide automatic changes to the implementation. It attempts repairs through claude -p, then reruns the same test to determine whether the repair worked. If an attempt changes the test, its original contents are restored and the attempt counts as a failure. Adding new dependencies is prohibited. Results include the before and after states, verification for each attempt, and usage costs.

When it helps

Use it when a commit causes CI tests to fail or when you have written tests first and need an implementation that passes them. It also helps investigate a previously passing test that now fails, with a specified budget and maximum number of attempts.

Example requests

  • “Fix the failing test in this repository without changing the test itself.”
  • “Make this regression test pass with a $15 budget and at most three attempts.”

Notes

It uses a Node.js script and Claude CLI. Actual repairs require --confirm; otherwise, it returns an execution plan. A failing test is required, and large architectural changes are unsuitable. Bash restrictions do not provide isolation, so use trusted code and a clean Git working tree. Code changes remain even when repair fails.

This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.

Objective evaluation

AI rated this skill on four points using only the contents of its SKILL.md. Stars and popularity are not taken into account.

Clear instructionsIs it clear when to use it and what it does?
AGoodThe documentation defines implementation repair against failing tests and explicitly lists situations outside its scope.
Concrete stepsAre steps, inputs, outputs, and examples spelled out?
AGoodSteps from preflight verification through retesting, arguments, JSON results, and exit codes are provided.
SafetyAre sending data, deleting files, and running commands disclosed?
AGoodThe documentation specifies confirmation, cost limits, test restoration, Bash's lack of isolation, and retained workspace changes.
Easy setupDoes it need few tools or API keys, and are they documented?
BPartly lackingExamples use Node.js and Claude CLI, but installation and authentication procedures are not documented.

The total counts each point as A = 25, B = 15, C = 5. Rated by AI (OpenAI Codex) as of Oct 21, 2026. Treat it as a guide and read the original before installing.

Disagree? Request a re-evaluation

Tell us which point is wrong and why. No login needed. We will check it against the SKILL.md, redo the evaluation, and show the result here.

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

Files included (1)

  • SKILL.md6.5 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Surfaces the Test-Driven Repair loop as a ruflo skill. Use when you have a failing test and want the source-under-test fixed automatically, with the test's pass/fail as the verification gate (no LLM-as-judge).

When to use

  • Failing CI test from a recent commit — point this at the test file, get a verified fix (or a clear "couldn't repair within budget" receipt).
  • Local TDD workflow — write the failing test first (tdd-workflow skill), then run tdd-repair to drive the green.
  • Regression triage — a previously-green test went red; before opening an issue, spend ~$1 to see if the fix is trivial.

When NOT to use

  • No failing test exists. Conformant mode (--no-test-oracle) is scoped for a follow-up ADR — needs MCTS over repro generation. For now, write a failing test first.
  • Architectural changes. This skill is for tactical "make red green" fixes. Cross-module refactors that incidentally break tests should be done by a human or a swarm.
  • Untrusted code. The headless claude -p runs with --allowedTools Read,Edit,Bash — no MCP, no network, no arbitrary file writes — but Bash can still read and write the filesystem and reach the network, so allowing it is not a sandbox. Don't point this at code you wouldn't git checkout . after, and run it on a clean git tree.

Algorithm

Implementation: scripts/tdd-repair/tdd-repair.mjs.

  1. Pre-flight verify — run the test command. If it already passes, exit 2 (test-already-passes). Repairing a green test is either a no-op or a --test-command typo.
  2. Spawn claude -p with a focused prompt:
    • Failing test file path (read-only intent)
    • Test command (run only)
    • Hard constraint: do NOT modify the test
    • Hard constraint: do NOT add new dependencies
  3. --allowedTools Read,Edit,Bash restricts capability. --max-budget-usd caps cost per attempt. --permission-mode acceptEdits auto-accepts file edits within the allowed set.
  4. Re-run the test to verify. The test's exit code IS the fitness function — no separate sandbox / LLM-as-judge.
  5. If green: emit success: true + per-attempt usage. If red after --max-attempts: emit success: false + receipts. Either way, the workspace is left as claude -p modified it (caller can git diff to review).

Output shape

{
  "success": true,
  "data": {
    "repaired": true,
    "attemptsTaken": 1,
    "mode": "test-driven",
    "before": { "passed": false, "exitCode": 1 },
    "after":  { "passed": true,  "exitCode": 0, "durationMs": 4321 },
    "attempts": [
      { "attempt": 1, "claude": { "ok": true, "durationMs": 38421, "usage": { "cost_usd": 0.0234 } }, "verify": { "passed": true } }
    ],
    "totalCostUsd": 0.0234,
    "budgetUsd": 5.0,
    "budgetExhausted": false,
    "shape": { "repo": "...", "test": "...", "testCommand": "...", "maxAttempts": 1, "model": "haiku" }
  }
}

Exit codes

CodeMeaning
0Test green after repair (success)
1Test still red after --max-attempts
2Config error (test file missing, test already passes, --no-test-oracle unsupported, etc.)
3Claude CLI exited non-zero (infrastructure failure)
99Reserved for safety tripwire (per ADR-153)

Safety posture

LayerMechanism
Cost cap--max-budget-usd default $5, divided across --max-attempts. Hard ceiling — claude exits when reached.
Capability cap--allowedTools Read,Edit,Bash — no MCP tools. Bash can still write files and use the network, so this narrows the tool set, it is not a sandbox.
Scope capThe prompt forbids adding dependencies. The test file is enforced, not just requested: if an attempt changes it, the original bytes are restored and the attempt is scored failed (reason: test-file-modified).
Confirmation gate--confirm REQUIRED — without it, returns dry-run plan (mirrors harness-evolve / harness-mint convention).
Hard timeout15 min total wall-clock; per-attempt budget of timeoutMs / maxAttempts.
Pre-flightRefuses to run if the test already passes (catches --test-command typos).

Inspiration

Modeled on the Test-Driven Repair mode from agent-harness-generator/packages/darwin-mode ADR-175. Key design difference: instead of wrapping metaharness-darwin evolve (population-based search), we drive a single claude -p invocation. Rationale:

  • The test command IS the fitness function — no need for variant scoring
  • claude -p is already in our stack — no new optional dep
  • Bounded cost / capability are first-class flags
  • Resumable via --session-id if iteration is needed

Conformant mode (no test, write own repro via MCTS) is deferred to a future ADR.

Example

# Smoke / dry-run (no --confirm yet)
node plugins/ruflo-testgen/scripts/tdd-repair/tdd-repair.mjs \
  --repo /path/to/myrepo \
  --test tests/auth.test.ts \
  --test-command "npx vitest run tests/auth.test.ts"

# Actually repair (Haiku tier, $5 budget, 1 attempt)
node plugins/ruflo-testgen/scripts/tdd-repair/tdd-repair.mjs \
  --repo /path/to/myrepo \
  --test tests/auth.test.ts \
  --test-command "npx vitest run tests/auth.test.ts" \
  --confirm

# Bigger model + more attempts for harder bugs
node plugins/ruflo-testgen/scripts/tdd-repair/tdd-repair.mjs \
  --repo . --test tests/regression-2456.test.ts \
  --test-command "npm test -- tests/regression-2456.test.ts" \
  --model sonnet --max-attempts 3 --budget 15.00 \
  --confirm

Cost ladder

TierModelPer-attempt typicalUse when
1Haiku$0.02 – $0.20First try — most "make red green" bugs are tactical
2Sonnet$0.30 – $2.00Haiku failed, or the bug has multi-file scope
3Opus$1.50 – $8.00Sonnet failed — architectural reasoning required (rarely worth it for a single failing test)

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

add-model-descriptions

FreeSummaryAI rating 80

Compare models available through the HuggingFace router with chat-ui configuration, research missing models, and write short English descriptions of their architecture and capabilities. Add entries to both production and development configuration files and commit the changes.

  • Adding newly available router models to chat-ui
  • Writing concise descriptions of model capabilities
  • Updating production and development model entries together
ruvnet/ruflo78.3KUpdated Oct 22, 2026

adr-create

FreeSummaryAI rating 80

Create an Architecture Decision Record, a document for recording important design choices, with the next sequential number. It generates a Markdown template, registers the record in AgentDB, and links related decisions found through search.

  • Record the reasoning behind adopting a technology
  • Start an ADR for an API or data model change
  • Document an infrastructure decision
ruvnet/ruflo78.3KUpdated Oct 22, 2026

adr-index

FreeSummaryAI rating 90

Build a searchable index and relationship graph from ADRs, records of architectural decisions. Import two supported document formats, refresh existing metadata without duplicate relationships, and review summaries of statuses, missing references, and inconsistencies.

  • Index ADRs imported from another project
  • Refresh a graph that differs from files on disk
  • Set up ADR tracking in an existing codebase
ruvnet/ruflo78.3KUpdated Oct 22, 2026

adr-reindex

FreeSummaryAI rating 70

Rebuild the index of ADRs, records of architectural decisions, after files or relationship lines are deleted. It clears stored records and relationships, indexes the files still present, and checks that the final record count matches.

  • Rebuild the index after deleting an ADR file
  • Remove stale relationships after editing an ADR
  • Reconcile the ADR index on a schedule
ruvnet/ruflo78.3KUpdated Oct 22, 2026

adr-review

FreeSummaryAI rating 80

Review code changes against accepted Architecture Decision Records, documents that capture agreed design choices. Report violations, outdated references, compliant changes, and areas without ADR coverage, then suggest code fixes or a new decision record where appropriate.

  • Check a pull request before merging
  • Review major code changes against agreed design decisions
  • Find references to superseded ADRs
ruvnet/ruflo78.3KUpdated Oct 22, 2026

adr-verify

FreeSummaryAI rating 90

Check saved architecture decision records (ADRs) for broken references, circular replacement relationships, and inconsistent statuses. Use the results to verify imported records or stop a CI check when selected integrity rules fail.

  • Checking ADR integrity after import
  • Blocking CI when ADR issues are found
  • Reviewing ADR data before a release
ruvnet/ruflo78.3KUpdated Oct 22, 2026

See all skills by ruvnet

Report a problem with this skill