test-coverage
Skill48 starsChanged 17 days agoMITView on GitHub
Use when test coverage falls below target or a new module has no tests — identifies untested code paths and writes targeted unit or integration tests to close the coverage gap.
20 other projects use a version of this.
Adopted by
Most recently taken up by
- luongnv89/skillstheir own version, first seen Nov 6, 2026
- cognitedata/builder-skillstheir own version, first seen Nov 4, 2026
- vhmarquez/argotheir own version, first seen Oct 15, 2026
- manastalukdar/ai-devstudiotheir own version, first seen Oct 13, 2026
- my-chiefmind/ai-maestrotheir own version, first seen Oct 13, 2026
- wso2/product-apimtheir own version, first seen Oct 8, 2026
Used with
Projects with it also use instinct-export, instinct-import and 7 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
TheKREATORSSkillinstinct-export
Export instincts from project/global scope to a file
Also in 3 projects that use this
TheKREATORSSkillinstinct-import
Import instincts from file or URL into project/global scope
Also in 3 projects that use this
diego-tobalinaSkillbuild-fix
Fix build and compilation errors systematically. Run when build fails.
Also in 3 projects that use this
qtzx06Skilleval
Evaluate trained YOLO model accuracy with mAP metrics and per-class error analysis. Identifies failure cases for targeted improvement. Use after training.
Also in 4 projects that use this
Microsoft AzureSkilliterative-retrieval
Max-3-cycle protocol for agent sub-tasks with WHY context and coordinator validation. Use when spawning sub-agents to complete scoped work.
Also in 3 projects that use this
iovisorSkillevolve
Evolve uBPF through a gated spec-first workflow that propagates approved changes through requirements, design, validation, implementation, and RFC alignment artifacts.
Also in 3 projects that use this
Other versions20 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 20
- cloudposse/atmos★ 1.4ksame name
- wso2/product-apim★ 1ksame name
- LedgerHQ/ledger-live★ 627same name
- luongnv89/skills★ 145same name
- ariadoss/superskills★ 12same name
- Montimage/skills★ 9same name
- cognitedata/builder-skills★ 6same name
- my-chiefmind/ai-maestro★ 6same name
- kartik-nighania/av_claude_code_workshop★ 4same name
- PatriotAgenticLLC/better_claude_skillz★ 3same name
10 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository111 other files it gives its agents.
- AGENTS.mdAGENTS.md
- COPILOT-INSTRUCTIONS.mdCopilot instructions
- .github/copilot-instructions.mdCopilot instructions
- ai-visibilitySkill
- content-strategySkill
- seoSkill
- actions-debuggingSkill
- agentic-engineeringSkill
- autopilot-patternsSkill
- background-agentSkill
- context-primeSkill
- copilot-memorySkill
- cross-session-memorySkill
- ecosystem-intakeSkill
- fleet-parallelSkill
- github-code-searchSkill
- github-codespaces-efficiencySkill
- github-issue-triageSkill
- github-pr-workflowSkill
- ide-switchingSkill
- knowledge-curatorSkill
- mcp-builderSkill
- mcp-ecosystemSkill
- multi-model-strategySkill
- plan-mode-masterySkill
- scope-guardSkill
- session-managementSkill
- stack-detectorSkill
- sub-agent-sandboxingSkill
- task-intake-routerSkill
- team-plannerSkill
- token-cost-optimizerSkill
- api-and-interface-designSkill
- code-reviewSkill
- context-engineeringSkill
- cpp-debuggingSkill
- deprecation-and-migrationSkill
- diagnoseSkill
- fix-build-errorsSkill
- fix-github-issueSkill
- implementSkill
- improve-codebase-architectureSkill
- nestjs-prismaSkill
- nextjs-prismaSkill
- performance-optimizationSkill
- pr-multi-perspective-reviewSkill
- prototypeSkill
- react-vitestSkill
- receiving-code-reviewSkill
- refactor-cleanSkill
- reviewSkill
- skill-creatorSkill
- source-driven-developmentSkill
- spec-driven-developmentSkill
- systematic-debuggingSkill
- tdd-workflowSkill
- zoom-outSkill
- add-to-changelogSkill
- api-documentationSkill
- architecture-decisionsSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
9 rules. 0 are common, 8 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 19 edited versions we read keep these.
8
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 22
Test framework configured with coverage reporting
- Distinctive: line 114
Default cases in switch statements
- Distinctive: line 173
No tests for error paths (catch blocks, failure cases)
- Distinctive: line 176
Only happy path tested, no edge cases
- Distinctive: line 190
Test behavior, not implementation — tests should survive refactoring
- Very specific: line 191
Use explore agent to understand complex functions before writing tests
- Distinctive: line 192
Write the test name first as a sentence describing expected behavior
- Distinctive: line 193
If code is hard to test, it may need refactoring (dependency injection, smaller functions)
- Distinctive: line 194
Add coverage thresholds to CI so coverage can't silently regress
“Common” is measured: kept by at least 6 in 10 of the 19 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Test Coverage Improvement
When to Use
- Coverage reports show critical modules below target thresholds
- New code was merged without sufficient test coverage
- Preparing for a release and need confidence in code correctness
- Refactoring requires a safety net of comprehensive tests
- Team has set a coverage target that needs to be met
Prerequisites
- Test framework configured with coverage reporting
- Baseline coverage report available or generatable
- Understanding of which code is critical vs. low-risk
Workflow
1. Generate a Coverage Report
# Node.js / Jest
npm test -- --coverage 2>&1 | Select-Object -Last 30
# With specific thresholds
npm test -- --coverage --coverageReporters="text" 2>&1
# Python / pytest
pytest --cov=src --cov-report=term-missing 2>&1
# Go
go test -coverprofile=coverage.out ./... && go tool cover -func=coverage.out2. Identify Uncovered Code
# Find files with lowest coverage (Jest text output)
npm test -- --coverage --coverageReporters="text" 2>&1 | Select-String "\d+\.\d+\s*\|" | Sort-Object { [double]($_ -split '\|')[1].Trim().TrimEnd('%') }
# Generate detailed HTML report for visual inspection
npm test -- --coverage --coverageReporters="html"
# Report is in coverage/lcov-report/index.html3. Prioritize What to Test
Focus testing effort where it matters most:
| Priority | What to Cover | Why |
| 🔴 High | Business logic, calculations | Bugs here cost money |
| 🔴 High | Authentication, authorization | Security-critical |
| 🟡 Medium | Data transformations, parsers | Common source of bugs |
| 🟡 Medium | Error handling paths | Often untested, often broken |
| 🟢 Low | Simple getters/setters | Low risk |
| 🟢 Low | UI layout components | Better tested with E2E |
4. Write Targeted Tests
For each uncovered function or branch:
# View the uncovered code
# Coverage report shows line numbers — use view tool to see the code
# Find existing test file (or create one)
glob pattern="**/*moduleName*.test.*"// Test the happy path
describe('calculateDiscount', () => {
it('applies 10% discount for orders over $100', () => {
expect(calculateDiscount(150)).toBe(135);
});
// Test edge cases and branches
it('returns original price for orders under $100', () => {
expect(calculateDiscount(50)).toBe(50);
});
it('handles zero amount', () => {
expect(calculateDiscount(0)).toBe(0);
});
// Test error paths
it('throws for negative amounts', () => {
expect(() => calculateDiscount(-10)).toThrow('Amount must be non-negative');
});
});5. Target Uncovered Branches
# Find conditional logic that may lack branch coverage
grep -n "if\|switch\|? .*:\|&&\|||" src/target-module.tsCommon branch gaps:
elseclausescatchblocks- Default cases in switch statements
- Short-circuit evaluation (
&&,||) - Ternary operators
- Early returns
6. Measure Improvement
# Run coverage again and compare
npm test -- --coverage --collectCoverageFrom="src/target-module.ts" 2>&1
# Verify overall coverage meets target
npm test -- --coverage 2>&1 | Select-String "All files|Statements|Branches"Examples
Cover Error Handling
// Source: src/api/client.ts has uncovered catch block
describe('apiClient.fetch', () => {
it('retries on network error', async () => {
const mockFetch = jest.fn()
.mockRejectedValueOnce(new Error('Network error'))
.mockResolvedValueOnce({ ok: true, json: () => ({ data: 'ok' }) });
const result = await apiClient.fetch('/endpoint', { fetch: mockFetch });
expect(mockFetch).toHaveBeenCalledTimes(2);
expect(result.data).toBe('ok');
});
it('throws after max retries', async () => {
const mockFetch = jest.fn().mockRejectedValue(new Error('Network error'));
await expect(apiClient.fetch('/endpoint', { fetch: mockFetch }))
.rejects.toThrow('Network error');
});
});Using task Agent for Coverage Runs
task agent_type: "task"
prompt: "Run 'npm test -- --coverage' and report the coverage summary. List any files below 80% line coverage."Common Rationalizations
| Rationalization | Reality |
| "80% coverage is good enough" | 80% is the minimum. What matters more is which 20% isn't covered. |
| "100% coverage is impractical" | Core business logic and security-critical code should still target 90%+ branch coverage. |
| "High coverage means high quality" | Coverage measures lines executed, not assertion quality. |
| "This file is hard to test" | Hard-to-test code is a signal of poor design. Improve the interface. |
Red Flags
- High coverage numbers but tests with no assertions (
expect(true).toBe(true)) - No tests for error paths (catch blocks, failure cases)
- Coverage drops when new features are added
- Far fewer test files than source files
- Only happy path tested, no edge cases
Verification
npm run coverageresult meets or exceeds the baseline- Newly added files have ≥80% coverage
- Tests exist for all error handling paths
- Uncovered lines in the coverage report have been reviewed
- Files/paths excluded from coverage are documented
Tips
- Don't chase 100% — aim for 80%+ overall, 90%+ on critical paths
- Cover branches, not just lines — branch coverage catches more bugs
- Test behavior, not implementation — tests should survive refactoring
- Use
exploreagent to understand complex functions before writing tests - Write the test name first as a sentence describing expected behavior
- If code is hard to test, it may need refactoring (dependency injection, smaller functions)
- Add coverage thresholds to CI so coverage can't silently regress
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

