test-gap-finderlisted

# Test gap finder Coverage percentage is a bad target and a useful signal. The number says nothing about risk; *which* lines are uncovered, and how often those lines change, says a great deal. This skill exists because the obvious approach — sort by lowest coverage, write tests from the top — spends its effort on the files nobody touches. A file at 40% that has not changed in two years is stable by demonstration. A file at 85% that changes every week is where the next incident comes from. ## Procedure ### 1. Rank the gaps `<skill-dir>` is the directory this SKILL.md was loaded from — the skill installs outside your project, so its script is named by full path, never relatively. ``` python3 <skill-dir>/scripts/coverage_gaps.py # auto-detects a coverage report python3 <skill-dir>/scripts/coverage_gaps.py --since 1.year # widen or narrow the churn window ``` The script finds a coverage summary (`coverage/coverage-summary.json` and the usual alternatives), counts commits per file over the churn window, and ranks by **uncovered lines × commits**. It prints the top gaps with both numbers visible, so the ranking can be argued with rather than taken on faith. **With no coverage report it says so** and falls back to structural pairing: source files with no corresponding test file, ranked by the same churn. State clearly which of the two modes produced your answer — they are not equally trustworthy, and a reader who assumes real coverage data when there was non