| name | comprehensive-review |
| description | Use after implementing features - 7-criteria code review with MANDATORY artifact posting to GitHub issue; blocks PR creation until complete |
Comprehensive Review
Overview
Review code against 7 criteria before considering it complete.
Core principle: Self-review catches issues before they reach others.
HARD REQUIREMENT: Review artifact MUST be posted to the GitHub issue. This is enforced by hooks.
Announce at start: "I'm performing a comprehensive code review."
Review Artifact Requirement
This is not optional. Before a PR can be created:
- Complete review against all 7 criteria
- Document all findings
- Post artifact to issue comment using EXACT format below
- Address all findings (fix or defer with tracking issues)
- Update artifact to show "Unaddressed: 0"
The review-gate skill and PreToolUse hook will BLOCK PR creation without this artifact.
The 7 Criteria
1. Blindspots
Question: What am I missing?
| Check | Ask Yourself |
|---|---|
| Edge cases | What happens at boundaries? Empty input? Max values? |
| Error paths | What if external services fail? Network issues? |
| Concurrency | Multiple users/threads? Race conditions? |
| State | What if called in wrong order? Invalid state? |
| Dependencies | What if dependency behavior changes? |
// Blindspot example: What if items is empty?
function calculateAverage(items: number[]): number {
return items.reduce((a, b) => a + b, 0) / items.length;
// Blindspot: Division by zero when items is empty!
}
// Fixed
function calculateAverage(items: number[]): number {
if (items.length === 0) {
throw new Error('Cannot calculate average of empty array');
}
return items.reduce((a, b) => a + b, 0) / items.length;
}
2. Clarity/Consistency
Question: Will someone else understand this?
| Check | Ask Yourself |
|---|---|
| Names | Do names describe what things do/are? |
| Structure | Is code organized logically? |
| Complexity | Can this be simplified? |
| Patterns | Does this match existing patterns? |
| Surprises | Would anything surprise a reader? |
3. Maintainability
Question: Can this be changed safely?
| Check | Ask Yourself |
|---|---|
| Coupling | Is this tightly bound to other code? |
| Cohesion | Does this do one thing well? |
| Duplication | Is logic repeated anywhere? |
| Tests | Do tests cover this adequately? |
| Extensibility | Can new features be added easily? |
4. Security Risks
Question: Can this be exploited?
| Check | Ask Yourself |
|---|---|
| Input validation | Is all input validated and sanitized? |
| Authentication | Is access properly controlled? |
| Authorization | Are permissions checked? |
| Data exposure | Is sensitive data protected? |
| Injection | SQL, XSS, command injection possible? |
| Dependencies | Are dependencies secure and updated? |
NOTE: If security-sensitive files are changed (auth, api, middleware, etc.), invoke security-review skill for deeper analysis.
5. Performance Implications
Question: Will this scale?
| Check | Ask Yourself |
|---|---|
| Algorithms | Is complexity appropriate? O(n²) when O(n) possible? |
| Database | N+1 queries? Missing indexes? Full table scans? |
| Memory | Large objects in memory? Memory leaks? |
| Network | Unnecessary requests? Large payloads? |
| Caching | Should results be cached? |
6. Documentation
Question: Is this documented adequately?
| Check | Ask Yourself |
|---|---|
| Public APIs | Are all public functions documented? |
| Parameters | Are parameter types and purposes clear? |
| Returns | Is return value documented? |
| Errors | Are thrown errors documented? |
| Examples | Are complex usages demonstrated? |
| Why | Are non-obvious decisions explained? |
See inline-documentation skill for documentation standards.
7. Standards and Style
Question: Does this follow project conventions?
| Check | Ask Yourself |
|---|---|
| Naming | Follows project naming conventions? |
| Formatting | Matches project formatting? |
| Patterns | Uses established patterns? |
| Types | Fully typed (no any)? |
| Language | Uses inclusive language? |
| IPv6-first | Network code uses IPv6 by default? IPv4 only for documented legacy? |
| Linting | Passes all linters? |
See style-guide-adherence, strict-typing, inclusive-language, ipv6-first skills.
Review Process
Step 1: Prepare
# Get list of changed files
git diff --name-only HEAD~1
# Get full diff
git diff HEAD~1
# Check for security-sensitive files
git diff --name-only HEAD~1 | grep -E '(auth|security|middleware|api|password|token|secret)'
# If matches found, security-review skill is MANDATORY
Step 2: Review Each Criterion
For each of the 7 criteria:
- Review all changed code
- Note any issues found
- Determine severity (Critical/Major/Minor)
Step 3: Check Security-Sensitive
If ANY security-sensitive files were changed:
- Invoke
security-reviewskill ORsecurity-reviewersubagent - Include security review results in artifact
- Mark "Security-Sensitive: YES" in artifact
Step 4: Document Findings
## Code Review Findings
### 1. Blindspots
- [ ] **Critical**: No handling for empty array in `calculateAverage()`
- [ ] **Minor**: Missing null check in `formatUser()`
### 2. Clarity/Consistency
- [ ] **Major**: Variable `x` should have descriptive name
### 3. Maintainability
- [x] No issues found
### 4. Security Risks
- [ ] **Critical**: SQL injection possible in `findUser()`
### 5. Performance Implications
- [ ] **Major**: N+1 query in `getOrdersWithUsers()`
### 6. Documentation
- [ ] **Minor**: Missing JSDoc on `processOrder()`
### 7. Standards and Style
- [x] Passes all checks
Step 5: Address All Findings
Use apply-all-findings skill to address every issue.
For findings that cannot be fixed:
- Use
deferred-findingskill to create tracking issue - Link tracking issue in artifact
- "Deferred without tracking issue" is NOT PERMITTED
Step 6: Post Artifact to Issue (MANDATORY)
Post review artifact as comment on the GitHub issue:
ISSUE_NUMBER=123
gh issue comment $ISSUE_NUMBER --body "$(cat <<'EOF'
<!-- REVIEW:START -->
## Code Review Complete
| Property | Value |
|----------|-------|
| Worker | `[WORKER_ID]` |
| Issue | #123 |
| Scope | [MINOR|MAJOR] |
| Security-Sensitive | [YES|NO] |
| Reviewed | [ISO_TIMESTAMP] |
### Criteria Results
| # | Criterion | Status | Findings |
|---|-----------|--------|----------|
| 1 | Blindspots | [✅ PASS|✅ FIXED|⚠️ DEFERRED] | [N] |
| 2 | Clarity | [✅ PASS|✅ FIXED|⚠️ DEFERRED] | [N] |
| 3 | Maintainability | [✅ PASS|✅ FIXED|⚠️ DEFERRED] | [N] |
| 4 | Security | [✅ PASS|✅ FIXED|⚠️ DEFERRED|N/A] | [N] |
| 5 | Performance | [✅ PASS|✅ FIXED|⚠️ DEFERRED] | [N] |
| 6 | Documentation | [✅ PASS|✅ FIXED|⚠️ DEFERRED] | [N] |
| 7 | Style | [✅ PASS|✅ FIXED|⚠️ DEFERRED] | [N] |
### Findings Fixed in This PR
| # | Severity | Finding | Resolution |
|---|----------|---------|------------|
| 1 | [SEVERITY] | [DESCRIPTION] | [HOW_FIXED] |
### Findings Deferred (With Tracking Issues)
| # | Severity | Finding | Tracking Issue | Justification |
|---|----------|---------|----------------|---------------|
| 1 | [SEVERITY] | [DESCRIPTION] | #[ISSUE] | [WHY] |
### Summary
| Category | Count |
|----------|-------|
| Fixed in PR | [N] |
| Deferred (with tracking) | [N] |
| Unaddressed | 0 |
**Review Status:** ✅ COMPLETE
<!-- REVIEW:END -->
EOF
)"
CRITICAL: "Unaddressed" MUST be 0. "Review Status" MUST be "COMPLETE".
Severity Levels
| Severity | Description | Action |
|---|---|---|
| Critical | Security issue, data loss, crash | Must fix before merge |
| Major | Significant bug, performance issue | Must fix before merge |
| Minor | Style, clarity, small improvement | Should fix before merge |
Checklist
Complete for every code review:
- Blindspots: Edge cases, errors, concurrency checked
- Clarity: Names, structure, complexity reviewed
- Maintainability: Coupling, cohesion, tests evaluated
- Security: Input, auth, injection, exposure checked (MANDATORY for sensitive files)
- Performance: Algorithms, queries, memory reviewed
- Documentation: Public APIs documented
- Style: Conventions followed
- All findings documented
- All findings addressed OR deferred with tracking issues
- Review artifact posted to issue (exact format)
- "Unaddressed: 0" in artifact
- "Review Status: COMPLETE" in artifact
Integration
This skill is called by:
issue-driven-development- Step 9
This skill uses:
review-scope- Determine review breadthapply-all-findings- Address issuessecurity-review- For security-sensitive changesdeferred-finding- For creating tracking issues
This skill is enforced by:
review-gate- Verifies artifact before PRPreToolUsehook - Blocks PR without artifact
This skill references:
inline-documentation- Documentation standardsstrict-typing- Type requirementsstyle-guide-adherence- Style requirementsinclusive-language- Language requirementsipv6-first- Network code requirements (IPv6 primary, IPv4 legacy)