test-coverage
Skill1 starsChanged 7 months agoMITView on GitHub
Analyze test coverage and suggest tests for uncovered code
- Installs packages
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
- drvoss/everything-copilot-clitheir own version, first seen Oct 26, 2026
- vhmarquez/argotheir own version, first seen Oct 15, 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 10 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
HABUBUSSSkilleval-harness
Also in 5 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
- +1 more from TheKREATORS
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
- drvoss/everything-copilot-cli★ 48same 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
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 repository206 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- project-healthSkill
- skill-validatorSkill
- accessibilitySkill
- agent-debugSkill
- agent-evaluateSkill
- ai-governanceSkill
- ai-system-reviewSkill
- api-docs-generateSkill
- api-examplesSkill
- api-mockSkill
- api-test-generateSkill
- api-validateSkill
- architecture-diagramSkill
- ask-mattSkill
- assumption-mapSkill
- boilerplateSkill
- brainstormSkill
- branch-finishSkill
- briefingSkill
- browser-testing-with-devtoolsSkill
- bundle-analyzeSkill
- cache-strategySkill
- canarySkill
- carefulSkill
- cavemanSkill
- changelog-autoSkill
- chaos-testSkill
- ci-setupSkill
- ci-sweepSkill
- cleanprojectSkill
- click-path-auditSkill
- codebase-designSkill
- code-review-checklistSkill
- code-tourSkill
- commitSkill
- completion-verifySkill
- complexity-reduceSkill
- component-librarySkill
- config-cleanupSkill
- config-generateSkill
- conflict-resolveSkill
- container-optimizeSkill
- context-budgetSkill
- context-engineeringSkill
- context-restoreSkill
- context-saveSkill
- continuous-learningSkill
- contributingSkill
- cost-trackSkill
- councilSkill
- create-todosSkill
- cross-modal-reviewSkill
- database-connectSkill
- db-diagramSkill
- ddd-modelSkill
- debug-root-causeSkill
- debug-sessionSkill
- debug-systematicSkill
- The first 60 shown.
The file
Show its rules and text
We split this skill into the rules it gives an agent
13 rules. 0 are common, 10 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 19 edited versions we read keep these.
10
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 16
Before starting, I'll verify:
- Distinctive: line 17
Test framework and coverage tool availability
- Distinctive: line 23
When analyzing test coverage:
- Distinctive: line 452
Write comprehensive test cases
- Distinctive: line 455
Add comments explaining edge cases
- Distinctive: line 468
No false positives (tests that pass without testing)
- Very specific: line 475
After /test runs → Check coverage with /test-coverage
- Very specific: line 476
After /scaffold → Ensure new code has tests
- Very specific: line 477
Before /commit → Verify coverage thresholds met
- Distinctive: line 588
Test implementation details instead of behavior
- Distinctive: line 589
Add AI attribution to commits or code
- Distinctive: line 590
Create tests that give false confidence
- Distinctive: line 597
Create clear commit messages (no AI attribution)
“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 Analysis & Enhancement
I'll analyze your test coverage, identify untested code paths, and suggest comprehensive tests for uncovered areas.
Arguments: $ARGUMENTS - specific paths or coverage focus areas
Phase 1: Coverage Tool Detection
Pre-Flight Checks: Before starting, I'll verify:
- Test framework and coverage tool availability
- Existing test configuration
- Coverage thresholds and requirements
- CI/CD coverage reporting setup
<think>
When analyzing test coverage:
- Line coverage is basic but can be misleading (executes but doesn't assert)
- Branch coverage reveals untested conditionals and error paths
- Function coverage shows unused functionality
- Statement coverage differs from line coverage (multiple statements per line)
- 100% coverage doesn't guarantee quality - need meaningful assertions
- Uncovered code often hides edge cases and error handling
</think>Coverage Tool Detection:
# Auto-detect coverage tooling
detect_coverage_tool() {
if [ -f "package.json" ]; then
# JavaScript/TypeScript ecosystem
if grep -q "jest" package.json; then
echo "jest --coverage"
elif grep -q "vitest" package.json; then
echo "vitest --coverage"
elif grep -q "c8" package.json; then
echo "c8"
elif grep -q "nyc" package.json || grep -q "istanbul" package.json; then
echo "nyc"
fi
elif [ -f "pyproject.toml" ] || [ -f "setup.py" ]; then
# Python ecosystem
if grep -q "pytest-cov" pyproject.toml setup.py requirements.txt 2>/dev/null; then
echo "pytest-cov"
elif command -v coverage >/dev/null 2>&1; then
echo "coverage"
fi
elif [ -f "go.mod" ]; then
# Go has built-in coverage
echo "go test -cover"
elif [ -f "Gemfile" ]; then
# Ruby ecosystem
if grep -q "simplecov" Gemfile; then
echo "simplecov"
fi
elif [ -f "pom.xml" ] || [ -f "build.gradle" ]; then
# Java ecosystem
echo "jacoco"
fi
}
COVERAGE_TOOL=$(detect_coverage_tool)
if [ -z "$COVERAGE_TOOL" ]; then
echo "No coverage tool detected. Suggestions:"
echo " - JavaScript: npm install --save-dev jest (includes coverage)"
echo " - Python: pip install pytest-cov"
echo " - Go: Built-in (go test -cover)"
echo " - Ruby: gem install simplecov"
exit 1
fi
echo "Detected coverage tool: $COVERAGE_TOOL"Coverage Report Generation: I'll use bash to run coverage and parse reports efficiently:
# Generate coverage report with minimal output formats
case "$COVERAGE_TOOL" in
"jest --coverage")
# Only generate JSON summary (skip HTML report generation)
npm test -- --coverage --coverageReporters=json-summary 2>&1 | tail -20
;;
"pytest-cov")
# Only generate JSON report (skip HTML)
pytest --cov=. --cov-report=json --cov-report=term-missing:skip-covered 2>&1 | tail -20
;;
"go test -cover")
go test -coverprofile=coverage.out ./... 2>&1
go tool cover -func=coverage.out | tail -20
;;
esac
# Parse coverage summary (avoid reading thousands of lines of HTML)
if [ -f "coverage/coverage-summary.json" ]; then
# Jest/NYC format - extract just total metrics
jq -c '.total' coverage/coverage-summary.json
elif [ -f "coverage.json" ]; then
# pytest-cov format - extract just summary
jq -c '.totals' coverage.json
fiThis gets coverage metrics without reading thousands of lines of HTML reports, saving 90%+ tokens.
Phase 2: Coverage Metrics Analysis
I'll analyze multiple coverage dimensions:
- Line Coverage
- Percentage of lines executed
- Identifies completely untested files
- Branch Coverage
- Percentage of if/else, switch paths tested
- More meaningful than line coverage
- Function Coverage
- Percentage of functions called
- Identifies unused code
- Statement Coverage
- More granular than line coverage
- Multiple statements per line counted separately
Coverage Report Parsing:
# Extract low-coverage files for targeted analysis
parse_low_coverage_files() {
if [ -f "coverage/coverage-summary.json" ]; then
# Extract files with <80% coverage
jq -r 'to_entries[] |
select(.value.lines.pct < 80) |
"\(.key): \(.value.lines.pct)% lines, \(.value.branches.pct)% branches"' \
coverage/coverage-summary.json
fi
}
LOW_COVERAGE_FILES=$(parse_low_coverage_files)Coverage Threshold Checking:
# Check if project has coverage requirements
check_coverage_thresholds() {
# Jest configuration
if [ -f "jest.config.js" ] || [ -f "jest.config.json" ]; then
grep -A 10 "coverageThreshold" jest.config.* 2>/dev/null
fi
# pytest configuration
if [ -f "pyproject.toml" ]; then
grep -A 5 "fail_under" pyproject.toml 2>/dev/null
fi
# Go coverage threshold (custom)
if [ -f ".coverage-threshold" ]; then
cat .coverage-threshold
fi
}
THRESHOLDS=$(check_coverage_thresholds)Phase 3: Uncovered Code Identification
Strategic File Analysis:
I'll focus on files with coverage gaps using Grep before full Read:
# Find uncovered functions in low-coverage files (JavaScript/TypeScript)
Grep pattern="^(export )?(async )?function \w+"
glob="$LOW_COVERAGE_FILE_PATTERN"
output_mode="content"
head_limit=15
-n=true
# Find uncovered classes in low-coverage files (Python)
Grep pattern="^class \w+"
glob="$LOW_COVERAGE_FILE_PATTERN"
output_mode="content"
head_limit=15
-n=true
# Find error handling that might be uncovered
Grep pattern="throw new|raise |catch \(|except "
glob="$LOW_COVERAGE_FILE_PATTERN"
output_mode="content"
head_limit=10Uncovered Code Patterns I'll Identify:
- Error Handling Paths
try { await operation(); } catch (error) { // UNCOVERED: Error path not tested logger.error(error); throw new CustomError(error); } - Edge Cases in Conditionals
if (value > 100) { return 'high'; } else if (value > 50) { return 'medium'; } else { return 'low'; // UNCOVERED: Never tested } - Validation Logic
def validate_input(data): if not data: raise ValueError("Data required") # UNCOVERED if not isinstance(data, dict): raise TypeError("Dict required") # UNCOVERED return True - Async Error Paths
async function fetchData(url) { if (!url) { throw new Error('URL required'); // UNCOVERED } const response = await fetch(url); if (!response.ok) { throw new Error('Fetch failed'); // UNCOVERED } return response.json(); } - Default/Fallback Cases
switch (action.type) { case 'CREATE': return handleCreate(action); case 'UPDATE': return handleUpdate(action); default: return state; // UNCOVERED: Default case not tested }
Phase 4: Missing Test Identification
I'll identify critical gaps:
- Untested Public APIs
# Find exported functions EXPORTED_FUNCTIONS=$(Grep pattern="^export (async )?function (\w+)" glob="src/**/*.{js,ts}" output_mode="content" head_limit=20) # Check which ones lack tests (bash comparison) echo "$EXPORTED_FUNCTIONS" | while read -r line; do FUNC_NAME=$(echo "$line" | grep -oP "function \K\w+") # Quick Grep check in test files HAS_TEST=$(Grep pattern="$FUNC_NAME" glob="**/*.{test,spec}.*" output_mode="files_with_matches" head_limit=1) [ -z "$HAS_TEST" ] && echo "UNTESTED: $FUNC_NAME" done - Untested Error Scenarios
# Find error throwing code in low-coverage files Grep pattern="throw new|raise |throw Error" glob="$LOW_COVERAGE_FILE_PATTERN" output_mode="content" head_limit=15 -n=true - Untested Edge Cases
- Empty array/object handling
- Null/undefined checks
- Boundary values (0, -1, MAX_INT)
- Invalid input types
- Integration Points
- API endpoints
- Database operations
- External service calls
- File system operations
Phase 5: Test Suggestions & Generation
For each uncovered area, I'll suggest tests:
Example: Uncovered Error Path
// Uncovered code in src/user-service.js:
async function createUser(data) {
if (!data.email) {
throw new Error('Email required'); // UNCOVERED
}
return db.users.create(data);
}
// Suggested test:
describe('UserService.createUser', () => {
it('should throw error when email is missing', async () => {
await expect(createUser({ name: 'Test' }))
.rejects.toThrow('Email required');
});
it('should throw error when email is null', async () => {
await expect(createUser({ email: null, name: 'Test' }))
.rejects.toThrow('Email required');
});
it('should throw error when email is empty string', async () => {
await expect(createUser({ email: '', name: 'Test' }))
.rejects.toThrow('Email required');
});
});Example: Uncovered Branch
# Uncovered code in src/calculator.py:
def divide(a, b):
if b == 0:
raise ValueError("Cannot divide by zero") # UNCOVERED
return a / b
# Suggested test:
def test_divide_by_zero():
"""Test division by zero raises ValueError"""
with pytest.raises(ValueError, match="Cannot divide by zero"):
divide(10, 0)
def test_divide_by_negative():
"""Test division by negative number"""
assert divide(10, -2) == -5.0
def test_divide_floats():
"""Test division with floating point precision"""
assert abs(divide(1, 3) - 0.333333) < 0.00001Example: Uncovered Edge Case
// Uncovered code in src/array-utils.js:
function getFirst(arr) {
return arr[0]; // What if arr is empty? UNCOVERED
}
// Suggested tests:
describe('getFirst', () => {
it('should return first element of array', () => {
expect(getFirst([1, 2, 3])).toBe(1);
});
it('should return undefined for empty array', () => {
expect(getFirst([])).toBeUndefined();
});
it('should handle single-element array', () => {
expect(getFirst([42])).toBe(42);
});
it('should return first element even if falsy', () => {
expect(getFirst([0, 1, 2])).toBe(0);
expect(getFirst([null, 1, 2])).toBeNull();
});
});Phase 6: Coverage Improvement Strategy
Prioritization Framework:
I'll prioritize test additions based on:
- Risk Level (Critical → Low)
- Critical: Security, data integrity, financial logic
- High: Core business logic, user-facing features
- Medium: Utility functions, helpers
- Low: Logging, formatting, trivial getters
- Impact (High → Low)
- High: Code used frequently, critical paths
- Medium: Occasional use, important features
- Low: Rarely used, edge features
- Effort (Low → High)
- Low: Simple unit tests, pure functions
- Medium: Mocked integration tests
- High: Complex integration/E2E tests
Coverage Improvement Plan:
COVERAGE IMPROVEMENT STRATEGY
==============================
Phase 1: Critical Uncovered Code (Priority: High Risk + High Impact)
├── auth/login.js:45-52 - Error handling in authentication
├── payment/process.js:78-85 - Failed payment scenarios
└── user/validate.js:23-30 - Input validation edge cases
Phase 2: Important Features (Priority: High Impact + Low Effort)
├── api/users.js:120-135 - User creation edge cases
├── utils/format.js:45-60 - Edge cases in formatting
└── services/email.js:89-95 - Email send failure handling
Phase 3: Code Quality (Priority: Medium Impact + Low Effort)
├── helpers/string.js:12-25 - String utility edge cases
├── models/user.js:67-72 - Model validation
└── config/parser.js:34-40 - Config parsing errors
Phase 4: Comprehensive Coverage (Priority: Low Risk + Low Effort)
├── utils/constants.js - Getter coverage
├── types/validators.js - Type checking edge cases
└── formatters/date.js - Date formatting edge casesPhase 7: Test Generation & Implementation
I'll generate and add tests:
- Create git checkpoint
git add -A git commit -m "Pre test-coverage-improvement checkpoint" || echo "No changes" - Generate tests for uncovered code:
- Write comprehensive test cases
- Cover all branches and edge cases
- Include descriptive test names
- Add comments explaining edge cases
- Verify coverage improvement:
# Run tests with coverage npm test -- --coverage # Compare before/after coverage echo "Coverage improved from X% to Y%" - Validate test quality:
- Tests actually assert behavior
- No false positives (tests that pass without testing)
- Good test organization and naming
- Proper setup/teardown
Integration with Existing Skills
Workflow Integration:
- After
/testruns → Check coverage with/test-coverage - After
/scaffold→ Ensure new code has tests - Before
/commit→ Verify coverage thresholds met - During
/review→ Include coverage analysis - With
/test-async→ Cover async edge cases - With
/test-antipatterns→ Quality + coverage together
Skill Suggestions:
- Low coverage in complex async →
/test-async - Coverage but poor quality →
/test-antipatterns - New feature needs tests →
/tdd-red-green - Complex uncovered logic →
/explain-like-senior
Reporting
I'll provide comprehensive coverage analysis:
TEST COVERAGE ANALYSIS REPORT
==============================
CURRENT COVERAGE:
├── Lines: 78.5% (target: 80%)
├── Branches: 65.2% (target: 75%)
├── Functions: 82.1% (target: 85%)
└── Statements: 77.8% (target: 80%)
FILES BELOW THRESHOLD:
├── src/auth/login.js: 45.2% (critical!)
├── src/payment/process.js: 52.8% (critical!)
├── src/api/users.js: 71.3%
├── src/utils/validate.js: 68.9%
└── src/helpers/format.js: 74.5%
UNCOVERED CRITICAL CODE:
├── Error handling paths: 23 instances
├── Edge case branches: 18 instances
├── Validation logic: 12 instances
└── Async error paths: 8 instances
TESTS SUGGESTED:
├── Authentication error scenarios: 8 tests
├── Payment failure handling: 6 tests
├── Input validation edge cases: 12 tests
├── API error responses: 10 tests
└── Utility function edge cases: 15 tests
AFTER IMPROVEMENTS:
├── Lines: 78.5% → 87.3% (+8.8%)
├── Branches: 65.2% → 81.7% (+16.5%)
├── Functions: 82.1% → 91.2% (+9.1%)
└── Statements: 77.8% → 86.9% (+9.1%)
TESTS ADDED: 51 new tests
FILES MODIFIED: 12 test files
EXECUTION TIME: +2.3s (acceptable)
NEXT STEPS:
├── Run tests to verify all pass
├── Review generated tests for quality
├── Update CI/CD coverage thresholds
└── Document testing coverage requirementsCoverage Tools Configuration
I can help set up coverage tools:
Jest (JavaScript/TypeScript):
{
"jest": {
"collectCoverage": true,
"coverageDirectory": "coverage",
"coverageReporters": ["text", "lcov", "json-summary"],
"coverageThreshold": {
"global": {
"lines": 80,
"branches": 75,
"functions": 85,
"statements": 80
}
},
"collectCoverageFrom": [
"src/**/*.{js,ts}",
"!src/**/*.d.ts",
"!src/**/*.test.{js,ts}"
]
}
}pytest-cov (Python):
[tool.pytest.ini_options]
addopts = "--cov=src --cov-report=term-missing --cov-report=html --cov-fail-under=80"
[tool.coverage.run]
omit = ["*/tests/*", "*/test_*.py"]
[tool.coverage.report]
exclude_lines = [
"pragma: no cover",
"def __repr__",
"raise NotImplementedError"
]Safety Guarantees
What I'll NEVER do:
- Generate tests that don't actually test
- Lower coverage thresholds to "pass"
- Test implementation details instead of behavior
- Add AI attribution to commits or code
- Create tests that give false confidence
What I WILL do:
- Generate meaningful, behavior-focused tests
- Cover edge cases and error paths
- Improve actual code quality, not just metrics
- Maintain test maintainability
- Create clear commit messages (no AI attribution)
Credits
This skill is based on:
- Istanbul/nyc - JavaScript coverage tool standards
- Jest - Built-in coverage capabilities
- pytest-cov - Python coverage testing
- JaCoCo - Java code coverage library
- SimpleCov - Ruby coverage analysis
- Testing Best Practices - Community-driven coverage guidelines
Token Optimization
Expected range: 1,200–2,000 tokens (initial), 200 tokens (coverage good)
Caching: Caches coverage tool detection in .claude/cache/test-coverage/tool.json for 7 days. Invalidated when package.json changes.
Early exit: Returns immediately if all coverage thresholds are already met.
Patterns used: Grep-before-Read, early exit, Bash for system queries, caching
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
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.

