Reviewing Code
Review the requested change, not the entire codebase. Treat the task as read-only unless fixes are requested. Keep this as an ordinary code review with a security baseline; when security is the primary objective or acceptance criterion, use audit-code-security instead of expanding this workflow into a full security audit.
Workflow
- Determine the exact target and comparison base from the request and repository or PR context. Use the target branch's merge base; do not assume
main. State broader file-audit scope when no diff is involved. - Infer intended behavior from the request, issue/PR context, tests, docs, and surrounding code. Label material assumptions.
- Trace changed behavior through relevant callers, contracts, state, errors, and downstream consumers. Report issues introduced, worsened, or made reachable by the change; separate directly relevant pre-existing problems.
- Check, where plausible:
- correctness, boundaries, state transitions, retries, concurrency, partial failure, and cleanup
- where repeated work without progress stops, and its worst-case time, resources, cost, and side effects
- interfaces, schemas, migrations, jobs, caches, feature flags, permissions, and configuration
- security baseline: affected assets and trust boundaries; authn/authz and tenant or object ownership; source-to-sink validation and injection; secrets, logging, and sensitive data; dependency and configuration exposure
- repeated work, I/O, queries, blocking, leaks, and expected scale
- tests for changed behavior and concrete error paths; maintainability only where it creates real cost or risk
- Run focused checks when feasible. Passing checks support but do not prove correctness.
- Stop after the relevant diff, directly affected contracts/callers, and focused evidence are covered. Distinguish confirmed findings, inferred risks, and unverified areas.
When fixes are requested, confirm the finding first, then use harden-code-paths for bounded edge-case or failure-mode work. Do not hand off speculative or preference-only comments. Use audit-code-security first when a security alert needs threat-focused reachability analysis. Return to review the resulting diff and evidence.
Findings
Lead with confirmed findings ordered by severity:
- Critical: severe security impact, data loss, or widespread production failure.
- Major: important correctness, reliability, security, or maintainability risk that should block merge.
- Minor: real, low-risk defect worth correcting.
Each finding needs a file/line when available, concrete trigger, impact, and actionable fix. Omit nits unless requested. If no finding survives verification, say so and name meaningful residual risk or unavailable checks.
Give a merge verdict only for a PR/MR or explicit mergeability request: Approve, Approve with minor comments, Request changes, or Needs more context.