| name | review-workflow |
| description | Code review methodology with severity tagging |
| argument-hint | <files-or-diff-to-review> |
| user-invocable | true |
| allowed-tools | ["Read","Grep","Glob","Bash"] |
Review Workflow
Review Process
Step 1 — Context
- Read the plan or PR description to understand intent
- Identify the acceptance criteria for this change
Step 2 — Correctness
- Does the code do what the plan/description says?
- Are there logic errors, off-by-one mistakes, or race conditions?
- Are edge cases handled?
Step 3 — Quality
- Is the code readable and maintainable?
- Are names descriptive? Is structure clear?
- Is there unnecessary duplication?
- Is complexity justified?
Step 4 — Tests
- Are there tests for the new/changed behavior?
- Do tests cover happy path, edge cases, and error conditions?
- Are tests meaningful (not just "it doesn't crash")?
Step 5 — Security
- Is user input validated at boundaries?
- Are there injection risks, auth gaps, or secret exposure?
- Reference the security-review skill for thorough checks
Step 6 — Verdict
- Tag each finding: BLOCKER / MAJOR / MINOR / NIT
- Deliver verdict: APPROVE / REQUEST_CHANGES / NEEDS_DISCUSSION
Finding Format
**[SEVERITY] — Short description**
File: path/to/file.ext, line N
Issue: What's wrong
Suggestion: How to fix it
Review Etiquette
- Praise good decisions — don't only criticize
- Be specific — "this is unclear" is useless; "rename
x to userCount" is actionable
- Don't bikeshed — if it works and is clear, let it be
- Separate personal preference (NIT) from genuine issues (MAJOR/BLOCKER)