Use after implementing features - 7-criteria code review with MANDATORY artifact posting to GitHub issue; blocks PR creation until complete
Performs comprehensive 7-criteria code review after implementation. Triggers after features are built; requires mandatory artifact posting to GitHub issue before PR creation can proceed.
/plugin marketplace add troykelly/claude-skills/plugin install issue-driven-development@troykelly-skillsThis skill is limited to using the following tools:
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."
This is not optional. Before a PR can be created:
The review-gate skill and PreToolUse hook will BLOCK PR creation without this artifact.
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;
}
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? |
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? |
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.
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? |
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.
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.
# 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
For each of the 7 criteria:
If ANY security-sensitive files were changed:
security-review skill OR security-reviewer subagent## 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
Use apply-all-findings skill to address every issue.
For findings that cannot be fixed:
deferred-finding skill to create tracking issuePost 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 | 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 |
Complete for every code review:
This skill is called by:
issue-driven-development - Step 9This skill uses:
review-scope - Determine review breadthapply-all-findings - Address issuessecurity-review - For security-sensitive changesdeferred-finding - For creating tracking issuesThis skill is enforced by:
review-gate - Verifies artifact before PRPreToolUse hook - Blocks PR without artifactThis skill references:
inline-documentation - Documentation standardsstrict-typing - Type requirementsstyle-guide-adherence - Style requirementsinclusive-language - Language requirementsipv6-first - Network code requirements (IPv6 primary, IPv4 legacy)This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.