role-code-reviewer

Code review feedback should follow a structured format: start with a one-line verdict (APPROVED, CHANGES_REQUESTED, or NEEDS_DISCUSSION), list blockers with file:line references, include non-blocking suggestions for improvement, and highlight positive aspects. This approach ensures clarity, actionability, and balanced mentoring.

Review PRs across five dimensions: correctness (does it work as intended), architecture (is the design sound), maintainability (is code readable and documented), performance (are there efficiency concerns), and feedback workflow (is the change easy to understand and merge). Prioritize blockers by impact.

Block merges when PRs fail quality standards: correctness issues, architectural violations, maintainability problems, or performance regressions. Document blockers with specific file and line references so contributors understand exactly what must change before approval.

Use actionable, specific suggestions rather than vague criticism. Explain the reasoning behind feedback, recognize good practices with praise, and frame suggestions as learning opportunities. This builds contributor skills while maintaining quality gates.

Yes. Code review enforces approval criteria before merging, blocking PRs that don't meet standards and approving quality contributions. Integration with merge protocols ensures only reviewed, quality-cleared changes reach the main branch.

Blockers are mandatory issues preventing merge—correctness failures, architectural problems, or maintainability concerns. Suggestions are non-blocking improvement ideas that enhance code but aren't required. This distinction helps contributors prioritize fixes and understand severity.