<skill_overview> Provide a structured approach to code review that maximizes value and minimizes friction.

User asks to review a file or set of files. User asks to review a Pull Request. User asks to check code for errors or improvements.

</skill_overview>

<severity_levels>

Must be fixed before merging.

• Bugs / Logical errors
• Security vulnerabilities
• Data loss risks
• Breaking changes to public APIs without versioning
• Build failures

<review_process>

Context Acquisition Understand what the code is trying to do. Read PR description, commit messages, or ask the user.

<comment_formatting> Conventional Comments

suggestion: This function is doing two things. Consider splitting it into 'fetchData' and 'processData'.

critical: This SQL query is vulnerable to injection. Use parameterized queries instead.

question: I don't see where 'user_id' is validated. Can you point me to the validation logic?

praise: Great use of the Strategy pattern here! Much cleaner.

nit: Typo in the variable name 'reciever' -> 'receiver'.

</comment_formatting>

<anti_patterns> Vague feedback ("This looks bad"). Be specific ("This loop is O(n^2) because..."). Commanding tone ("Change this"). Use questions or suggestions ("Have you considered...?"). Nitpicking style when it's valid. (e.g., const vs let if not reassigned is fine, but don't fight over newlines). Reviewing generated files (.lock , dist/ , build/ ). </anti_patterns>