| name | audit-reviewer |
| description | Triple-perspective code review (architect, security, quality). Use before finalizing any non-trivial code change, for self-review when no human reviewer is available, or when evaluating third-party code or pull requests. |
| license | MIT |
Audit Reviewer
Internal code review via triple-perspective debate before finalizing any non-trivial change.
When to Use
The broad pre-merge pass — three general lenses (architect, security, quality)
over a whole change. Two siblings pull narrower:
- domain-reviewer when one module needs specialist lenses at depth
(security + perf + correctness on a single domain), not a generalist sweep.
- review-role when the artifact under review is a role composition
(injection/skill/rule coherence), not code.
Three Perspectives
1. Architect (Structural Integrity)
- Do design patterns, SOLID/DRY hold?
- Does this introduce technical debt or break existing abstractions?
2. Security Expert (Risk Mitigation)
- OWASP/SANS principles, least privilege, injection risks.
- Could an attacker exploit this change?
3. Quality Engineer (Verification & Performance)
- Test coverage, edge cases, silent failure modes.
- Is there a scenario where this fails silently or performs poorly?
- If code consumes structured LLM output: schema validation proves shape, not
meaning. Immediately after the parse, does it check that identifiers came from
the input, that selections are a subset of the candidates, and that references
resolve? Raise on failure, never warn-and-continue.
Self-Refinement Loop
- Debate — one key concern from each perspective.
- Refine — address at least one concern before finalizing.
- Approve — finalize only when no perspective has a blocking issue.
Output
Include a brief "Internal Review" section in your response noting the three perspectives. A change is "Reviewed" only when this section is present.
Completion
- All 3 perspectives evaluated with at least one concern each
- Blocking issues resolved before approval
- "Internal Review" section present in the response
Bundled Rules
Edit Efficiency
- New Files: Prefer Write for new files. Edit is for modifying existing content — building fresh files via multiple Edits wastes turns.
- Full Rewrites: If >3 consecutive Edits target the same file — STOP, use Write.
- Surgical Edits: Use Edit only for targeted, isolated modifications.
- Plan Before Editing: Read the file, plan all modifications, execute in fewest operations.
Anti-Patterns
- Rubber-stamp review — all three perspectives say "looks good" without substance
- Skipping refinement loop — listing concerns without addressing them
- Only reviewing happy path — security and edge cases matter most
