PR Review Checklist

A checklist for Pull Request reviews.

Usage#

@checklist:pr-review [PR number or link]

Quick Review (5-minute review)#

Minimum items to check when a quick review is needed:

• Build success (CI)
• Tests passing
• Lint check passing
• No security issues
• Breaking Changes verified

Full Review Checklist#

1. PR Meta Information#

• PR title follows convention
  • Format: type(scope): gitmoji description
  • Example: feat(auth): ✨ Add social login feature
• Related issues linked
• Appropriate labels assigned
• Reviewers properly assigned

2. Change Scope#

• PR purpose is clear
• Focused on a single purpose (one PR = one feature/fix)
• Change scope is appropriate (not too large)
• No unnecessary file changes

3. Code Quality#

Architecture

• Clean Architecture layer separation followed
• Dependency direction correct (Domain ← Data ← Presentation)
• No cross-feature module dependencies

Naming & Readability

• Meaningful variable/function names
• Project naming conventions followed
• Appropriate comments (not too many, not too few)

Code Structure

• No duplicate code (DRY)
• Single Responsibility Principle followed
• Appropriate abstraction level

4. State Management (BLoC)#

• Event/State using Freezed
• Appropriate state separation
• Error handling implemented
• Loading state handled
• Resources released in dispose

5. Testing#

• Tests added for new features
• Existing tests passing
• Edge case tests included
• Mock/Fake used appropriately

# Verify test execution
melos run test

6. Security#

• No hardcoded secrets
• No sensitive information in logs
• Input validation applied
• Authentication/authorization properly applied

7. Performance#

• No N+1 query issues
• Unnecessary re-renders prevented
• Image optimization applied
• Appropriate caching strategy

8. Internationalization#

• No hardcoded strings
• Translation keys added
• Pluralization/parameter handling correct

9. Accessibility#

• Semantic labels applied
• Touch target size appropriate
• Color contrast appropriate

10. Documentation#

• Public API documented
• Breaking Changes documented
• README updated (if needed)

Must-Have (cannot Approve)#

If any of these items have issues, cannot Approve:

1. Build failure
2. Test failure
3. Security vulnerability
4. Undocumented Breaking Change
5. Architecture violation

Should-Have (can Approve after requesting improvements)#

Can Approve after requesting improvements (fix in follow-up PR):

1. Insufficient performance optimization
2. Insufficient test coverage
3. Insufficient documentation
4. Insufficient accessibility

Nice-to-Have (comment only)#

Leave comment only and Approve:

1. Naming improvement suggestions
2. Code style suggestions
3. Additional optimization suggestions

Review Comment Templates#

Required Fix (Blocking)#

🔴 **[Required]** {description}

{code location}: {file}:{line}

**Problem**: {problem description}
**Suggestion**: {solution}

Improvement Request (Non-blocking)#

🟡 **[Improvement]** {description}

{code location}: {file}:{line}

**Current**: {current code}
**Suggestion**: {improved code}

Suggestion/Question#

🟢 **[Suggestion]** {description}

{code location}: {file}:{line}

**Question/Suggestion**: {content}

Praise#

✨ **Nice!** {description}

{code location}: {file}:{line}

{praise content}

Review Results#

Approve ✅#

LGTM! 🎉

All checklist items verified.
- Build successful
- Tests passing
- No security issues

Request Changes 🔄#

Changes requested.

**Required fixes** (must resolve before merge):
1. {item 1}
2. {item 2}

**Recommended fixes** (optional):
1. {item 1}

Comment 💬#

Overall looks good. A few questions/suggestions.

**Questions**:
1. {question 1}

**Suggestions**:
1. {suggestion 1}

CI/CD Verification#

# Check CI status
gh pr checks [PR_NUMBER]

# View build logs
gh pr view [PR_NUMBER] --web

• Build successful
• Test successful
• Lint successful
• Coverage check

Related Agents#

• @code-review: Detailed code review
• @test: Test review
• @feature: Architecture review
• @bloc: State management review