Prompt Modifiers
Re-Audit Mode (Modifier)
A practical prompt for reviewing or building software.
- Best for
- Re-running any audit against a prior report so every earlier finding is classified FIXED, REGRESSED, NEVER FIXED, NO LONGER APPLICABLE, or DISPUTED with evidence, new findings are listed separately, and the result is a delta rather than a fresh pile
- Use when
- A fix batch just landed and you need to know what it actually closed; the same audit is being run for the second time and nobody wants a second unrelated list; a regression appeared in an area a previous report called fixed; or a report is being handed to someone who only wants to see what changed
Prepend this to any other prompt when a prior report for the same audit exists.
You are operating in Re-Audit Mode. The prior report is the baseline; the job is to produce a delta against it, not a new report that ignores it. Three inputs are required and you ask for any that is missing: the prior report (path or URL), the commit the prior report was produced against, and the commit under audit now.
Modified Behavior
-
Baseline first: parse the prior report into a numbered list of findings with their severity and location before reading any code. Record the two commits and
git diff --stat <prior>..<current>so the delta is anchored to real changes. -
Run the base prompt as written on the current commit. Do not skip sections because the prior report was clean there.
-
Classify every prior finding — no finding is left unclassified:
- FIXED — the original trigger no longer reproduces, with evidence: the fix commit, the pinning test that now passes, or a re-run reproduction that fails to fire. Code that merely changed nearby is not FIXED.
- REGRESSED — was fixed at some point between the two commits and reproduces again; cite the commit that reintroduced it.
- NEVER FIXED — still reproduces exactly as reported.
- NO LONGER APPLICABLE — the code or feature was removed or redesigned so the finding has no target; say what replaced it and whether the replacement inherits the risk.
- DISPUTED — you could not reproduce the original claim on either commit; state what you tried. Disputed findings are not counted as fixed.
-
Re-grade severity on current evidence, and say when a grade changed and why.
-
New findings separately: anything not in the prior report goes in its own section, produced under the base prompt's evidence rules. Do not fold new findings into the prior list to make the delta look better or worse.
-
Report additions: a Prior Findings table — # | prior severity | current status | current severity | evidence — followed by a Delta Summary (counts per status, net change in Critical and High, the commits responsible for each FIXED and REGRESSED row) and then the New Findings table. The executive summary opens with the delta, not with the overall state.
When NOT to Use
Do not use Re-Audit when the prior report was produced by a different prompt or with different modifiers (a quick-scan baseline cannot be re-audited at full depth — run the full prompt fresh, then use Re-Audit next time). Do not use it without the prior commit; a delta with no anchor is a guess. Do not use it to verify findings before fixing; it measures fixes, not findings.
Stacking
The last analysis stage: … → findings verification → fix-and-verify → re-audit → output format. Combine with a diff-scoped review mode to restrict the classification to prior findings whose locations fall inside the diff; the rest are reported as OUT OF SCOPE, not as any other status. Combine with a live-environment mode when a prior finding was live-only.
Want this applied to a live stack?
See the project work behind these tools, or start a conversation if you want help using one in context.