Pre-Review

Find and fix issues before publishing your PR — not after.

Single-pass review using one capable model. No orchestration overhead, no agent swarm. Fast, cheap, thorough.

When to use

• - Reviewing code changes before publishing a PR
• Auditing existing code for bugs, security, or quality issues
• Finding and fixing issues in specific files or directories

When NOT to use

• - Running a coding agent to write new code → use INLINECODE0
• Checking GitHub CI status → use INLINECODE1
• Managing forks or rebasing branches → use INLINECODE2

Usage

CODEBLOCK0

Two modes:

Instructions

Step 1: Detect Mode and Scope

No arguments provided:

git diff main...HEAD --name-only 2>/dev/null || git diff master...HEAD --name-only

• - If changes exist → Diff mode
• If no changes → inform user, stop

Paths/patterns provided or --audit:

• - Resolve to actual files (exclude node_modules, dist, build, vendor, .git, coverage)
• If > 50 files, ask user to narrow scope or confirm
• Audit mode

Step 2: Gather Context

Read project guidelines (quick scan, don't overthink):
CODEBLOCK2

Get the diff or file contents:
CODEBLOCK3

Step 3: Review (Single Pass)

Analyze all code in one pass. Cover these areas in priority order:

1. Correctness (highest priority)

• - Logic errors, edge cases, null/undefined handling
• Off-by-one, pagination boundaries, numeric precision
• Async/await mistakes, race conditions, resource leaks
• Data consistency, idempotency

2. Security

• - Injection vulnerabilities (SQL, XSS, command, path traversal)
• Auth/authz gaps, IDOR risks, exposed secrets
• Unvalidated input reaching sensitive operations
• Logging sensitive data, insecure defaults

3. Reliability

• - Error handling gaps, silent failures, swallowed exceptions
• Missing timeouts, retries without backoff
• Unbounded operations on user-controlled data

4. Performance

• - N+1 queries, unnecessary loops, memory bloat
• Missing pagination, inefficient algorithms
• Blocking operations in async context

5. Quality (lowest priority — skip if trivial)

• - Missing tests for new functionality
• Dead code, duplicated logic
• Stale comments, unclear naming
• Style issues only if they violate project guidelines

Step 4: Score and Classify

For each issue found, assign:

Discard thresholds:

• - Diff mode: discard below 50
• Audit mode: discard below 40

Classify each issue:

• - blocker — security, data corruption, crash risk
• INLINECODE6 — likely bug, perf regression, missing validation
• INLINECODE7 — edge case, maintainability, style

Step 5: Auto-Fix

Apply fixes directly for issues meeting the threshold:

• - Diff mode: fix issues scoring >= 70
• Audit mode: fix issues scoring >= 80

For each fix: read file → apply edit → verify surrounding code preserved.

Never auto-fix:

• - Issues requiring architectural changes
• Ambiguous fixes with multiple valid approaches
• Issues in test files (report only)

After fixing, if any files were modified:
CODEBLOCK4

Step 6: Report

Format:

CODEBLOCK5

If zero issues found: INLINECODE8

Guidelines

DO:

• - Fix issues directly, not just report them
• Match existing code patterns and style
• Be specific: file, line, concrete fix
• Prioritize impact over thoroughness

DON'T:

• - Fix pre-existing issues in diff mode — only what changed
• Bikeshed on style unless it violates project guidelines
• Report what a linter or type checker would catch (assume CI handles these)
• Make architectural changes or large refactors
• Spend tokens on obvious non-issues

False Positives to Avoid

• - Pre-existing code not touched by the current change (diff mode)
• Intentional patterns that look unusual but are correct
• Issues a type checker or linter would flag
• Style opinions not grounded in project guidelines
• General nitpicks a senior engineer would skip