pacificstudio/openase/review-code

Review Code

Overview

Conduct a thorough code review for quality, security, performance, and maintainability. Focus on the real risks first, then provide concrete, severity-rated feedback with file and line references where possible.

When To Use

• Before merging a pull request.
• After implementing a feature or refactor.
• When the user asks for a review of changed files or a branch.
• When the code looks correct at first glance but may still hide regressions or design debt.

Review Workflow

1. Identify the review scope.

• Review the current diff, named files, or the whole change set.
• Prefer reviewing the actual changed surface before expanding further.

1. Check behavioral correctness first.

• Regressions against existing behavior.
• Missing edge-case handling.
• Broken invariants or data consistency risks.

1. Review the main quality categories.

• Security risks.
• Code quality and complexity.
• Performance concerns.
• Error handling and observability.
• Maintainability, coupling, and testability.

1. Evaluate the test story.

• Are the important paths covered?
• Are the tests proving behavior rather than implementation trivia?
• Is there an obvious missing regression test for the change?

1. Rate findings by severity.

• CRITICAL: must fix before merge; security or correctness issue with serious impact.
• HIGH: should fix before merge; likely bug, major regression risk, or serious design flaw.
• MEDIUM: worthwhile fix; non-blocking but meaningful quality issue.
• LOW: suggestion, cleanup, or style improvement.

1. Report findings in priority order.

• File and line reference.
• What is wrong.
• Why it matters.
• Concrete fix guidance.

Review Categories

• Security: secrets, unsafe input handling, authz gaps, injection, XSS, CSRF.
• Code quality: complexity, duplication, large functions, fragile branching.
• Performance: avoidable repeated work, inefficient algorithms, N+1 patterns, unnecessary re-renders.
• Maintainability: unclear naming, tight coupling, hidden assumptions, hard-to-test logic.
• Reliability: missing error handling, weak retries, silent failures, incomplete logging.

Operating Rules

• Lead with findings, not praise.
• Prioritize behavior and risk before style nits.
• Prefer evidence and concrete examples over general taste.
• If there are no findings, say so explicitly and still mention residual risks or test gaps.
• Keep recommendations actionable enough that another engineer can implement them directly.

Default Deliverable Shape

Return these sections:

1. Findings - ordered by severity, each with file and line references.
2. Open Questions / Assumptions - only if they affect confidence.
3. Residual Risks - what was not fully proven by the review.
4. Short Summary - brief overall assessment after the findings.