# 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.

Paste into: **Claude Code**, started in your project folder

## Prompt template

How the builder on the page fills in this template, so you can do the same:

- `{{key}}` becomes the text entered for that field, exactly as typed. Empty text, or text that is only whitespace (spaces, tabs or line breaks), counts as empty: a required field then becomes `[fill in: <label>]` with its label, and an optional field becomes nothing.
- For a choice field, `{{key}}` becomes the text of the chosen option, or of the default when none is chosen.
- Text between `{{#key}}` and `{{/key}}` stays only when that field is not empty; a choice field always counts as filled. The markers themselves are removed, and a marker that stands alone on its line takes its line break with it.
- Each value is inserted once, as it is: `{{…}}` inside a value stays as typed.

```text
Read {{report}} and add tests for the files with the lowest {{metric}} until each is above {{target}}%. Use {{metric}} 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 {{target}}% {{metric}}, lowest first, with their current {{metric}}. Skip generated code, vendored code and files that only re-export or hold configuration.{{#skip}} Also skip: {{skip}}.{{/skip}} 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{{#regenerate}} with: {{regenerate}}{{/regenerate}} and check that file's {{metric}}. 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 {{target}}% {{metric}}, or explain which files cannot get there and why.

Finish with a table: file, {{metric}} before, {{metric}} after, tests added. Then list the untestable or dead code you found.
```

## Fields

- `{{report}}` (required): Coverage report. A report file in the project. Generate a fresh one before you start.
- `{{target}}` (required): Target coverage per file, in percent.
- `{{metric}}`: Coverage metric. Choose one:
  - line coverage (default)
  - branch coverage
  - statement coverage
  - function coverage
- `{{regenerate}}`: Command that regenerates the report. Optional. Leave empty and Claude will look for how the report is produced.
- `{{skip}}`: Files or folders to skip. Optional. Generated and vendored code is skipped anyway.

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

## 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:

```
80
```

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.

## Related templates

- [Write tests, run them, fix failures](https://awesomeclaudeprompts.com/prompts/write-and-run-tests/): 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](https://awesomeclaudeprompts.com/prompts/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](https://awesomeclaudeprompts.com/prompts/optimize-to-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.

## Sources

- [Claude Code docs: Prompt library](https://code.claude.com/docs/en/prompt-library) (Anthropic documentation)
- [Claude Code docs: Common workflows, work with tests](https://code.claude.com/docs/en/common-workflows#work-with-tests) (Anthropic documentation)
- [Claude Code best practices: Give Claude a way to verify its work](https://code.claude.com/docs/en/best-practices#give-claude-a-way-to-verify-its-work) (Anthropic documentation)

---

Awesome Claude Prompts is an independent project. It is not affiliated with, endorsed by, or sponsored by Anthropic. Claude is a trademark of Anthropic, PBC.