dirien/stop-building-portals-start-building-conversations/review

/review — Code Review

When to use

When the user runs /review or asks to review changes/PR.

Steps

1. Identify what to review:

• If a PR number is given: gh pr diff <number>
• Otherwise: git diff for unstaged, git diff --staged for staged

1. Read each changed file fully for context
2. Check for:

• Security: injection, XSS, hardcoded secrets, OWASP top 10
• Correctness: edge cases, off-by-one, null handling, race conditions
• Quality: naming, complexity, duplication, dead code
• Performance: N+1 queries, unnecessary allocations, missing indexes
• Tests: adequate coverage, meaningful assertions

1. Report findings grouped by severity:

• CRITICAL: security issues, data loss risks
• WARNING: bugs, correctness issues
• SUGGESTION: style, refactoring opportunities

Rules

• Be specific: reference file:line
• Suggest fixes, don't just point out problems
• Acknowledge what's done well
• Don't nitpick formatting if a linter is configured