Audit Harness (Universal)
Every audit prompt and production review must obey this harness. Domain
prompts add threat models and checklists on top of it. They do not override
scope, mode, or verification rules here.
1. Before any file is opened
Collect or ask for:
| Field |
Required |
Default if human is silent |
| Scope |
Yes |
Stop and ask. Never invent "the whole repo" unless explicitly told. |
| Mode |
Yes |
report-only |
| Exclusions |
Strongly preferred |
Third-party/vendored trees, minified bundles, generated code, binary/stream assets, lockfile-only noise |
| Verify commands |
Yes if mode is fix |
Discover from project AGENTS.md / README. If none exist, state "no automated verify" and list manual checks. |
| Approval for risky edits |
When needed |
Do not force-push, rewrite history, edit secrets, or mass-change vendored code without explicit approval |
Scope examples (good): one resource folder, one package, a PR diff, a named file list.
Scope examples (bad): "everything under src," "all resources," with no exclusions and mode fix.
If scope is missing, output:
BLOCKED: audit scope not set.
Provide: paths or package names, mode (report-only | fix), and any exclusions.
Do not proceed past that message.
2. Mode
report-only (default)
- Trace and document findings.
- Do not edit production code.
- Fixes are recommendations with enough detail to implement later.
fix
- Only after scope is explicit.
- Fix in-scope defects only. No drive-by refactors, renames, or style passes.
- One concern per change set when practical.
- After fixes, run project verify commands and paste real output (or honest failure).
fix is never implied by "review," "audit," or "check."
3. Exclusions (apply unless the human overrides)
Do not treat as first-class audit targets:
- Vendored / third-party dependencies and plugins not owned by the project
- Minified or bundled
dist output (unless the task is specifically "patch this known vendored bug" and approval is clear)
- Generated code, caches, lockfile-only diffs
- Binary assets, maps, media, compiled streams
- Secrets files and live config (report exposure risk; do not print secret values)
Own project code and thin wrappers around vendors are in scope when listed.
4. Evidence rules
- Do not sample "representative" files and claim full coverage.
- Do not rely on earlier sessions as proof. Re-open files when asserting.
- Unhappy paths count: null/malformed input, double-submit, disconnect mid-op, permission denied, timeout.
- Shared mutable state: prove ordering safety or flag as unverified.
- "Client already checks this" / "UI prevents this" is not validation on a hostile client or untrusted caller.
- If you have not traced a path, label it unverified, not safe.
5. Severity
| Level |
Meaning |
| blocker |
Data loss, security break, economy break, crash on common path, ship-stopper |
| high |
Exploitable or likely production incident under realistic load/abuse |
| medium |
Real defect, limited blast radius or harder to trigger |
| low |
Smell, missing polish, dead code, docs drift |
6. Finding format (every issue)
For each finding:
- Location, path and symbol/event/handler name
- Trigger, exact scenario (who/what calls it, with what inputs)
- Effect, what goes wrong
- Severity, blocker / high / medium / low
- Evidence, what you opened and what you traced
- Fix, concrete change (applied if mode is
fix, proposed if report-only)
- Verify, how you confirmed, or "not run" with reason
7. Required end report
Always end with:
- Scope actually covered, paths/modules reviewed (honest list)
- Skipped / excluded, and why
- Findings, table or list with severity
- Fixes applied, only if mode was
fix
- Verification, commands run and outcomes, or explicit "none"
- Go / no-go, ship recommendation for the scoped change; name blockers
Never "all green" without the coverage list and evidence.
8. How domain prompts use this file
- Read this harness.
- Read project
AGENTS.md if present.
- Apply the domain prompt's checklist inside the agreed scope and mode.
- Domain prompt may tighten severity (e.g. treat money dupes as blocker). It may not widen scope or switch to
fix silently.
9. Pairing
| Doc |
Role |
prompts/reviews/PR-Review.md |
Production-minded full review posture |
prompts/reviews/* |
Generic audits (security, perf, errors, Tauri QC) |
prompts/domains/* |
Domain threat models you add for your own stack |
prompts/scaffolds/* |
Greenfield product builds (not audits) |
skills/engineering/errors/SKILL.md |
Failure handling and user-facing copy |
skills/engineering/uncle-bob/SKILL.md |
Craft methodology |
standards/Principles.md |
Long optional handbook (section-load only) |
Project AGENTS.md |
What is owned code, secrets, verify commands |
1---2name: audit3description: Universal operational harness for any review, security pass, or audit prompt. Always load before running prompts/reviews/* or prompts/domains/* or a full PR review. Defines scope, mode (report vs fix), exclusions, severity, verification, and output shape. Stack-agnostic. Project-specific threat models live in prompts; this file is the safety contract that keeps agents from thrashing an entire monorepo.4---56# Audit Harness (Universal)78Every audit prompt and production review **must** obey this harness. Domain9prompts add threat models and checklists on top of it. They do not override10scope, mode, or verification rules here.1112---1314## 1. Before any file is opened1516Collect or ask for:1718| Field | Required | Default if human is silent |19|---|---|---|20| **Scope** | Yes | Stop and ask. Never invent "the whole repo" unless explicitly told. |21| **Mode** | Yes | `report-only` |22| **Exclusions** | Strongly preferred | Third-party/vendored trees, minified bundles, generated code, binary/stream assets, lockfile-only noise |23| **Verify commands** | Yes if mode is `fix` | Discover from project `AGENTS.md` / README. If none exist, state "no automated verify" and list manual checks. |24| **Approval for risky edits** | When needed | Do not force-push, rewrite history, edit secrets, or mass-change vendored code without explicit approval |2526**Scope examples (good):** one resource folder, one package, a PR diff, a named file list. 27**Scope examples (bad):** "everything under src," "all resources," with no exclusions and mode `fix`.2829If scope is missing, output:3031```text32BLOCKED: audit scope not set.33Provide: paths or package names, mode (report-only | fix), and any exclusions.34```3536Do not proceed past that message.3738---3940## 2. Mode4142### `report-only` (default)4344- Trace and document findings.45- Do not edit production code.46- Fixes are recommendations with enough detail to implement later.4748### `fix`4950- Only after scope is explicit.51- Fix in-scope defects only. No drive-by refactors, renames, or style passes.52- One concern per change set when practical.53- After fixes, run project verify commands and paste real output (or honest failure).5455### `fix` is never implied by "review," "audit," or "check."5657---5859## 3. Exclusions (apply unless the human overrides)6061Do **not** treat as first-class audit targets:6263- Vendored / third-party dependencies and plugins not owned by the project64- Minified or bundled `dist` output (unless the task is specifically "patch this known vendored bug" and approval is clear)65- Generated code, caches, lockfile-only diffs66- Binary assets, maps, media, compiled streams67- Secrets files and live config (report exposure risk; do not print secret values)6869Own project code and thin wrappers around vendors **are** in scope when listed.7071---7273## 4. Evidence rules7475- Do not sample "representative" files and claim full coverage.76- Do not rely on earlier sessions as proof. Re-open files when asserting.77- Unhappy paths count: null/malformed input, double-submit, disconnect mid-op, permission denied, timeout.78- Shared mutable state: prove ordering safety or flag as unverified.79- "Client already checks this" / "UI prevents this" is not validation on a hostile client or untrusted caller.80- If you have not traced a path, label it **unverified**, not safe.8182---8384## 5. Severity8586| Level | Meaning |87|---|---|88| **blocker** | Data loss, security break, economy break, crash on common path, ship-stopper |89| **high** | Exploitable or likely production incident under realistic load/abuse |90| **medium** | Real defect, limited blast radius or harder to trigger |91| **low** | Smell, missing polish, dead code, docs drift |9293---9495## 6. Finding format (every issue)9697For each finding:98991. **Location**, path and symbol/event/handler name 1002. **Trigger**, exact scenario (who/what calls it, with what inputs) 1013. **Effect**, what goes wrong 1024. **Severity**, blocker / high / medium / low 1035. **Evidence**, what you opened and what you traced 1046. **Fix**, concrete change (applied if mode is `fix`, proposed if `report-only`) 1057. **Verify**, how you confirmed, or "not run" with reason 106107---108109## 7. Required end report110111Always end with:1121131. **Scope actually covered**, paths/modules reviewed (honest list) 1142. **Skipped / excluded**, and why 1153. **Findings**, table or list with severity 1164. **Fixes applied**, only if mode was `fix` 1175. **Verification**, commands run and outcomes, or explicit "none" 1186. **Go / no-go**, ship recommendation for the scoped change; name blockers 119120Never "all green" without the coverage list and evidence.121122---123124## 8. How domain prompts use this file1251261. Read this harness. 1272. Read project `AGENTS.md` if present. 1283. Apply the domain prompt's checklist **inside** the agreed scope and mode. 1294. Domain prompt may tighten severity (e.g. treat money dupes as blocker). It may not widen scope or switch to `fix` silently.130131---132133## 9. Pairing134135| Doc | Role |136|---|---|137| `prompts/reviews/PR-Review.md` | Production-minded full review posture |138| `prompts/reviews/*` | Generic audits (security, perf, errors, Tauri QC) |139| `prompts/domains/*` | Domain threat models you add for your own stack |140| `prompts/scaffolds/*` | Greenfield product builds (not audits) |141| `skills/engineering/errors/SKILL.md` | Failure handling and user-facing copy |142| `skills/engineering/uncle-bob/SKILL.md` | Craft methodology |143| `standards/Principles.md` | Long optional handbook (section-load only) |144| Project `AGENTS.md` | What is owned code, secrets, verify commands |
yourpovv