Prompt Modifiers
Deep Audit Mode (Modifier)
A practical prompt for reviewing or building software.
- Best for
- The opposite of a quick scan: whole-surface scope, every file in the audited surface read in full, data flows traced end to end, everything runnable actually run, every Likely finding reproduced or killed, no finding cap, and an explicit statement of what was not covered. For pre-launch security, compliance, revenue integrity, and any audit where one missed Critical costs more than the extra hour
- Use when
- A public launch, store submission, or compliance review is days away; the audit covers money, auth, or personal data; a previous quick scan or diff-scoped review missed something expensive; or an audit is being run once to establish a baseline that later re-audits will diff against
Prepend this to any other prompt when missing a Critical is not acceptable.
You are operating in Deep Audit Mode. Breadth-first skimming is the failure mode this mode exists to prevent: a long checklist pasted into a large repository produces a page of pattern matches and no traced defects. Here, coverage is measured, reproduction is mandatory, and the report says what was not looked at.
Modified Behavior
-
Scope: the whole surface the base prompt names, not a diff — even when a diff exists. If the base prompt offers a diff-scoped default, override it and say so in the executive summary.
-
Coverage is explicit: before reading, enumerate the surface (files, routes, jobs, screens, tables — whatever the base prompt audits) with a command, and keep that list as the coverage ledger. Every entry ends the audit marked READ, TRACED, RUN, or NOT COVERED with a reason. A surface with no ledger is a quick scan wearing a deep label.
-
Read in full, trace end to end: every file in the surface is read completely, not grepped. Each finding's trigger is traced from input to effect across module boundaries. "Probably handled upstream" is resolved by reading upstream.
-
Run everything runnable: the test suite, the type check, the build, and the application itself where a browser or mobile MCP is available. Findings the tools can confirm are confirmed by the tools, not by reading.
-
Every Likely finding is resolved: reproduce it (a failing test, a driven interaction, a query) and promote it to Confirmed, or fail to reproduce it and drop it with the attempt recorded. No Likely findings survive to the final report unless reproduction was genuinely impossible, in which case the reason is stated and severity stays capped at Medium.
-
No finding cap: report everything that meets the base prompt's evidence rules, ranked by severity then blast radius. Do not trim for length; use the risk table for volume and reserve prose for Critical and High.
-
Checkpoints: for a surface larger than roughly forty files or an hour of work, write an interim report at each checkpoint (a fixed file count or interval) so an interrupted session loses nothing. The final report supersedes the checkpoints and lists them.
-
Report additions: a Coverage Ledger (entry | status | evidence) and a Not Covered section naming every gap and why — access, time, missing credentials — so the reader knows what a clean report does not promise.
When NOT to Use
Do not use Deep Audit for mid-sprint reviews of a single change (use a diff-scoped review), for triage under time pressure (use a quick scan), or for a second run of the same audit where a prior report exists (re-audit against it instead). Do not use it on a repository where nothing can be run; half of this mode is execution, and a read-only Deep Audit should be labelled as such.
Stacking
The depth slot: diff scope → deep audit → live environment → findings verification → fix-and-verify → re-audit → output format. Incompatible with a quick-scan depth mode — one depth modifier only. Combining with a diff-scoped review mode narrows the surface to the diff and its dependents while keeping Deep's read-everything and reproduce-everything rules inside that surface. Combine with a live-environment mode for full coverage.
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.