coverage-gap-finderlisted

Turn a raw coverage report into a ranked, actionable plan. This skill runs the project's existing coverage tool, reads the per-line and per-branch data, and surfaces the gaps that actually matter — uncovered error handlers, unguarded edge cases, and critical modules with thin coverage — rather than nudging an arbitrary percentage upward. For each gap it proposes concrete, named test cases you can hand straight to a scaffolder. The goal is risk reduction per test written, not a green 100% badge. ## When to use this skill - You have (or can generate) a coverage report but don't know which untested lines are worth testing first. - A module is business-critical and you want to confirm its error paths and edge cases are exercised. - You're triaging tech debt and need a prioritized list of test gaps instead of a wall of red lines. > [!NOTE] > Line coverage measures *executed* lines, not *correct* behavior. A function can be 100% covered by a test that asserts nothing. Treat coverage as a map of blind spots, not a quality score — prioritize gaps by blast radius, then verify the new tests actually assert something. ## Instructions 1. **Detect the test stack and coverage tool.** Do not guess — inspect the project: - JS/TS: `package.json` for `vitest --coverage` / `jest --coverage` (look for `coverage` scripts or a `c8`/`nyc`/`@vitest/coverage-v8` dep). - Python: `pytest --cov` (`pytest-cov`), `coverage run`, config in `pyproject.toml`/`.coveragerc`. - Go: `go test -cover