
Fix Tests
Orchestrate a structured pass to repair failing tests after refactors or dependency updates without silently rewriting product logic.
Overview
Fix Tests is an agent skill most often used in Ship (also Build after refactors) that systematically repairs failing tests to match current implementation while preserving intent.
Install
npx skills add https://github.com/neolabhq/context-engineering-kit --skill fix-testsWhat is this skill?
- Discovers test commands from README and package.json (or equivalent project config)
- Fix tests to match current business logic—avoid drive-by production changes unless unavoidable
- Complexity gate: 2+ changed files or complex logic → orchestrate agents; single simple file → may fix directly
- Optional integration with sadd skill for agent orchestration best practices
- Accepts `$ARGUMENTS` to scope modules or suites when not fixing everything
- Complexity gate at 2+ changed files triggers agent orchestration only
Adoption & trust: 531 installs on skills.sh; 1.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You changed code or dependencies and now dozens of tests fail, and ad-hoc fixes risk rewriting business logic or leaving suites misleading.
Who is it for?
Post-refactor or post-upgrade recovery when you know product behavior is correct but assertions, mocks, or fixtures are stale.
Skip if: Greenfield test authoring from scratch, defining acceptance criteria, or large behavior changes disguised as test fixes.
When should I use this skill?
Systematically fix all failing tests after business logic changes or refactoring
What do I get? / Deliverables
Failing tests are identified, scoped, and fixed or agent-orchestrated until the project's test and coverage commands reflect current behavior.
- Passing project test command output
- Tests updated to reflect current behavior without abandoned intent
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Test repair is canonically a Ship concern—green suites gate release—but it is triggered right after Build refactors. Testing subphase covers discovering runners, coverage commands, and aligning assertions with current behavior.
Where it fits
After renaming an internal API module, run Fix Tests to realign mocks without redesigning endpoints.
CI fails on integration tests following a dependency bump—discover runners from README then repair assertions.
Before merging a refactor PR, scope Fix Tests to the touched package so reviewers see a green suite.
Production fix shipped; run Fix Tests on the hotfix branch so regression tests match the new behavior.
How it compares
A Ship-phase test-repair workflow—not a one-shot linter rule or a mock-data generator.
Common Questions / FAQ
Who is fix-tests for?
Solo and indie devs using agentic IDEs who need a repeatable ritual after merges or refactors instead of guessing which tests to touch.
When should I use fix-tests?
In Ship when CI is red after logic changes; in Build immediately after a refactor PR when local suites fail; optionally with arguments to focus one module.
Is fix-tests safe to install?
It can drive test edits and agent delegation—review the Security Audits panel on this page and keep changes in version control with your usual review bar.
SKILL.md
READMESKILL.md - Fix Tests
# Fix Tests ## User Arguments User can provide to focus on specific tests or modules: ``` $ARGUMENTS ``` If nothing is provided, focus on all tests. ## Context After business logic changes, refactoring, or dependency updates, tests may fail because they no longer match the current behavior or implementation. This command orchestrates automated fixing of all failing tests using specialized agents. ## Goal Fix all failing tests to match current business logic and implementation. ## Important Constraints - **Focus on fixing tests** - avoid changing business logic unless absolutely necessary - **Preserve test intent** - ensure tests still validate the expected behavior - "Analyse complexity of changes" - - if there 2 or more changed files, or one file with complex logic, then **Do not write tests yourself** - only orchestrate agents! - if there is only one changed file, and it's a simple change, then you can write tests yourself. ## Workflow Steps ### Preparation 1. **Read sadd skill if available** - If available, read the sadd skill to understand best practices for managing agents 2. **Discover test infrastructure** - Read @README.md and package.json (or equivalent project config) - Identify commands to run tests and coverage reports - Understand project structure and testing conventions 3. **Run all tests** - Execute full test suite to establish baseline 4. **Identify all failing test files** - Parse test output to get list of failing test files - Group by file for parallel agent execution ### Analysis 5. **Verify single test execution** - Choose any test file - Launch haiku agent with instructions to find proper command to run this only test file - Ask him to iterate until you can reliably run individual tests - After he complete try running a specific test file if it exists - This ensures agents can run tests in isolation ### Test Fixing 6. **Launch `developer` agents (parallel)** - Launch one agent per failing test file - Provide each agent with clear instructions: * **Context**: Why this test needs fixing (business logic changed) * **Target**: Which specific file to fix * **Guidance**: Read TDD skill (if available) for best practices how to write tests. * **Resources**: Read README and relevant documentation * **Command**: How to run this specific test file * **Goal**: Iterate until test passes * **Constraint**: Fix test, not business logic (unless clearly broken) 7. **Verify all fixes** - After all agents complete, run full test suite again - Verify all tests pass 8. **Iterate if needed** - If any tests still fail: Return to step 5 - Launch new agents only for remaining failures - Continue until 100% pass rate ## Success Criteria - All tests pass ✅ - Test coverage maintained - Test intent preserved - Business logic unchanged (unless bugs found) ## Agent Instructions Template When launching agents, use this template: ``` The business logic has changed and test file {FILE_PATH} is now failing. Your task: 1. Read the test file and understand what it's testing 2. Read TDD skill (if available) for best practices on writing tests. 3. Read @README.md for project context 4. Run the test: {TEST_COMMAND} 5. Analyze the failure - is it: - Test expectations outdated? → Fix test assertions - Test setup broken? → Fix test setup/mocks - Business logic bug? → Fix logic (rare case) 6. Fix the test and verify it passes 7. Iterate until test passes ```