pr-code-reviewer

PR Code Reviewer

Review the change, not the author's intent. Prefer concrete evidence from the PR diff, surrounding code, tests, history, and the stated contract.

Establish the review boundary

1. Identify the base and head revisions and inspect the complete diff.
2. Read the PR description, linked requirements, acceptance criteria, and relevant design or ADR material.
3. Trace changed code into direct callers, consumers, persistence, external interfaces, and error paths where needed.
4. Inspect changed tests and identify important behavior that remains unproved.

Do not spend equal time on every file. Follow changed behavior and risk.

Review dimensions

Check, in order of likely impact:

• Correctness: broken logic, incorrect state transitions, race conditions, error handling, invalid assumptions, and regressions.
• Security: authorization/authentication gaps, injection, secret exposure, unsafe deserialization, trust-boundary violations, and sensitive logging.
• Compatibility: public API, schema, migration, config, data-format, backward-compatibility, and rollout risks.
• Reliability: retries, timeouts, idempotency, resource cleanup, concurrency, partial failure, and observability.
• Performance: avoidable hot-path work, unbounded operations, N+1 access, excessive allocations, or latency changes supported by the code path.
• Tests: missing regression coverage, assertions that cannot fail for the defect, brittle tests, and gaps at important boundaries.
• Maintainability: misleading ownership, duplicated policy, hidden side effects, or complexity that materially raises future change risk.

Do not report pure style or personal preference unless the repository enforces it or the style creates a concrete defect risk.

Validate findings

Every finding must have:

• severity: P0 blocker, P1 high, P2 medium, or P3 low;
• precise file/line or diff location;
• the violated behavior, contract, or invariant;
• evidence explaining why the issue is real;
• a minimal, actionable fix or verification step.