Claude-skill-registry comprehensive-review
Use after implementing features - 7-criteria code review with MANDATORY artifact posting to GitHub issue; blocks PR creation until complete
git clone https://github.com/majiayu000/claude-skill-registry
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/comprehensive-review-troykelly-claude-skills" ~/.claude/skills/majiayu000-claude-skill-registry-comprehensive-review && rm -rf "$T"
skills/data/comprehensive-review-troykelly-claude-skills/SKILL.mdComprehensive 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 )? |
| 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
skill ORsecurity-review
subagentsecurity-reviewer - 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
skill to create tracking issuedeferred-finding - 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:
- Step 9issue-driven-development
This skill uses:
- Determine review breadthreview-scope
- Address issuesapply-all-findings
- For security-sensitive changessecurity-review
- For creating tracking issuesdeferred-finding
This skill is enforced by:
- Verifies artifact before PRreview-gate
hook - Blocks PR without artifactPreToolUse
This skill references:
- Documentation standardsinline-documentation
- Type requirementsstrict-typing
- Style requirementsstyle-guide-adherence
- Language requirementsinclusive-language
- Network code requirements (IPv6 primary, IPv4 legacy)ipv6-first