agentleFS
Sign inStart free
LucasCooperBeyLucasCooperBey/claude-skills/skills/test-and-fix/SKILL.md

test-and-fix

Skill1 starsChanged 5 months agoMITView on GitHub

Run tests and auto-fix failures. Standalone test runner that diagnoses and repairs failing tests without manual intervention.

We split this skill into the rules it gives an agent

17 rules. 0 are common, 11 are distinctive, and 6 are very specific to this project.

  • 0

    Common

    Most of the 5 edited versions we read keep these.

  • 11

    Distinctive

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run the test suite and automatically fix any failures.

    line 7
  2. Distinctive:

    After making code changes

    line 11
  3. Distinctive:

    When tests are red and you want them green fast

    line 13
  4. Distinctive:

    If approaching budget, stop fixing and report what remains

    line 30
  5. Very specific:

    Check the project root to determine the test command.

    line 34
  6. Very specific:

    If --file was provided: $TEST_CMD [file] 2>&1

    line 53
  7. Very specific:

    All pass? Report SUCCESS: All tests passing and exit.

    line 61
  8. Very specific:

    If --no-fix: skip to Step 6.

    line 75
  9. Distinctive:

    Read the failing test file AND the source file it tests

    line 79
  10. Distinctive:

    If still failing, try ONE different approach

    line 83
  11. Distinctive:

    If still failing after 2 attempts, flag for manual review and move to next failure

    line 84
  12. Very specific:

    After all individual fixes, run the full suite: $TEST_CMD

    line 90
  13. Distinctive:

    If fixes introduced NEW failures:

    line 92
  14. Distinctive:

    Never delete tests to make them pass

    line 114
  15. Distinctive:

    Prefer fixing source over changing test expectations (unless the test is genuinely wrong)

    line 115
  16. Distinctive:

    If a fix changes public API behavior, warn the user before applying

    line 116
  17. Very specific:

    If no test runner detected and user doesn't provide one, exit with BLOCKED: No test runner found

    line 118

“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Test and Fix (/test-and-fix)

Run the test suite and automatically fix any failures.

When to Use

  • After making code changes
  • Before committing
  • When tests are red and you want them green fast
  • As a standalone alternative to the fix loop in /ship

Arguments

Parse $ARGUMENTS for these flags:

ArgEffect
--file "path"Run only specific test file
--no-fixReport failures without fixing
(bare path)Treat as --file

Time Budget

  • Total: 10 minutes max
  • Per-failure fix: 2 minutes max
  • If approaching budget, stop fixing and report what remains

Step 1: Detect Test Runner

Check the project root to determine the test command. Do NOT assume bun test.

SignalRunner
bun.lockb or bunfig.tomlbun test
package.json with "test" scriptbun run test (or npm test if no bun lockfile)
pytest.ini, pyproject.toml [tool.pytest], or conftest.pypython -m pytest
Gemfile with rspecbundle exec rspec
Makefile with test targetmake test
None foundAsk user for test command, then proceed

Store the detected command as $TEST_CMD for all subsequent steps.

Step 2: Run Tests

$TEST_CMD 2>&1

If --file was provided: $TEST_CMD [file] 2>&1

Capture: pass/fail counts, error messages, stack traces, file locations.

If tests hang (no output for 60s): Kill the process, report timeout, ask user.

Step 3: Triage Failures

All pass? Report SUCCESS: All tests passing and exit.

Categorize each failure:

CategoryExampleAction
Type errorProperty missing, wrong argFix the type
Logic errorWrong assertion valueFix the implementation
Test driftTest expectations outdatedUpdate the test
Missing mockUnresolved dependencyAdd mock/stub
Env/configMissing env var, wrong DB URLFix config, don't touch code

Step 4: Fix Loop

If --no-fix: skip to Step 6.

For each failing test (max 5 fix iterations total, max 2 attempts per failure):

  1. Read the failing test file AND the source file it tests
  2. Determine fix location: source code, test code, or mock/fixture
  3. Apply the fix using Edit tool
  4. Re-run just that test file: $TEST_CMD [file]
  5. If still failing, try ONE different approach
  6. If still failing after 2 attempts, flag for manual review and move to next failure

Never retry the exact same fix. Change approach or escalate.

Step 5: Full Suite Verification

After all individual fixes, run the full suite: $TEST_CMD

If fixes introduced NEW failures:

  1. Identify which fix caused it (check git diff)
  2. Revert that specific fix: git checkout -- [file]
  3. Report the conflict — don't attempt to resolve cascading failures

Step 6: Report

## Test Results

### Fixed
- `file:line` -- description of fix

### Still Failing (needs manual review)
- `file:line` -- why auto-fix didn't work

### Summary
- N tests total, N passing, N fixed this run, N need manual attention

Safety Rails

  • Never delete tests to make them pass
  • Prefer fixing source over changing test expectations (unless the test is genuinely wrong)
  • If a fix changes public API behavior, warn the user before applying
  • Max 5 fix iterations total, max 2 attempts per individual failure
  • If no test runner detected and user doesn't provide one, exit with BLOCKED: No test runner found

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free