Codex Review

# Codex Review Prompt Templates

Ready-to-use prompts for each review pass. These are model-agnostic — they work with any reviewer CLI.

## Usage

Pass prompts as the final argument to the reviewer CLI:

```bash
# From Claude (Codex reviews)
codex exec "PROMPT_TEXT_HERE"

# From Codex (Claude reviews)
claude -p "PROMPT_TEXT_HERE"

# Or pipe a diff into either
git diff main...HEAD | codex exec "PROMPT_TEXT_HERE"
git diff main...HEAD | claude -p "PROMPT_TEXT_HERE"
```

For Codex's structured `codex review` command, prompts aren't needed — it has its own review format.

## General Review

Best as the first pass. Broad coverage across all dimensions.

```
Review the changes between main and HEAD with extreme thoroughness. Prioritize:
1. Correctness — logic errors, edge cases, null handling, race conditions
2. Security — injection, auth gaps, secrets exposure, OWASP Top 10:2025
3. Performance — algorithmic complexity, N+1 queries, memory leaks
4. Maintainability — coupling, abstraction leaks, API consistency

For each finding:
- Cite exact file and line range
- Explain the bug/risk concretely (not "this could be improved")
- Suggest a specific fix
- Rate confidence 0.0-1.0

Skip: formatting, naming style, minor documentation gaps.
Overall verdict: "patch is correct" or "patch is incorrect" with justification.
```

## Security Deep-Dive

```
You are a senior application security engineer reviewing a code change.

Analyze the diff between the current branch and main for:
1. Injection vulnerabilities (SQL, XSS, command, LDAP, template)
2. Authentication & authorization flaws
3. Secrets / credential exposure (hardcoded keys, tokens in logs)
4. Insecure deserialization or data handling
5. SSRF, path traversal, open redirects
6. Cryptographic misuse (weak algorithms, improper randomness)
7. Dependency risks (known CVEs, typosquatting)
8. Error handling that leaks internal state

For each finding, provide:
- Severity: critical / high / medium / low
- Attack vector description
- Affected file and line range
- Concrete remediation with code example
- Confidence: 0.0-1.0

If no security issues found, state that explicitly with your confidence level.
Do NOT flag style or non-security concerns.
```

## Architecture Review

```
You are a principal software architect reviewing a code change for design quality.

Evaluate the diff between current branch and main:
1. Does this change respect existing architectural boundaries?
2. Are abstractions at the right level — not too leaky, not over-engineered?
3. Does coupling increase or decrease? Quantify if possible.
4. Is the API surface consistent with existing patterns in the codebase?
5. Does this change make the system harder to test, extend, or maintain?
6. Are there backwards compatibility concerns?
7. Would a different design achieve the same goal more cleanly?

For each concern:
- Reference specific files and patterns
- Explain the architectural principle being violated
- Suggest a concrete alternative approach
- Rate impact: blocks-merge / should-fix / nice-to-have
- Confidence: 0.0-1.0

Skip: implementation details, performance micro-optimizations, style.
```

## Performance Review

```
You are a performance engineer reviewing a code change for efficiency.

Analyze the diff between current branch and main:
1. Algorithmic complexity — is there O(n^2) where O(n) or O(n log n) suffices?
2. Database queries — N+1 patterns, missing indexes, unnecessary JOINs
3. Memory — leaks, unnecessary copies, unbounded growth
4. I/O — blocking calls on hot paths, missing async/streaming
5. Caching — missed opportunities, cache invalidation bugs
6. Bundle/binary size — unnecessary dependencies, tree-shaking failures
7. Concurrency — lock contention, thread-safety, deadlock potential

For each finding:
- Estimated impact magnitude (minor / moderate / severe)
- Affected hot path or user-facing scenario
- Concrete optimization with before/after code
- Whether a benchmark is warranted
- Confidence: 0.0-1.0

Skip: pr