150 lines
4.2 KiB
Markdown
150 lines
4.2 KiB
Markdown
---
|
|
name: ck-code-review
|
|
description: 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:**
|
|
1. **Scout edge cases first** (see below)
|
|
2. Get commit SHAs: base and head
|
|
3. Dispatch `ck-code-review` with: WHAT, PLAN, BASE_SHA, HEAD_SHA, DESCRIPTION
|
|
4. 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:**
|
|
1. Invoke `ck-scout` with edge-case-focused prompt
|
|
2. Scout analyzes: affected files, data flows, error paths, boundary conditions
|
|
3. Review scout findings for potential issues
|
|
4. 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
|
|
|
|
```markdown
|
|
## 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
|