Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add jerseycheese/agent-skills --skill test-fixgit clone --depth 1 https://github.com/jerseycheese/agent-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/jerseycheese/agent-skills/test-fix)<a href="https://agentmods.dev/skills/jerseycheese/agent-skills/test-fix"><img src="https://agentmods.dev/badge/skills/jerseycheese/agent-skills/test-fix.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00091 | $0.01336 |
| Opus 5 | $0.00046 | $0.00668 |
| Sonnet 5 | $0.00018 | $0.00267 |
| Haiku 4.5 | $0.00009 | $0.00134 |
Grade A, and why
test-fix scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 7d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 186 lines — stays where its author put it; the contents beside it link to each section on GitHub.
When to invoke (auto-trigger)
Invoke automatically whenever:
- A test run outputs one or more FAIL results
npm test,jest, orplaywrightexits with a non-zero code due to test failures (not config errors)- The user says tests are broken or a CI check is red on tests
Do NOT invoke for: build errors, type errors, lint failures — those are not test failures. Hard stop at 3 attempts; do not loop.
Test Fix with Attempt Budget
When to Use This Skill
Use this skill when:
- E2E tests are failing
- Unit tests are failing after code changes
- Tests are flaky or intermittent
- Previous fix attempts haven't worked
Critical Rule
Maximum 3 fix attempts per test. After 3 failures, STOP and present options to the user.
Fix Attempt Checklist
For each failing test, follow this process:
Attempt 1: Understand and Fix Obvious Issues
-
Read the test file
- Understand what the test is checking
- Identify all selectors, assertions, and expectations
- Note any timing assumptions (waits, animations, async operations)
-
Identify the failure
- Read the error message carefully
- Determine if it's a selector issue, timing issue, or logic issue
- Check if the test expects specific DOM state
-
Apply the most obvious fix
- Fix broken selectors
- Add necessary waits for async operations
- Update assertions to match current behavior (if behavior is correct)
-
Run the test
- Run ONLY this test, not the full suite
- Document the result: PASS or FAIL (with error)
Attempt 2: Investigate Deeper
If Attempt 1 failed:
-
Read related component source code
- Find the component(s) being tested
- Trace selectors to their definitions
- Look for race conditions or state dependencies
-
Check for environmental issues
- Is the dev server running? (don't restart it)
- Are there dependencies on other tests?
- Are there timing issues with animations or transitions?
-
Apply the fix addressing root cause
- Fix race conditions with proper waits
- Update test to handle async state changes
- Fix component code if bug is there, not in test
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 7d ago First seen · 186 lines · 91 tokens per session scan A fc0ff2908459
test-fix is a skill published in the GitHub repository jerseycheese/agent-skills (1 stars, last pushed 6d ago), licensed MIT. It adds 91 tokens to every session and 1,336 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
test-master
Generates test files, creates mocking strategies, analyzes code coverage, designs test architectures, and produces test plans and defect reports across functional, performance, and security testing disciplines. Use when writing unit tests, integration tests, or E2E tests; creating test strategies or automation…
prodtest
Senior-QA test pass on a newly implemented feature. Detects the project's real test stack, writes unit and functional/integration tests, then drives the running app with Playwright for end-to-end coverage, saving screenshots to a gitignored folder for human review. Asks upfront whether found bugs should be fixed or…
test-agent
You are the Test agent for this project. You own unit, component, integration, and E2E tests, plus test fixtures and test infrastructure.
tdd-workflow
Use this skill when writing new features, fixing bugs, or refactoring code. Enforces test-driven development with 80%+ coverage including unit, integration, and E2E tests.
memstack-development-test-writer
Use this skill when the user says 'write tests', 'add tests', 'test coverage', 'unit tests', 'integration tests', 'component tests', 'mocking', 'edge cases', or needs to generate tests with proper mocking and edge case coverage. Do NOT use for refactoring plans or database migrations.
testing-blocks
Use this when you have made AEM Edge Delivery Services code changes to blocks, scripts, or styles and need to validate them before opening a pull request. Covers unit testing for utilities and logic, browser testing with Playwright, linting, and guidance on what to test and how.