Hire an AI failed test repairer

Everything it can hand back

Your task sets the actual outputs. The specialist picks the methods that cover them.

• The failures before and after, with a full final run
• One line per round, with the group, cause, change and result
• A diff of the changes, left uncommitted for you
• A list of what is still failing and the decision each one needs

How it does the job well

• Read the existing code, its conventions and its tests before changing anything. Match the project's patterns.
• Make the smallest change that fully solves the request. Keep unrelated refactors out.
• Reproduce a bug before fixing it, and add a test that fails without the fix.
• Treat input from users, files and networks as untrusted. Validate it at the boundary.

Mistakes it avoids

• Making a test pass by weakening it.
• Fixing several groups in one round, so nobody can tell which change worked.
• Retrying a flaky test until it goes green.
• Starting a sixth round because "one more try" looks close.
• Calling the work done without a full run.
• Claiming code works without running it or its tests.

What a good result looks like

An example, not your task: Your tests are red after a change and you want them fixed without the guesswork.

• RESULT. Green, partly fixed or stopped, with the number of failures before and after.
• ROUNDS. One line per round with the failure group, the cause, the change and the result.
• CHANGES MADE. The files changed and why, left uncommitted so you can read the full diff.
• STILL FAILING. Each remaining test, its cause and the decision it needs from you.
• FLAKY FOUND. Tests added to the flaky list because the cause sits outside the code.
• CHECKS AND MISSING. The lint and type check result, then every MISSING line.

How the work is checked

• The final full run is shown, with its count.
• No test was skipped, deleted or loosened.
• No group had more than 3 tries and the rounds did not pass the limit.
• Every change maps to a failure group.
• States which checks passed, failed or could not run, and names missing inputs.

These checks have not been run against a model yet. Your AI uses them to check its own work.

Capabilities

• Take a baseline. Runs the full suite and saves the failing tests, so every later round is compared with the start.
• Set the limits. Five rounds in total and three tries on any one group of failures. It also stops if two rounds in a row make no progress.
• Choose a path. A failure only in the pull request check gets the cause found first. A flaky browser test gets a flaky-test fix. The rest are grouped and fixed by cause.
• Fix one group, then check. Runs that group, then the full suite, and counts what was fixed, what still fails and what is new.
• Decide from the result. Proves the cause when it is unsure, applies the three-try budget when a failure comes back, and undoes a fix that breaks other tests.
• Stop and run the project checks. Stops at green or at a limit. When green, runs your lint and type checks once.

How the role works

1. Checks your task, context and available tools.
2. Picks the methods needed and prepares a work plan.
3. Carries out supported tasks, with each method's limits and review gates.
4. Checks the real deliverables and corrects supported faults.
5. Hands back files, evidence and unresolved gaps.

Your specialist's working setup

Download the base specialist without a task form or account. README.md and SETUP.md explain how to use the folder. SOUL.md defines its scope. INTAKE.md asks missing questions inside your AI. PLAYBOOK.md, SKILLS.md, BEST_PRACTICES.md, CHECKS.md and HANDOFF.md guide the work and its checked deliverables.

Complete associated skills, supporting files and licences are included. Choose only the methods needed for the actual task. Keep context, working files and accepted feedback in your AI project.

Use this specialist through MCP or the API

Call prepare_specialist with role_id test-failure-repair-loop only. No task is required to load it. Your AI asks what job you need done, what you want back and which relevant context it can use.

For task-led hiring, call find_specialist, explain the suggested specialists and let the user accept or change the team.

Complete ZIP: Download base specialist. API: GET /api/v1/specialists/test-failure-repair-loop/pack. The host AI supplies its own model, tools and execution; a pack does not connect accounts or run a task.

Inputs and helpful context

The specialist starts from the task brief. Only active methods require their inputs.

For the primary method, when used

• The code, in a folder or repository it can run
• The command that runs your tests
• The failing output or the failed check, if you have it (optional)
• A list of tests you already know are flaky (optional)

Helpful context (optional)

• The failing test output or the failed check log
• A list of tests you already know are flaky

Tools and access

• Claude Code: It can run your tests, edit the code and keep the fixer folder between runs.
• GitHub: It can read a failed pull request check so the cause is found before any edit.

Functions and deliverables

• Failed test repairer: Fix one group of test failures at a time. Re-run meaningful checks and stop at clear limits without weakening tests.
  • The failures before and after, with a full final run
  • One line per round, with the group, cause, change and result
  • A diff of the changes, left uncommitted for you
  • A list of what is still failing and the decision each one needs
• Failing test fixer: Share a broken test suite. Get failures grouped by cause and fixed one group at a time.
  • Failures grouped by cause
  • Small focused code fixes
  • A re-run result after each group
  • A final full-suite result
  Source: sickn33.
• GitHub check failure fixer: Share a failing pull request. Get the cause of the failed GitHub check and a fix plan.
  • A list of failing checks
  • The error lines from each log
  • A likely cause
  • A fix plan to approve
  Source: OpenAI.
• Flaky test fixer: Find why your Playwright test is flaky and get it fixed. Give it a failing test and it finds the cause, fixes it and proves it stays stable.
  • Reproduction of the failure
  • Cause sorted into one of four types
  • Fix applied to the test
  • Repeat-run results showing it is stable
  Source: Alireza Rezvani.
• Bug root cause finder: Use failing tests and code to investigate a bug, then review its cause before fixes.
  • The exact error captured
  • A narrowed-down location
  • A root cause for your approval
  • A minimal fix after you agree
  • Proof that tests pass
  Source: sickn33.
• Persistent bug debugger: Share a bug that keeps failing and its evidence. Get a bounded repair, verification log and rollback check, or a clear stop decision.
  • Repair contract with baseline result
  • Log of up to three attempts with evidence
  • Check that fails on bad state and passes on the fix
  • Tested rollback
  • Final status: PROVEN, INCONCLUSIVE or BLOCKED
  Source: sickn33.
• Lint and type check runner: Run your project's lint and type checks after a change. Get a clear pass or fail, plus a plain line for any check that never ran.
  • Results of each lint and type check
  • Fixes for real failures
  • A list of checks that did not run
  • The commands used and their exit results
  Source: sickn33.
• AI project context organiser: Share your project and next task. Get a short rules file, a focused file list and a clear handoff for later sessions.
  • A ready rules file for your project
  • A list of which files to load for each task
  • Rules for when to reset or trim the session
  • A checklist for spotting drifting answers
  Source: Addy Osmani.

Tasks you can use it for

• Your tests are red after a change and you want them fixed without the guesswork.
• A pull request check fails and you do not know why.
• You have flaky browser tests and want the cause fixed, not retries added.

Limits to check before starting

• Your suite is already green. There is nothing to fix, so run your normal checks instead.
• You have one known bug you can fix yourself. Make the change by hand and run the tests once.
• The failure has no test output at all. Use the Bug root cause finder skill first, or a debugger, to find the cause.

Best way to use this role

Give it one clear outcome, the actual files and a definition of done. Keep the work in one AI project so it can reuse checked context and earlier files.

• Start a chat with the agent. In Claude Code, add it as a skill or save it in .claude/agents, then point it at your project.
• Tell it the test command the first time. It saves it.
• Let it run. It stops by itself at the limit.
• Read the diff and the list of what is still failing. Decide on any test that looks out of date.
• Commit the changes yourself when you are happy. It will not.

Read it as data

Read the complete role setup as JSON. Connect your AI to the AI Blocks MCP library and read aiblocks://roles/test-failure-repair-loop for its role instructions and pinned sources.

This is a prepared AI role. No task has run. Your AI carries out authorized work using its available tools and reports the actual deliverables and checks.