Code Review Playbook
This skill provides a comprehensive framework for effective code reviews that improve code quality, share knowledge, and foster collaboration. Whether you're a reviewer giving feedback or an author preparing code for review, this playbook ensures reviews are thorough, consistent, and constructive.
Overview
- Reviewing pull requests or merge requests
- Preparing code for review (self-review)
- Establishing code review standards for teams
- Training new developers on review best practices
- Resolving disagreements about code quality
- Improving review processes and efficiency
Code Review Philosophy
Purpose of Code Reviews
Code reviews serve multiple purposes:
- Quality Assurance: Catch bugs, logic errors, and edge cases
- Knowledge Sharing: Spread domain knowledge across the team
- Consistency: Ensure codebase follows conventions and patterns
- Mentorship: Help developers improve their skills
- Collective Ownership: Build shared responsibility for code
- Documentation: Create discussion history for future reference
Principles
Be Kind and Respectful:
- Review the code, not the person
- Assume positive intent
- Praise good solutions
- Frame feedback constructively
Be Specific and Actionable:
- Point to specific lines of code
- Explain why something should change
- Suggest concrete improvements
- Provide examples when helpful
Balance Speed with Thoroughness:
- Aim for timely feedback (< 24 hours)
- Don't rush critical reviews
- Use automation for routine checks
- Focus human review on logic and design
Distinguish Must-Fix from Nice-to-Have:
- Use conventional comments to indicate severity
- Block merges only for critical issues
- Allow authors to defer minor improvements
- Capture deferred work in follow-up tickets
Conventional Comments
issue [blocking]: Missing error handling for API call
If the API returns a 500 error, this will crash. Add try/catch.
security [blocking]: API endpoint is not authenticated
The /api/admin/users endpoint is missing auth middleware.
Load Read("${CLAUDE_SKILL_DIR}/references/conventional-comments.md") for the full format, labels (praise, nitpick, suggestion, issue, question, security, bug, breaking), decorations ([blocking], [non-blocking], [if-minor]), and examples.
Review Process
1. Before Reviewing
Check Context:
- Read the PR/MR description
- Understand the purpose and scope
- Review linked tickets or issues
- Check CI/CD pipeline status
Verify Automated Checks:
Set Aside Time:
- Small PR (< 200 lines): 15-30 minutes
- Medium PR (200-500 lines): 30-60 minutes
- Large PR (> 500 lines): 1-2 hours (or ask to split)
2. During Review
Follow a Pattern:
High-Level Review (5-10 minutes)
- Read PR description and understand intent
- Skim all changed files to get overview
- Verify approach makes sense architecturally
- Check that changes align with stated purpose
Detailed Review (20-45 minutes)
- Line-by-line code review
- Check logic, edge cases, error handling
- Verify tests cover new code
- Look for security vulnerabilities
- Ensure code follows team conventions
Testing Considerations (5-10 minutes)
- Are tests comprehensive?
- Do tests test the right things?
- Are edge cases covered?
- Is test data realistic?
Documentation Check (5 minutes)
- Are complex sections commented?
- Is public API documented?
- Are breaking changes noted?
- Is README updated if needed?
3. After Reviewing
Provide Clear Decision:
- ✅ Approve: Code is ready to merge
- 💬 Comment: Feedback provided, no action required
- 🔄 Request Changes: Issues must be addressed before merge
Respond to Author:
- Answer questions promptly
- Re-review after changes made
- Approve when issues resolved
- Thank author for addressing feedback
Review Checklists
General Code Quality
Security
Quick Start Guide
For Reviewers:
- Read PR description and understand intent
- Check that automated checks pass
- Do high-level review (architecture, approach)
- Do detailed review (logic, edge cases, tests)
- Use conventional comments for clear communication
- Provide decision: Approve, Comment, or Request Changes
For Authors:
- Write clear PR description
- Perform self-review before requesting review
- Ensure all automated checks pass
- Keep PR focused and reasonably sized (< 400 lines)
- Respond to feedback promptly and respectfully
- Make requested changes or explain reasoning
Skill Version: 2.0.0
Last Updated: 2026-01-08
Maintained by: AI Agent Hub Team
Related Skills
ork:architecture-patterns - Enforce testing and architectural best practices during code review
security-scanning - Automated security checks to complement manual review
ork:testing-unit - Unit testing patterns to verify during review
Rules
Each category has individual rule files in rules/ loaded on-demand:
| Category |
Rule |
Impact |
Key Pattern |
| TypeScript Quality |
rules/typescript-quality.md |
HIGH |
No any, Zod validation, exhaustive switches, React 19 |
| Python Quality |
rules/python-quality.md |
HIGH |
Pydantic v2, ruff, mypy strict, async timeouts |
| Security Baseline |
rules/security-baseline.md |
CRITICAL |
No secrets, auth on endpoints, input validation |
| Linting |
rules/linting-biome-setup.md |
HIGH |
Biome setup, ESLint migration, gradual adoption |
| Linting |
rules/linting-biome-rules.md |
HIGH |
Biome config, type-aware rules, CI integration |
Total: 5 rules across 4 categories
Available Scripts
scripts/review-pr.md - Dynamic PR review with auto-fetched GitHub data
- Auto-fetches: PR title, author, state, changed files, diff stats, comments count
- Usage:
/ork:review-pr [PR-number]
- Requires: GitHub CLI (
gh)
- Uses
$ARGUMENTS and !command for live PR data
assets/review-feedback-template.md - Static review feedback template
assets/pr-template.md - PR description template
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: code-review-playbook3description: Use this skill when conducting or improving code reviews. Provides structured review processes, conventional comments patterns, language-specific checklists, and feedback templates. Use when reviewing PRs or standardizing review practices.4license: MIT5---67# Code Review Playbook8This skill provides a comprehensive framework for effective code reviews that improve code quality, share knowledge, and foster collaboration. Whether you're a reviewer giving feedback or an author preparing code for review, this playbook ensures reviews are thorough, consistent, and constructive.910## Overview11- Reviewing pull requests or merge requests12- Preparing code for review (self-review)13- Establishing code review standards for teams14- Training new developers on review best practices15- Resolving disagreements about code quality16- Improving review processes and efficiency1718## Code Review Philosophy1920### Purpose of Code Reviews2122Code reviews serve multiple purposes:23241. **Quality Assurance**: Catch bugs, logic errors, and edge cases252. **Knowledge Sharing**: Spread domain knowledge across the team263. **Consistency**: Ensure codebase follows conventions and patterns274. **Mentorship**: Help developers improve their skills285. **Collective Ownership**: Build shared responsibility for code296. **Documentation**: Create discussion history for future reference3031### Principles3233**Be Kind and Respectful:**34- Review the code, not the person35- Assume positive intent36- Praise good solutions37- Frame feedback constructively3839**Be Specific and Actionable:**40- Point to specific lines of code41- Explain *why* something should change42- Suggest concrete improvements43- Provide examples when helpful4445**Balance Speed with Thoroughness:**46- Aim for timely feedback (< 24 hours)47- Don't rush critical reviews48- Use automation for routine checks49- Focus human review on logic and design5051**Distinguish Must-Fix from Nice-to-Have:**52- Use conventional comments to indicate severity53- Block merges only for critical issues54- Allow authors to defer minor improvements55- Capture deferred work in follow-up tickets5657---5859## Conventional Comments6061```62issue [blocking]: Missing error handling for API call63If the API returns a 500 error, this will crash. Add try/catch.6465security [blocking]: API endpoint is not authenticated66The /api/admin/users endpoint is missing auth middleware.67```6869Load `Read("${CLAUDE_SKILL_DIR}/references/conventional-comments.md")` for the full format, labels (praise, nitpick, suggestion, issue, question, security, bug, breaking), decorations ([blocking], [non-blocking], [if-minor]), and examples.7071---7273## Review Process7475### 1. Before Reviewing7677**Check Context:**78- Read the PR/MR description79- Understand the purpose and scope80- Review linked tickets or issues81- Check CI/CD pipeline status8283**Verify Automated Checks:**84- [ ] Tests are passing85- [ ] Linting has no errors86- [ ] Type checking passes87- [ ] Code coverage meets targets88- [ ] No merge conflicts8990**Set Aside Time:**91- Small PR (< 200 lines): 15-30 minutes92- Medium PR (200-500 lines): 30-60 minutes93- Large PR (> 500 lines): 1-2 hours (or ask to split)9495### 2. During Review9697**Follow a Pattern:**98991. **High-Level Review** (5-10 minutes)100 - Read PR description and understand intent101 - Skim all changed files to get overview102 - Verify approach makes sense architecturally103 - Check that changes align with stated purpose1041052. **Detailed Review** (20-45 minutes)106 - Line-by-line code review107 - Check logic, edge cases, error handling108 - Verify tests cover new code109 - Look for security vulnerabilities110 - Ensure code follows team conventions1111123. **Testing Considerations** (5-10 minutes)113 - Are tests comprehensive?114 - Do tests test the right things?115 - Are edge cases covered?116 - Is test data realistic?1171184. **Documentation Check** (5 minutes)119 - Are complex sections commented?120 - Is public API documented?121 - Are breaking changes noted?122 - Is README updated if needed?123124### 3. After Reviewing125126**Provide Clear Decision:**127- ✅ **Approve**: Code is ready to merge128- 💬 **Comment**: Feedback provided, no action required129- 🔄 **Request Changes**: Issues must be addressed before merge130131**Respond to Author:**132- Answer questions promptly133- Re-review after changes made134- Approve when issues resolved135- Thank author for addressing feedback136137---138139## Review Checklists140141### General Code Quality142143- [ ] **Readability**: Code is easy to understand144- [ ] **Naming**: Variables and functions have clear, descriptive names145- [ ] **Comments**: Complex logic is explained146- [ ] **Formatting**: Code follows team style guide147- [ ] **DRY**: No unnecessary duplication148- [ ] **SOLID Principles**: Code follows SOLID where applicable149- [ ] **Function Size**: Functions are focused and < 50 lines150- [ ] **Cyclomatic Complexity**: Functions have complexity < 10151152### Security153154- [ ] **Authentication**: Protected endpoints require auth155- [ ] **Authorization**: Users can only access their own data156- [ ] **Input Sanitization**: SQL injection, XSS prevented157- [ ] **Secrets Management**: No hardcoded credentials or API keys158- [ ] **Encryption**: Sensitive data encrypted at rest and in transit159- [ ] **Rate Limiting**: Endpoints protected from abuse160161---162163## Quick Start Guide164165**For Reviewers:**1661. Read PR description and understand intent1672. Check that automated checks pass1683. Do high-level review (architecture, approach)1694. Do detailed review (logic, edge cases, tests)1705. Use conventional comments for clear communication1716. Provide decision: Approve, Comment, or Request Changes172173**For Authors:**1741. Write clear PR description1752. Perform self-review before requesting review1763. Ensure all automated checks pass1774. Keep PR focused and reasonably sized (< 400 lines)1785. Respond to feedback promptly and respectfully1796. Make requested changes or explain reasoning180181---182183**Skill Version**: 2.0.0184**Last Updated**: 2026-01-08185**Maintained by**: AI Agent Hub Team186187## Related Skills188189- `ork:architecture-patterns` - Enforce testing and architectural best practices during code review190- `security-scanning` - Automated security checks to complement manual review191- `ork:testing-unit` - Unit testing patterns to verify during review192193## Rules194195Each category has individual rule files in `rules/` loaded on-demand:196197| Category | Rule | Impact | Key Pattern |198|----------|------|--------|-------------|199| TypeScript Quality | `rules/typescript-quality.md` | HIGH | No `any`, Zod validation, exhaustive switches, React 19 |200| Python Quality | `rules/python-quality.md` | HIGH | Pydantic v2, ruff, mypy strict, async timeouts |201| Security Baseline | `rules/security-baseline.md` | CRITICAL | No secrets, auth on endpoints, input validation |202| Linting | `rules/linting-biome-setup.md` | HIGH | Biome setup, ESLint migration, gradual adoption |203| Linting | `rules/linting-biome-rules.md` | HIGH | Biome config, type-aware rules, CI integration |204205**Total: 5 rules across 4 categories**206207## Available Scripts208209- **`scripts/review-pr.md`** - Dynamic PR review with auto-fetched GitHub data210 - Auto-fetches: PR title, author, state, changed files, diff stats, comments count211 - Usage: `/ork:review-pr [PR-number]`212 - Requires: GitHub CLI (`gh`)213 - Uses `$ARGUMENTS` and `!command` for live PR data214215- **`assets/review-feedback-template.md`** - Static review feedback template216- **`assets/pr-template.md`** - PR description template217218---219> Converted and distributed by [TomeVault](https://tomevault.io/claim/yonatangross) — claim your Tome and manage your conversions.220<!-- tomevault:4.0:skill_md:2026-04-11 -->