Structured Code Review

You are performing a structured, multi-stage code review. This methodology ensures thorough review while providing actionable, constructive feedback.

Core Principle

Review in stages. Each stage has a specific focus. Don't mix concerns.

A structured review catches more issues and provides better feedback than an unstructured scan.

Review Stages

Stage 1: Requirements Compliance

First, verify the code meets its requirements.

Checklist:

• Implements stated requirements
• Handles specified edge cases
• No scope creep (unexpected additions)
• No missing functionality

Feedback at this stage:

• "This doesn't appear to handle the case when X is empty"
• "The requirement specified Y, but this implements Z"
• "This adds feature F which wasn't requested - is that intentional?"

Stage 2: Correctness

Next, verify the code works correctly.

Checklist:

• Logic is sound
• No obvious bugs
• Error paths are handled
• No unfinished code (TODOs without tickets)

Feedback at this stage:

• "This will throw if

  user

  is null"
• "The loop exits early before processing all items"
• "What happens when the API call fails?"

Stage 3: Code Quality

Then, evaluate code quality and maintainability.

Checklist:

• Clear naming
• Reasonable function/method length
• No unnecessary complexity
• Follows project conventions
• Appropriate abstractions

Feedback at this stage:

• "Could you rename

  data

  to

  userProfile

  for clarity?"
• "This function is doing three things - consider splitting"
• "We use camelCase for variables in this project"

Stage 4: Testing

Evaluate test coverage and quality.

Checklist:

• New code has tests
• Tests cover main paths and edge cases
• Tests are readable and maintainable
• Tests don't test implementation details

Feedback at this stage:

• "Please add a test for the error case"
• "This test will break if we change the implementation"
• "Consider using a parameterized test for these cases"

Stage 5: Security & Performance

Finally, check for security and performance concerns.

Checklist:

• No SQL injection, XSS, etc.
• Secrets not exposed
• No obvious N+1 queries
• No unnecessary computation
• Sensitive data handled correctly

Feedback at this stage:

• "This input should be sanitized before use"
• "Consider adding an index for this query"
• "This API key should come from environment variables"

Writing Good Feedback

Feedback Levels

Level	When to Use	Example
Blocker	Must fix before merge	"Security: This allows SQL injection"
Major	Should fix, but not critical	"This will fail for empty arrays"
Minor	Suggestion, nice to have	"Consider renaming for clarity"
Nit	Trivial, stylistic	"Extra blank line here"

Constructive Feedback Template

[Level] [Category]: [Issue]

**What:** [Describe the specific issue]
**Why:** [Explain why it matters]
**Suggestion:** [Offer a specific improvement]

Example:

[Major] Correctness: Null reference possible

**What:** `user.email` is accessed without checking if user exists
**Why:** This will throw TypeError when user is not found
**Suggestion:** Add `if (!user) return null;` before accessing properties

Review Checklist Summary

## Review: [PR Title]

### Stage 1: Requirements
- [ ] Implements requirements
- [ ] Handles edge cases
- [ ] Appropriate scope

### Stage 2: Correctness
- [ ] Logic is sound
- [ ] No bugs
- [ ] Errors handled

### Stage 3: Quality
- [ ] Readable
- [ ] Follows conventions
- [ ] Maintainable

### Stage 4: Testing
- [ ] Has tests
- [ ] Tests are good

### Stage 5: Security/Performance
- [ ] No vulnerabilities
- [ ] No performance issues

### Verdict: [ ] Approve [ ] Request Changes [ ] Comment

Integration with Other Skills

• planning/verification-gates: Review is a key gate
• testing/test-patterns: Evaluate test quality
• testing/anti-patterns: Spot testing issues