Fix failing tests

Skill Phoenixrr2113/agent-harness/templates/dev/defaults/skills/fix-failing-tests

A file-first agent operating system. Build AI agents by editing markdown files, not writing code. Self-managing, self-improving, durable. Agent Skills compatible.

Install

npx -y skills add Phoenixrr2113/agent-harness --skill fix-failing-tests

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Seven-step flow for diagnosing and fixing failing tests. Use when the user asks to fix failing tests, green the suite, or says 'tests are red' — works through reproduce → read → root-cause → propose → apply → verify → commit.

SKILL.md

2.9 KB, as published. Nobody here has run it

Skill: Fix Failing Tests

When this skill applies

Triggered by the human asking to fix failing tests, green the suite, or a related phrasing.

Step 1 — Reproduce

Work in the assigned worktree (or request one per working-in-a-git-repo). Run the project's test command and identify which files are red, which specific test cases fail, and the assertion that fails with actual vs. expected values.

If no tests are red, STOP — there's nothing to fix. Report back to human.

Step 2 — Read the failing tests

Read the entire test file where failures occur. Understand what behavior is under test and what the system-under-test is supposed to do. Read the production code the test is exercising. Do not guess; read.

Step 3 — Root-cause the failure

Answer: is the bug in the test, or in production code?

Common test-side bugs: hardcoded dates or timestamps going stale, shared state across tests, caching that persists across assertions, mock drift from real implementation.

If I cannot determine root cause in one pass, STOP and surface what I found to the human.

Step 4 — Propose the minimal fix

State in one paragraph:

What I'm changing
Which file(s)
Why it resolves the failure without altering unintended behavior

Wait for the human's acknowledgement on non-trivial changes. For clear test-only fixes with no production impact, proceed.

Step 5 — Apply the fix

ONE file at a time.
Specific lines only. Never rewrite a whole file for a spot change.
Follow existing patterns — check nearby tests for how they handle the same concern (mocking time, fixtures, setup/teardown).

Step 6 — Verify

All three must pass:

Targeted suite green.
Full suite green (or no new failures beyond pre-existing unrelated ones).
Linter: no new errors.

If any fail, debug before proceeding. Do not commit red tests.

Step 7 — Commit & report

Commit on the feature branch with a message matching project style.
Report to the human: branch name, commit SHA, files changed, one-line summary.
DO NOT push. DO NOT open a PR. DO NOT merge to main.

Failure handling

If root cause is ambiguous → STOP, ask human.
If the fix would require production-code changes (not just tests) → STOP, describe what's needed, ask human.
If environment-specific issues emerge (CI git config, Node version, etc.) → note them and proceed where possible.