Test Fixing
Systematically triage and repair a broken test suite after implementation or CI failures using grouped root-cause analysis.
Overview
test-fixing is an agent skill most often used in Ship (also Build) that systematically groups failing tests by root cause and fixes them in priority order until the suite passes.
Install
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill test-fixingWhat is this skill?
- Explicit triggers: fix tests, make tests pass, broken suite, post-implementation cleanup, CI failures
- Initial run via `make test` with totals, error types, and affected modules
- Smart grouping by error type, file/module, and root cause (deps, API drift, refactors)
- Priority order: highest blast radius first, infrastructure fixes before behavioral assertions
- Uses `git diff` alongside code reads to tie failures to recent changes
- Documented workflow: run suite, group failures, fix by highest-impact group with git diff checks
Adoption & trust: 574 installs on skills.sh; 40.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your test suite is failing in clusters and you do not know whether to fix imports, API changes, or assertions first.
Who is it for?
Builders with an existing test harness who hit multi-failure regressions after refactors, dependency bumps, or agent-generated code.
Skip if: Greenfield projects with no tests yet, or teams that only want flaky-test quarantine policy without code changes.
When should I use this skill?
Explicitly asked to fix tests, tests are failing or the suite is broken, implementation is complete and tests must pass, or CI/CD failures are test-related.
What do I get? / Deliverables
Failures are grouped, root-caused, and fixed iteratively until `make test` (or your project equivalent) reports green—unblocking CI and release checks.
- Code and test edits that restore a passing suite
- Grouped failure notes showing root cause per cluster
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Failing tests block safe Ship; this skill is shelved under testing because its primary job is restoring suite health before release. Testing is the canonical shelf because the workflow centers on `make test`, failure grouping, and assertion/import fixes—not feature design.
Where it fits
Unblock a release branch when twenty tests fail after an API rename.
Stabilize integration tests right after merging a large agent-generated patch.
Clear CI failures on the tag build before publishing binaries.
How it compares
Use as a systematic repair workflow after failures appear, not as a test generator or coverage booster.
Common Questions / FAQ
Who is test-fixing for?
Solo developers and small teams using Claude Code, Cursor, or Codex who maintain automated tests and need a disciplined fix pass when CI goes red.
When should I use test-fixing?
When you are explicitly asked to fix tests, the suite is broken after implementation, or CI/CD reports failures—in Ship testing gates and late Build regression cleanup.
Is test-fixing safe to install?
It implies running tests and editing code; review the Security Audits panel on this Prism page and use version control so fixes stay reviewable.
SKILL.md
READMESKILL.md - Test Fixing
# Test Fixing Systematically identify and fix all failing tests using smart grouping strategies. ## When to Use - Explicitly asks to fix tests ("fix these tests", "make tests pass") - Reports test failures ("tests are failing", "test suite is broken") - Completes implementation and wants tests passing - Mentions CI/CD failures due to tests ## Systematic Approach ### 1. Initial Test Run Run `make test` to identify all failing tests. Analyze output for: - Total number of failures - Error types and patterns - Affected modules/files ### 2. Smart Error Grouping Group similar failures by: - **Error type**: ImportError, AttributeError, AssertionError, etc. - **Module/file**: Same file causing multiple test failure - **Root cause**: Missing dependencies, API changes, refactoring impacts Prioritize groups by: - Number of affected tests (highest impact first) - Dependency order (fix infrastructure before functionality) ### 3. Systematic Fixing Process For each group (starting with highest impact): 1. **Identify root cause** - Read relevant code - Check recent changes with `git diff` - Understand the error pattern 2. **Implement fix** - Use Edit tool for code changes - Follow project conventions (see CLAUDE.md) - Make minimal, focused changes 3. **Verify fix** - Run subset of tests for this group - Use pytest markers or file patterns: ```bash uv run pytest tests/path/to/test_file.py -v uv run pytest -k "pattern" -v ``` - Ensure group passes before moving on 4. **Move to next group** ### 4. Fix Order Strategy **Infrastructure first:** - Import errors - Missing dependencies - Configuration issues **Then API changes:** - Function signature changes - Module reorganization - Renamed variables/functions **Finally, logic issues:** - Assertion failures - Business logic bugs - Edge case handling ### 5. Final Verification After all groups fixed: - Run complete test suite: `make test` - Verify no regressions - Check test coverage remains intact ## Best Practices - Fix one group at a time - Run focused tests after each fix - Use `git diff` to understand recent changes - Look for patterns in failures - Don't move to next group until current passes - Keep changes minimal and focused ## Example Workflow User: "The tests are failing after my refactor" 1. Run `make test` → 15 failures identified 2. Group errors: - 8 ImportErrors (module renamed) - 5 AttributeErrors (function signature changed) - 2 AssertionErrors (logic bugs) 3. Fix ImportErrors first → Run subset → Verify 4. Fix AttributeErrors → Run subset → Verify 5. Fix AssertionErrors → Run subset → Verify 6. Run full suite → All pass ✓ ## Limitations - Use this skill only when the task clearly matches the scope described above. - Do not treat the output as a substitute for environment-specific validation, testing, or expert review. - Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.