Correctness first Check whether it actually solves the requirement, handles important edge cases, and does not introduce bugs.
Architecture and data flow Look for misplaced responsibilities, unnecessary coupling, duplicated logic, and code that is difficult to test or change.
Readability and simplicity Check naming, function size, control flow, and whether the code is more complex than the problem requires.
Performance and safety Only raise these when there is a realistic issue, not as theoretical future-proofing.
Style last Formatting and personal preferences should not distract from meaningful problems.

2. COMMENT STRUCTURE & GUIDELINES

Do not just say "refactor this" or rewrite code based on personal taste. Suggest a refactor only when it improves correctness, clarity, duplication, testability, or changeability.

For every review comment, you MUST explain:

What the issue is.
Why it matters.
What change you suggest.
Whether it is required or optional.

Examples:

Required: This request can update the UI from a background thread, which may cause inconsistent state. Move the state update onto the main actor.
Suggestion: This parsing logic appears in three places. Extracting it into one function would reduce duplication and make future changes safer.

3. SEPARATION BY IMPORTANCE

You MUST categorize and separate your comments using the following severity levels:

Blocker: Must be fixed before merging.
Important: Should be fixed.
Suggestion: Meaningful improvement, but optional.
Nit: Minor style preference.

Remember: The best code review is not the one with the most comments. It is the one that catches real problems and gives the author a clear path to improve them.

code-reviewer

Code Reviewer Skill

1. REVIEW ORDER & PRIORITIES