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
Upstream coverage (do not restate)
This skill is a thin wrapper. General review craft is documented first-party elsewhere;
only OrchestKit's own decisions live here. Load Read("references/ork-delta.md")
for the house rules that survived the retired files.
| Topic |
Go here instead |
| Review philosophy, speed, tone, PR sizing |
https://google.github.io/eng-practices/review/ |
| Conventional comment labels and decorations |
references/conventional-comments.md, https://conventionalcomments.org/ |
| OWASP Top 10 review checks |
rules/security-baseline.md, https://owasp.org/Top10/ |
| Generic language and framework review checklists |
rules/typescript-quality.md, rules/python-quality.md, rules/linting-biome-rules.md |
| Review report shape and multi-agent full-PR review |
ork:review-pr |
| Applying findings to the working tree |
/code-review --fix, /simplify (see below) |
| Security-only pass over the current branch |
/security-review |
| GitHub review mechanics (approve, request changes, inline comments) |
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests |
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("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
CC Built-in Review Commands (2.1.152+)
This playbook is the manual framework; Claude Code ships built-in commands that automate parts of it:
/code-review — reviews the current diff for correctness bugs and reuse/simplification/efficiency cleanups./code-review --fix (CC 2.1.152+) — runs the review then applies the findings to your working tree (a bug-hunting review covering correctness plus reuse/simplification/efficiency)./code-review --comment — posts findings as inline PR comments./simplify — CC 2.1.154 changed this: it now runs a cleanup-only review (reuse, simplification, efficiency, altitude) and applies the fixes — it no longer invokes the full /code-review --fix bug-hunt. Reach for /simplify for tidy-ups, /code-review --fix for bug-finding-plus-fix.
Use the built-ins for fast diff-scoped passes; use ork:review-pr for the multi-agent, full-PR review (security + testing + architecture).
Skill Version: 2.0.0
Last Updated: 2026-01-08
Maintained by: OrchestKit
Related Skills
ork:architecture-patterns - Enforce testing and architectural best practices during code reviework:security-patterns - Auth, input validation, and OWASP patterns to complement manual reviework: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
There is deliberately no review-report template here; ork:review-pr owns that output
shape. See references/ork-delta.md.
1---2name: code-review-playbook3description: Structured review processes, conventional comments, language-specific checklists, and feedback templates. Use when reviewing PRs, conducting code review, or standardizing review practice.4license: MIT5---6
7# Code Review Playbook
8This 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.
9
10## Overview
11- Reviewing pull requests or merge requests
12- Preparing code for review (self-review)
13- Establishing code review standards for teams
14- Training new developers on review best practices
15- Resolving disagreements about code quality
16- Improving review processes and efficiency
17
18## Upstream coverage (do not restate)
19
20This skill is a thin wrapper. General review craft is documented first-party elsewhere;
21only OrchestKit's own decisions live here. Load `Read("references/ork-delta.md")`
22for the house rules that survived the retired files.
23
24| Topic | Go here instead |
25|-------|-----------------|
26| Review philosophy, speed, tone, PR sizing | https://google.github.io/eng-practices/review/ |
27| Conventional comment labels and decorations | `references/conventional-comments.md`, https://conventionalcomments.org/ |
28| OWASP Top 10 review checks | `rules/security-baseline.md`, https://owasp.org/Top10/ |
29| Generic language and framework review checklists | `rules/typescript-quality.md`, `rules/python-quality.md`, `rules/linting-biome-rules.md` |
30| Review report shape and multi-agent full-PR review | `ork:review-pr` |
31| Applying findings to the working tree | `/code-review --fix`, `/simplify` (see below) |
32| Security-only pass over the current branch | `/security-review` |
33| GitHub review mechanics (approve, request changes, inline comments) | https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests |
34
35---
36
37## Conventional Comments
38
39```
40issue [blocking]: Missing error handling for API call
41If the API returns a 500 error, this will crash. Add try/catch.
42
43security [blocking]: API endpoint is not authenticated
44The /api/admin/users endpoint is missing auth middleware.
45```
46
47Load `Read("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.
48
49---
50
51## Review Process
52
53### 1. Before Reviewing
54
55**Check Context:**
56- Read the PR/MR description
57- Understand the purpose and scope
58- Review linked tickets or issues
59- Check CI/CD pipeline status
60
61**Verify Automated Checks:**
62- [ ] Tests are passing
63- [ ] Linting has no errors
64- [ ] Type checking passes
65- [ ] Code coverage meets targets
66- [ ] No merge conflicts
67
68**Set Aside Time:**
69- Small PR (< 200 lines): 15-30 minutes
70- Medium PR (200-500 lines): 30-60 minutes
71- Large PR (> 500 lines): 1-2 hours (or ask to split)
72
73### 2. During Review
74
75**Follow a Pattern:**
76
771. **High-Level Review** (5-10 minutes)
78 - Read PR description and understand intent
79 - Skim all changed files to get overview
80 - Verify approach makes sense architecturally
81 - Check that changes align with stated purpose
82
832. **Detailed Review** (20-45 minutes)
84 - Line-by-line code review
85 - Check logic, edge cases, error handling
86 - Verify tests cover new code
87 - Look for security vulnerabilities
88 - Ensure code follows team conventions
89
903. **Testing Considerations** (5-10 minutes)
91 - Are tests comprehensive?
92 - Do tests test the right things?
93 - Are edge cases covered?
94 - Is test data realistic?
95
964. **Documentation Check** (5 minutes)
97 - Are complex sections commented?
98 - Is public API documented?
99 - Are breaking changes noted?
100 - Is README updated if needed?
101
102### 3. After Reviewing
103
104**Provide Clear Decision:**
105- ✅ **Approve**: Code is ready to merge
106- 💬 **Comment**: Feedback provided, no action required
107- 🔄 **Request Changes**: Issues must be addressed before merge
108
109**Respond to Author:**
110- Answer questions promptly
111- Re-review after changes made
112- Approve when issues resolved
113- Thank author for addressing feedback
114
115---
116
117## Review Checklists
118
119### General Code Quality
120
121- [ ] **Readability**: Code is easy to understand
122- [ ] **Naming**: Variables and functions have clear, descriptive names
123- [ ] **Comments**: Complex logic is explained
124- [ ] **Formatting**: Code follows team style guide
125- [ ] **DRY**: No unnecessary duplication
126- [ ] **SOLID Principles**: Code follows SOLID where applicable
127- [ ] **Function Size**: Functions are focused and < 50 lines
128- [ ] **Cyclomatic Complexity**: Functions have complexity < 10
129
130### Security
131
132- [ ] **Authentication**: Protected endpoints require auth
133- [ ] **Authorization**: Users can only access their own data
134- [ ] **Input Sanitization**: SQL injection, XSS prevented
135- [ ] **Secrets Management**: No hardcoded credentials or API keys
136- [ ] **Encryption**: Sensitive data encrypted at rest and in transit
137- [ ] **Rate Limiting**: Endpoints protected from abuse
138
139---
140
141## Quick Start Guide
142
143**For Reviewers:**
1441. Read PR description and understand intent
1452. Check that automated checks pass
1463. Do high-level review (architecture, approach)
1474. Do detailed review (logic, edge cases, tests)
1485. Use conventional comments for clear communication
1496. Provide decision: Approve, Comment, or Request Changes
150
151**For Authors:**
1521. Write clear PR description
1532. Perform self-review before requesting review
1543. Ensure all automated checks pass
1554. Keep PR focused and reasonably sized (< 400 lines)
1565. Respond to feedback promptly and respectfully
1576. Make requested changes or explain reasoning
158
159---
160
161## CC Built-in Review Commands (2.1.152+)
162
163This playbook is the manual framework; Claude Code ships built-in commands that automate parts of it:
164
165- **`/code-review`** — reviews the current diff for correctness bugs and reuse/simplification/efficiency cleanups.
166- **`/code-review --fix`** (CC 2.1.152+) — runs the review then applies the findings to your working tree (a bug-hunting review covering correctness plus reuse/simplification/efficiency).
167- **`/code-review --comment`** — posts findings as inline PR comments.
168- **`/simplify`** — **CC 2.1.154 changed this**: it now runs a **cleanup-only** review (reuse, simplification, efficiency, altitude) and applies the fixes — it no longer invokes the full `/code-review --fix` bug-hunt. Reach for `/simplify` for tidy-ups, `/code-review --fix` for bug-finding-plus-fix.
169
170Use the built-ins for fast diff-scoped passes; use `ork:review-pr` for the multi-agent, full-PR review (security + testing + architecture).
171
172---
173
174**Skill Version**: 2.0.0
175**Last Updated**: 2026-01-08
176**Maintained by**: OrchestKit
177
178## Related Skills
179
180- `ork:architecture-patterns` - Enforce testing and architectural best practices during code review
181- `ork:security-patterns` - Auth, input validation, and OWASP patterns to complement manual review
182- `ork:testing-unit` - Unit testing patterns to verify during review
183
184## Rules
185
186Each category has individual rule files in `rules/` loaded on-demand:
187
188| Category | Rule | Impact | Key Pattern |
189|----------|------|--------|-------------|
190| TypeScript Quality | `rules/typescript-quality.md` | HIGH | No `any`, Zod validation, exhaustive switches, React 19 |
191| Python Quality | `rules/python-quality.md` | HIGH | Pydantic v2, ruff, mypy strict, async timeouts |
192| Security Baseline | `rules/security-baseline.md` | CRITICAL | No secrets, auth on endpoints, input validation |
193| Linting | `rules/linting-biome-setup.md` | HIGH | Biome setup, ESLint migration, gradual adoption |
194| Linting | `rules/linting-biome-rules.md` | HIGH | Biome config, type-aware rules, CI integration |
195
196**Total: 5 rules across 4 categories**
197
198## Available Scripts
199
200- **`scripts/review-pr.md`** - Dynamic PR review with auto-fetched GitHub data
201 - Auto-fetches: PR title, author, state, changed files, diff stats, comments count
202 - Usage: `/ork:review-pr [PR-number]`
203 - Requires: GitHub CLI (`gh`)
204 - Uses `$ARGUMENTS` and `!command` for live PR data
205
206- **`assets/pr-template.md`** - PR description template
207
208There is deliberately no review-report template here; `ork:review-pr` owns that output
209shape. See `references/ork-delta.md`.
yonatangross