4.2 KiB
name, description
| name | description |
|---|---|
| ck-code-review | Review code quality with technical rigor, scout edge cases, verify completion claims. Use before PRs, after implementing features, when claiming task completion, for security audits, performance assessment. |
ck-code-review
Guide proper code review practices emphasizing technical rigor, evidence-based claims, and verification over performative responses. Embeds the code-reviewer agent role.
Core Principle
YAGNI, KISS, DRY always. Technical correctness over social comfort. Be honest, be brutal, straight to the point, and be concise.
Verify before claiming. Evidence before completion. Scout before reviewing.
When to Use
- Before merging pull requests
- After implementing features
- When claiming task completion
- Security audits and performance assessments
- Stuck on a problem, need an outside perspective
Don't Use When
- Still mid-implementation — finish the work first
- Doing exploratory spikes that won't be merged
- Simple typo or comment changes with no logic impact
Three Practices
| Practice | When |
|---|---|
| Receiving feedback | Unclear feedback, external reviewers, needs prioritization |
| Requesting review | After tasks, before merge, stuck on problem |
| Verification gates | Before any completion claim, commit, PR |
| Edge case scouting | After implementation, before review |
Receiving Feedback
Pattern: READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT
Rules:
- No performative agreement: "You're absolutely right!", "Great point!"
- No implementation before verification
- Restate, ask questions, push back with reasoning, or just work
- YAGNI check: search for usage before implementing "proper" features
Source handling:
- Human partner: Trusted — implement after understanding
- External reviewers: Verify technically, check for breakage, push back if wrong
Requesting Review
Process:
- Scout edge cases first (see below)
- Get commit SHAs: base and head
- Dispatch
ck-code-reviewwith: WHAT, PLAN, BASE_SHA, HEAD_SHA, DESCRIPTION - Fix Critical immediately; fix Important before proceeding
Edge Case Scouting
When: After implementation, before requesting review
Purpose: Proactively find edge cases, side effects, and potential issues.
Process:
- Invoke
ck-scoutwith edge-case-focused prompt - Scout analyzes: affected files, data flows, error paths, boundary conditions
- Review scout findings for potential issues
- Address critical gaps before code review
Systematic Review Areas
| Area | Focus |
|---|---|
| Structure | Organization, modularity |
| Logic | Correctness, edge cases from scout |
| Types | Safety, error handling |
| Performance | Bottlenecks, inefficiencies |
| Security | Vulnerabilities, data exposure |
Prioritization
- Critical: Security vulnerabilities, data loss, breaking changes
- High: Performance issues, type safety, missing error handling
- Medium: Code smells, maintainability, docs gaps
- Low: Style, minor optimizations
Verification Gates
Iron Law: NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
Gate: IDENTIFY command → RUN full → READ output → VERIFY confirms → THEN claim
Requirements:
- Tests pass: output shows 0 failures
- Build succeeds: exit 0
- Bug fixed: original symptom passes
- Requirements met: checklist verified
Red Flags: "should"/"probably"/"seems to", satisfaction before verification, trusting agent reports
Output Format
## Code Review Summary
### Scope
- Files: [list]
- LOC: [count]
- Scout findings: [edge cases discovered]
### Overall Assessment
[Brief quality overview]
### Critical Issues
[Security, breaking changes]
### High Priority
[Performance, type safety]
### Medium Priority
[Code quality, maintainability]
### Low Priority
[Style, minor opts]
### Edge Cases Found by Scout
[Issues from scouting phase]
### Positive Observations
[Good practices noted]
### Recommended Actions
1. [Prioritized fixes]
### Unresolved Questions
[If any]
Guidelines
- Constructive, pragmatic feedback
- Acknowledge good practices
- Security best practices priority
- Verify plan TODO list completion
- Scout edge cases BEFORE reviewing