Requesting Code Expert

A focused skill for systematically requesting, conducting, and managing code reviews. Covers creating effective review requests, structuring feedback, using automated review tools, and establishing team review workflows that catch bugs without slowing delivery.

When to Use This Skill

Choose this skill when:

• Preparing a pull request for team review and want structured feedback
• Setting up automated code review with linters, static analysis, and CI checks
• Establishing code review guidelines and checklists for a team
• Reviewing others' code and need a systematic approach
• Configuring GitHub/GitLab review workflows with CODEOWNERS and required reviewers

Consider alternatives when:

• Need automated testing rather than review → use a testing skill
• Want to refactor code yourself → use a refactoring skill
• Setting up CI/CD pipelines → use a CI/CD skill
• Need security-specific auditing → use a security audit skill

Quick Start

Copy
# Create a well-structured PR for review
git checkout -b feature/user-auth
# ... make changes ...
git add -A && git commit -m "feat: add JWT authentication middleware"

# Push and create PR with structured description
gh pr create \
  --title "feat: Add JWT authentication middleware" \
  --body "## What
Adds JWT-based auth middleware for protected routes.

## Why
Replacing session-based auth to support stateless API scaling.

## How
- JWT verification middleware in \`src/middleware/auth.ts\`
- Token refresh endpoint at \`POST /auth/refresh\`
- Protected route wrapper for Express routers

## Testing
- Unit tests for token verification
- Integration tests for refresh flow
- Manual testing with Postman collection

## Review Focus
- Security of token validation logic
- Error handling edge cases
- Middleware ordering correctness"

Core Concepts

Review Request Checklist

Before Requesting	Why
Self-review the diff line by line	Catch obvious issues before reviewer's time
Run all tests locally	Don't waste review cycles on broken code
Keep PR under 400 lines changed	Large PRs get shallow reviews
Write descriptive PR title and body	Context reduces back-and-forth
Link related issues and docs	Reviewers understand the "why"
Add inline comments on complex logic	Preempt questions about intent

Automated Review Configuration

Copy
# .github/CODEOWNERS
# Require review from specific teams based on file paths
/src/auth/          @security-team
/src/api/           @backend-team
/src/components/    @frontend-team
/infrastructure/    @devops-team
*.sql               @dba-team

# .github/pull_request_template.md
## What does this PR do?
<!-- Brief description -->

## Type of change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Refactoring (no behavior change)

## Checklist
- [ ] Tests pass locally
- [ ] Self-reviewed the code
- [ ] Added/updated tests for changes
- [ ] Updated documentation if needed

Structured Code Review Feedback

Copy
# Review feedback categories (prefix convention)

## Blocking (must fix before merge):
🚫 **Bug**: `processPayment()` doesn't handle negative amounts
🚫 **Security**: SQL string interpolation at line 42 — use parameterized query

## Suggestions (recommended but not blocking):
💡 **Simplify**: This nested ternary could be a switch statement for readability
💡 **Performance**: Consider memoizing this computed value — it's called 50x per render

## Nitpicks (optional style preferences):
🔸 **Nit**: Prefer `const` over `let` here since value isn't reassigned
🔸 **Nit**: Import order — group third-party imports above local imports

## Praise (reinforce good patterns):
✅ **Nice**: Great error handling here with specific error types
✅ **Nice**: Clean separation of concerns between service and controller

Configuration

Parameter	Type	Default	Description
requiredApprovals	number	1	Minimum approvals before merge
codeownersRequired	boolean	true	Require review from code owners
maxPRSize	number	400	Warning threshold for lines changed
autoAssignReviewers	boolean	true	Auto-assign based on CODEOWNERS
staleReviewDismissal	boolean	true	Dismiss approvals when new commits push
requiredChecks	string[]	['tests', 'lint']	CI checks that must pass before review

Best Practices

1. Keep pull requests focused and small — A PR should represent one logical change. Split large features into a chain of smaller PRs (data model → API → UI). Reviewers give more thorough feedback on 200-line PRs than 2000-line PRs.

2. Respond to every review comment — Even if you disagree, acknowledge the feedback. Resolve conversations only after both parties agree. Leaving comments unresolved breeds resentment and reduces review quality over time.

3. Use prefix conventions for review feedback — Distinguish blocking issues from suggestions and nitpicks. This eliminates ambiguity about whether a comment requires changes before merge and keeps reviews focused on what matters.

4. Review your own PR first — Before requesting review, go through the diff as if you're the reviewer. You'll catch at least 30% of issues yourself — debug logging left in, missing error handling, unclear variable names.

5. Set up automated checks to free reviewers for logic review — Linting, formatting, type checking, and test execution should be automated in CI. Human reviewers should focus on architecture, logic correctness, and edge cases — not indentation.

Common Issues

Reviews take days, blocking delivery — Set SLA expectations (e.g., first response within 4 hours). Use reviewer rotation rather than assigning all reviews to the same senior developer. Enable auto-merge after approval to remove manual merge delay.

Reviewers only comment on style, miss logic bugs — Automate style enforcement with Prettier and ESLint. This redirects human attention to business logic, concurrency issues, and architectural concerns that tools can't catch.

PR description says "fixed stuff" with no context — Enforce PR templates through GitHub/GitLab settings. A mandatory template with What/Why/How sections ensures reviewers have enough context. Reject PRs without meaningful descriptions.