Audit guard: stop agents fixing work you deliberately deferred

Audit guardModel-agnosticupdated 2026-06-21sha cc036359ae4b

A vendor-blog audit prompt optimizes for finding the most issues, which is exactly the behavior that makes agents propose rebuilding deliberately-scoped-later work; this one inverts the incentive by forcing a written deferral list FIRST and making “is this on my deferral list?” a delete-gate on every finding, so a stub can only become a finding through a quoted contradiction in the plan.

Before you do the audit below, you are going to build a do-not-touch list. This is non-negotiable and comes first.

STEP 1 - Read the intent record. Open and read these files in full before scanning any code:
{{plan_doc_paths}}
Also read any CLAUDE.md, AGENTS.md, README, ROADMAP, HANDOFF, or PHASE/PLAN doc you find at the repo root. If none of these exist, say so explicitly in your output and proceed - but lower your confidence accordingly.

STEP 2 - Extract the deferral list. From those docs AND from inline markers in the code, collect everything that is deliberately scoped for later. Treat the following as POSSIBLY intentional ONLY when a cited plan line, a nearby comment, a named phase, or a ticket supports it - an unexplained stub is UNCLEAR, not automatically deferred:
- TODO / FIXME tags that name a phase, milestone, or ticket (e.g. "TODO Phase 2", "TODO(#142)", "later")
- functions that return null / None / empty / throw NotImplemented / log a "stub" or "not wired yet" warning
- feature flags that are off, commented-out wiring, and placeholder modules
- anything a plan doc describes as "deferred", "out of scope for now", "phase N", "follow-up", or "future"
Write this deferral list out explicitly as the FIRST section of your output, each item with the doc line or code comment that justifies it.

STEP 3 - Now run the actual audit: {{audit_goal}}

HARD RULES while auditing:
- A documented deferral is NOT a finding. Do not propose implementing it, do not call it a bug, gap, missing implementation, or quick win. It is the plan working as designed.
- If you believe a deferral is actually wrong (the plan contradicts itself, the stub will crash callers TODAY, security hole shipped by accident), you may raise it - but ONLY in a separate section titled "CHALLENGES TO THE PLAN", and each entry MUST quote the specific doc line you are disagreeing with and state why the deferral is unsafe as written. No vague "this should probably be done now."
- For every real finding, before you write it, ask yourself: "Is this on my deferral list?" If yes, delete it. If you are unsure whether something is deferred-on-purpose or genuinely forgotten, do NOT guess - list it under "UNCLEAR - needs human" with the one question you would ask.
- Do not refactor, do not edit files, do not open PRs. This is a read-only audit. Output findings as text only.

Output sections, in this order: (1) DEFERRALS RESPECTED, (2) REAL FINDINGS, (3) CHALLENGES TO THE PLAN, (4) UNCLEAR - needs human. If a section is empty, write "none".

Fill in: audit_goal plan_doc_paths

Shared as is, for reference. Read it and decide what it will do before you run it; using it is your responsibility, under the terms.