jiayaoqijia Code Review Skill
Review code changes and identify bugs, security issues, and quality problems.
Workflow
Get the code changes - Use the method provided in the prompt, or if none specified:
- For a PR:
gh pr diff <PR_NUMBER> - For local changes:
git diff mainorgit diff --staged
- For a PR:
Read full files and related code before commenting - verify issues exist and consider how similar code is implemented elsewhere in the codebase
Analyze for issues - Focus on what could break production
Report findings - Use the method provided in the prompt, or summarize directly
Severity Levels
- CRITICAL: Security vulnerabilities, auth bypass, data corruption, crashes
- IMPORTANT: Logic bugs, race conditions, resource leaks, unhandled errors
- NITPICK: Minor improvements, style issues, portability concerns
What to Look For
- Security: Auth bypass, injection, data exposure, improper access control
- Correctness: Logic errors, off-by-one, nil/null handling, error paths
- Concurrency: Race conditions, deadlocks, missing synchronization
- Resources: Leaks, unclosed handles, missing cleanup
- Error handling: Swallowed errors, missing validation, panic paths
What NOT to Comment On
- Style that matches existing project patterns
- Code that already exists unchanged
- Theoretical issues without concrete impact
- Changes unrelated to the PR's purpose
Review Quality
- Explain impact ("causes crash when X" not "could be better")
- Make observations actionable with specific fixes
- Read the full context before commenting on a line
- Check project guidelines for conventions before flagging style
Comment Standards
- Only comment when confident - If you're not 80%+ sure it's a real issue, don't comment. Verify claims before posting.
- No speculation - Avoid "might", "could", "consider". State facts or skip.
- Verify technical claims - Check documentation or code before asserting how something works. Don't guess at API behavior or syntax rules.