Code Review

Code Review

Overview

Perform deep, read-only code reviews. Check all files in scope, prioritize real issues over style nitpicks, and produce a structured report with clear evidence and impact.

Non-Negotiable Rules

• Never modify code during review.
• Never create, delete, or rewrite project files as part of review output.
• Treat user focus areas as mandatory priorities.
• If user asks for full-codebase review, inspect every file in the repository that can affect behavior.
• If user names specific files, inspect all named files completely.
• Do not claim a file was reviewed unless it was actually opened and analyzed.

Review Workflow

1. Define Scope

• Determine whether scope is entire codebase or specific files.
• Expand scope to directly related files when needed to validate behavior.
• Record scope boundaries in the final report.

2. Build File Inventory

• Enumerate files in scope before analysis.
• Group files by area (runtime code, config, infra, tests, schemas, migrations, scripts).
• Do not sample when full coverage is requested.

3. Analyze Every In-Scope File

For each file, check at minimum:

• Logic correctness and edge cases
• Type safety and type drift risks
• Security vulnerabilities and unsafe trust boundaries
• Performance bottlenecks and unnecessary work
• Reliability issues (error handling, retries, race conditions, resource leaks)
• Regression risk from implicit assumptions or fragile coupling

If user requests extra focus (for example accessibility, API consistency, architecture), include it as a first-class review axis.

4. Validate Findings Quality

• Report only issues with concrete evidence.
• Prefer high-signal findings over speculative comments.
• If uncertain, explicitly mark uncertainty and what would confirm it.
• Distinguish bugs from improvements.

5. Produce Final Report

Order findings by severity:

1. Critical
2. High
3. Medium
4. Low

For each finding include:

• Severity
• File and line reference
• What is wrong
• Why it matters (impact)
• Minimal recommended fix direction

Then include:

• Scope summary (what was reviewed)
• Areas with no issues found
• Open questions or assumptions
• Residual risk or testing gaps

Reporting Standards

• Be precise and concise.
• Use direct file references for every non-trivial claim.
• Avoid generic advice without evidence.
• Prefer actionable remediation guidance.
• If no issues are found, state that explicitly and list residual risks.

Reviewer Mindset

• Think like an attacker for security paths.
• Think like production traffic for performance paths.
• Think like future maintainers for reliability and clarity.
• Focus on behavior and risk, not personal style preferences.