coverage
Coverage Check
Context
Run in parallel:
git diff --name-only- get unstaged filesgit diff -U0 --no-color- get changed line numbers
Commands
Sequential:
npm run test:ci- vitest with coveragenpm run coverage:report- generate lcov/text reports
Workflow
- Get unstaged files and line ranges (parallel):
git diff --name-onlygit diff -U0 --no-color
- Run coverage:
npm run test:cinpm run coverage:report
- Save diff to a temp file, then run:
git diff -U0 --no-color > /tmp/changes.diff python3 scripts/parse-lcov.py --lcov coverage/lcov.info --diff /tmp/changes.diff - Report uncovered lines from stdout:
file.ts:42 - Summary from stderr: X/Y changed lines covered
LCOV Format
Parse coverage/lcov.info:
SF:src/utils/helper.ts
DA:10,1 # line 10, covered (hit 1 time)
DA:11,0 # line 11, NOT covered
DA:12,5 # line 12, covered (hit 5 times)
end_of_record
Key fields:
SF:-- source file pathDA:line,hits--0= uncovered,>0= coveredend_of_record-- end of file section
Match SF: paths to git diff files. For each changed line, check DA: entry. If hits is 0, report as uncovered.
Anti-Rationalization
| Excuse | Rebuttal |
|---|---|
| "Coverage doesn't guarantee quality" | True, but uncovered code guarantees zero automated verification. |
| "It's just a config change" | Config changes break production too. If there's logic, check coverage. |
| "100% is overkill" | Nobody asked for 100%. Check that changed lines are covered. |
| "The test suite is already green" | Green suite with uncovered changes = false confidence. |
Rules
- Only analyze unstaged changes (
git diff) - Use sequential commands:
test:cithencoverage:report - Use
scripts/parse-lcov.pyto parse lcov data and map to changed lines - Report uncovered lines:
file.ts:42 - Ignore files without coverage data (non-code files)
Error Handling
npm run test:cifails -- report test failures and stopcoverage/lcov.infonot found -- verifycoverage.reporterincludeslcovin test runner configgit diffreturns no changes -- report no unstaged changes to check
More from helderberto/skills
code-review
Review a GitHub Pull Request for bugs, security, performance, and code quality. Use when user asks to review a PR or wants pull request feedback. Don't use for reviewing local uncommitted changes, creating new PRs, or merging branches.
29write-a-skill
Create new agent skills with proper structure and progressive disclosure. Use when user wants to create, write, or build a new skill, or asks "make a skill for X".
22write-a-prd
Create a PRD through user interview, codebase exploration, and module design, saved locally to prds/. Use when user wants to write a PRD, create a product requirements document, or plan a new feature. Don't use for refactoring plans, bug reports, or small changes.
12pr-reply
Draft friendly, concise replies to pull request review comments. Use when user pastes a PR comment, asks to "reply to a PR comment", "/pr-reply", "answer this reviewer", or wants help responding to review feedback. Don't use for posting comments to GitHub, creating new PRs, or reviewing PRs.
2caveman
>
1open-pr
Open current PR in browser. Use when user asks to "open pr", "/open-pr", or wants to open the current pull request in the browser.
1