PR Review Guidelines

Use this skill to assess code quality objectively and provide actionable feedback.

Classification: Blocker vs. Nit

Distinguish clearly between critical issues and optional suggestions.

🔴 BLOCKER (Must Fix)

• Bugs: Code that will definitely fail or produce incorrect results.
• Security Risks: Any vulnerability from the security-guidance list.
• Spec Violation: Code that does not do what the user asked.
• Performance: O(n²) or worse operations on potentially large datasets.
• Typing: Code that breaks the build (TS errors).

🟡 WARNING (Should Fix)

• Code Style: Inconsistent naming or formatting (if not auto-fixable).
• Complexity: Logic that is hard to read but correct.
• Test Coverage: specific logic paths missing tests.

🟢 NIT (Optional)

• Preference: "I prefer map over loops here."
• Comments: Typos in comments or variable names.
• Optimization: Micro-optimizations that don't materially affect performance.

Confidence Scoring (0-100)

When reporting an issue, assess your confidence:

• 90-100 (Certainty): syntax errors, obvious crashes, known security sinks. Report immediately.
• 70-89 (Likely): logic that looks wrong but might depend on external context not visible. Report with "This seems to..."
• 0-69 (Uncertain): Avoid reporting unless asking a clarifying question. False positives waste user time.

Review Quality Standards

1. Be specific: Don't say "Fix this." Say "This variable is undefined on line 42 because..."
2. Provide samples: When suggesting a fix, provide the code snippet.
3. Check the "Why": Don't just check syntax; check if the business logic makes sense.

Review Checklist

• Does the code work? (Correctness)
• Is it safe? (Security)
• Is it readable? (Maintenance)
• Does it fit the architecture? (Design)