What this prompt does
This prompt frames the model as a senior engineer who treats coverage as a tool, not a vanity metric, and asks it to audit coverage and propose a plan to raise it where it actually reduces risk, returning concrete commands and a schedule. Four placeholders steer it: [stack] (the language and test runner), [coverage_tool] (how coverage is measured), [target] (the uplift percentage), and [risk_modules] (the highest-risk areas to focus on).
The structure works because chasing a coverage number for its own sake produces tests that assert nothing. By asking for commands to measure line and branch coverage per module, prioritisation by change frequency times business risk focused on [risk_modules], a rule forbidding vanity tests for trivial glue, a branch-coverage plan, a CI floor that fails on regression without blocking unrelated work, and a two-week test-by-test schedule, the prompt ties every new test to a real risk rather than inflating a metric. Setting [target] as a deliberate uplift rather than an arbitrary ceiling keeps the goal honest, and pinning [coverage_tool] ensures the measurement commands and reports match what your project already produces.
When to use it
- You want to raise coverage where it reduces risk, not just hit a number.
- You need commands to measure line and branch coverage per module on
[stack]. - You want targets prioritised by change frequency and business risk around
[risk_modules]. - You want a rule that forbids vanity tests for trivial glue and getters.
- You need a CI coverage floor that fails on regression but won't block unrelated work.
- You want a concrete two-week, test-by-test schedule to reach
[target].
Example output
Expect tooling commands plus a prioritised two-week plan. The commands measure current line and branch coverage with [coverage_tool] and produce a per-module report. The plan prioritises targets by change frequency times business risk, concentrating on [risk_modules], adds a rule against vanity tests for glue and getters, lays out the specific branch-coverage gaps to close, defines a CI coverage floor that fails on regression without blocking unrelated work, and gives a test-by-test schedule mapping each new test to a real risk to hit [target] on [stack].
Pro tips
- Tie every new test in the schedule to a module that actually changes and breaks; coverage on stable glue code buys you nothing.
- Track branch coverage, not just line coverage — fully covered lines can still miss critical conditional paths.
- Set
[risk_modules]to the things that hurt when they break (e.g. payments, auth, order processing) so effort lands where it matters. - Make the CI floor fail on regression but not block unrelated work, so it protects coverage without becoming an obstacle.
- Keep
[target]realistic; a modest uplift on[risk_modules]reduces more risk than a big jump driven by trivial tests. - Use the per-module report to spot which
[risk_modules]are weakest, then sequence the two-week schedule to close those first. - Run the measurement commands with
[coverage_tool]before and after each week so you can see whether the new tests actually moved the needle where it mattered.
