Fill gaps from a coverage report

Point Claude Code at your coverage report and a target percentage; it adds tests to the lowest-covered files and shows the before and after numbers.

Task: Fill gaps from a coverage report · Other tasks

Fill in the details

Coverage report (required)

A report file in the project. Generate a fresh one before you start.

Target coverage per file, in percent (required)

Coverage metric

Command that regenerates the report

Optional. Leave empty and Claude will look for how the report is produced.

Files or folders to skip

Optional. Generated and vendored code is skipped anyway.

Copy your prompt

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

Your prompt (you can edit it)

Read [fill in: Coverage report] and add tests for the files with the lowest line coverage until each is above [fill in: Target coverage per file, in percent]%. Use line coverage for every number below. If the report does not contain it, tell me which metrics it has and ask before going further.

1. List the files below [fill in: Target coverage per file, in percent]% line coverage, lowest first, with their current line coverage. Skip generated code, vendored code and files that only re-export or hold configuration. If the report looks stale or does not match the current code, say so before going further.
2. Work from the lowest file up. For each one, read the uncovered lines and write tests for the behavior they implement: branches, error paths and edge cases. Match the style of the existing tests. Every test must check a result, not just run lines.
3. Change only test files. Do not change production code to raise the number. If code cannot be tested without a change, or looks unreachable, note it and move on.
4. After each file, regenerate the report and check that file's line coverage. All tests must pass. If you cannot find how the report is produced, ask me instead of guessing.
5. Stop when every listed file is above [fill in: Target coverage per file, in percent]% line coverage, or explain which files cannot get there and why.

Finish with a table: file, line coverage before, line coverage after, tests added. Then list the untestable or dead code you found.

2 required fields are empty.

What you type is kept in this tab's session storage so a reload doesn't lose it. Use "Clear this task" to remove it. Browsers can restore session data when they reopen tabs, so closing a tab isn't a guaranteed way to erase it.

When to use this template

The project already produces a coverage report and some files sit well below the level your team expects.
You want the work to start where it matters most, using the real numbers instead of a guess about which code is untested.
You want a clear finish line: the work is done when each listed file passes the target, and Claude can rerun the report to check.

When not to use it

The project has no coverage tool set up. Ask Claude to add one and produce a first report, then come back to this template with the file.
You care about one specific file rather than the whole report. The write and run tests template is a better fit and goes deeper into that file's behavior.
The low numbers come from code you plan to delete or rewrite soon. Tests for it will be thrown away; decide what to remove first.

Why this structure

Step 1 asks for the list of files with their numbers before any test is written, so you can see the plan and spot a stale report early.
Working from the lowest file up spends effort where coverage is weakest, which is what the report is for.
The rule that every test must check a result is there because a test can raise the percentage without testing anything. Coverage counts code that ran, not code whose result was checked.
The metric setting names which coverage number counts, so the ranking, the stop rule and the closing table all use the same figure. If the report lacks that metric, Claude asks instead of switching to another one.
Step 3 limits changes to test files. Raising coverage by changing the code under test mixes two kinds of change and can hide real bugs.
Regenerating the report after each file, with your command when you give one, gives Claude a number it can check and a reason to keep going until the target is reached.
The stop rule and the closing table give you both outcomes: files that reached the target, and files that could not, with the reason.

Example input (fictional)

Coverage report

coverage/coverage-summary.json

Target coverage per file, in percent

Coverage metric

line coverage

Command that regenerates the report

npm test -- --coverage

Files or folders to skip

src/generated/ and the database migrations

Follow-ups to send Claude

Review the new tests for any that would still pass if the code under test returned a wrong value. Strengthen those.
List the code you marked as unreachable, with a short reason for each, so I can decide what to delete.
Add a coverage threshold to the test configuration so the suite fails if these files drop below the target again.

Common mistakes

Using an old report. Coverage numbers from last month point Claude at files that may already be covered, or miss new ones.
Setting a target with no exclusions. Generated files and migrations drag the numbers down and waste effort on tests nobody needs.
Treating the percentage as the goal. A file at the target with weak assertions is less protected than one below it with careful tests, so read a sample of the new tests.

Write tests, run them, fix failures: Ask Claude Code to write tests for a file, run them and work through the failures in one go, without weakening a test just to make it pass.
Write unit tests: Get unit tests for a function or module in your framework, covering normal cases, edge cases and errors, with each test explained.
Optimize code to a measurable target: Give Claude Code a metric and a target value, so it measures first, changes one thing at a time and stops when the number is reached.

See all templates

Sources

Claude Code docs: Prompt library (Anthropic documentation)
Claude Code docs: Common workflows, work with tests (Anthropic documentation)
Claude Code best practices: Give Claude a way to verify its work (Anthropic documentation)