| name | code-review |
| description | This skill should be used when reviewing code before commit, conducting quality gates, or when review, fresh eyes, pre-commit review, or quality gate are mentioned. |
| metadata | {"version":"1.0.1"} |
Fresh Eyes Review
Systematic pre-commit quality gate โ checklist-based review โ findings โ summary.
<when_to_use>
- Pre-commit code review and quality gates
- Pre-merge pull request reviews
- Systematic code audits before deployment
- Quality verification for critical changes
- Second-opinion review requests
NOT for: quick sanity checks, trivial typo fixes, formatting-only changes
</when_to_use>
<announcement_protocol>
Starting Review
Review Scope: { files/areas under review }
Focus Areas: { specific concerns or general quality gate }
Checklist: { full or targeted categories }
During Review
Emit findings as discovered:
- {SEVERITY}
{FILE_PATH}:{LINE} โ { issue description }
- Impact: { consequences if shipped }
- Fix: { concrete remediation }
Completing Review
Review Complete
Findings Summary:
- โ Severe: {COUNT} โ blocking issues
- โ Moderate: {COUNT} โ should fix before merge
- โ Minor: {COUNT} โ consider addressing
Recommendation: { ship / fix blockers / needs rework }
{ detailed findings below if any found }
</announcement_protocol>
Type Safety
- โ No
any types without justification comment
- โ Null/undefined handled explicitly (optional chaining, nullish coalescing)
- โ Type guards used for union types
- โ Discriminated unions for state machines
- โ Generic constraints specified where needed
- โ Return types explicit on public functions
- โ No type assertions without safety comment
Error Handling
- โ All error paths handled (no silent failures)
- โ Meaningful error messages with context
- โ Errors propagated or logged appropriately
- โ Result types used for expected failures
- โ Try/catch blocks have specific error handling
- โ Promise rejections handled
- โ Resource cleanup in finally blocks
Security
- โ User input validated before use
- โ No hardcoded secrets or credentials
- โ Authentication/authorization checks present
- โ Parameterized queries (no SQL injection)
- โ XSS prevention (sanitized output)
- โ CSRF protection where applicable
- โ Sensitive data encrypted/hashed
- โ Rate limiting on public endpoints
Testing
- โ Tests exist for new functionality
- โ Edge cases covered
- โ Error scenarios tested
- โ Actual assertions (not just execution)
- โ No test pollution (proper setup/teardown)
- โ Mocks used appropriately (not overused)
- โ Test names describe behavior
- โ Integration tests for critical paths
Code Quality
- โ Names reveal intent (functions, variables, types)
- โ Functions <50 lines (single responsibility)
- โ Files <500 lines (consider splitting)
- โ No magic numbers (use named constants)
- โ DRY violations eliminated
- โ Nested conditionals <3 deep
- โ Cyclomatic complexity reasonable
- โ Dead code removed
Documentation
- โ Public APIs have JSDoc/TSDoc
- โ Complex algorithms explained
- โ Non-obvious decisions documented
- โ Breaking changes noted
- โ TODOs have context and owner
- โ README updated if behavior changes
- โ Examples provided for complex usage
Performance
- โ No obvious N+1 queries
- โ Appropriate data structures used
- โ Unnecessary allocations avoided
- โ Heavy operations async/batched
- โ Caching where beneficial
- โ Database indexes considered
Rust-Specific (when applicable)
- โ
rustfmt and clippy passing
- โ
Result preferred over panic
- โ No
unwrap/expect outside tests/startup
- โ Ownership/borrowing idiomatic
- โ
Send/Sync bounds respected
- โ Unsafe code justified with comments
- โ Proper error types (
thiserror/anyhow)
1. Announce (activeForm: Announcing review)
Emit starting protocol:
- Scope of review
- Focus areas
- Checklist approach (full or targeted)
2. Checklist (activeForm: Running checklist review)
Systematically verify each category:
- Type Safety โ Error Handling โ Security โ Testing โ Quality โ Docs โ Performance
- Flag violations immediately with severity
- Note clean areas briefly
3. Deep Dive (activeForm: Investigating findings)
For each finding:
- Verify it's actually a problem (not false positive)
- Assess severity and impact
- Determine concrete fix
- Check for pattern across codebase
4. Summarize (activeForm: Compiling review summary)
Emit completion protocol:
- Findings count by severity
- Recommendation (ship / fix blockers / rework)
- Detailed findings list
- Optional: patterns noticed, suggestions for future
Load the maintain-tasks skill for tracking review stages.
<finding_format>
{SEVERITY} {FILE_PATH}:{LINE_RANGE}
Issue: { clear description of problem }
Impact: { consequences if shipped โ security risk, runtime error, maintenance burden, etc }
Fix: { concrete steps to remediate }
Pattern: { if issue appears multiple times, note scope }
Example:
โ src/auth/login.ts:45-52
Issue: Password compared using == instead of constant-time comparison
Impact: Timing attack vulnerability โ attacker can infer password length and content through response timing
Fix: Use crypto.timingSafeEqual() or bcrypt's built-in comparison
Pattern: Single occurrence
</finding_format>
<severity_guidance>
โ Severe (blocking):
- Security vulnerabilities
- Data loss risks
- Runtime crashes in common paths
- Breaking changes without migration
- Test failures or missing critical tests
โ Moderate (should fix):
- Type safety violations
- Unhandled error cases
- Poor error messages
- Missing tests for edge cases
- Significant code quality issues
- Missing documentation for public APIs
โ Minor (consider addressing):
- Code style inconsistencies
- Overly complex but functional code
- Minor performance optimizations
- Documentation improvements
- TODOs without context
- Naming improvements
</severity_guidance>
Loop: Scan โ Verify โ Document โ Next category
- Announce review โ scope, focus, approach
- Run checklist โ systematically verify each category
- Document findings โ severity, location, issue, impact, fix
- Investigate patterns โ does finding repeat? Broader issue?
- Deep dive blockers โ verify severity assessment, ensure fix is clear
- Compile summary โ counts by severity, recommendation
- Deliver findings โ completion protocol with detailed list
At each finding:
- Verify it's actually a problem
- Assess impact if shipped
- Determine concrete fix
- Note if pattern across files
Before completing review:
Check coverage:
- โ All checklist categories verified?
- โ Both happy path and error paths reviewed?
- โ Tests examined for actual assertions?
- โ Security-sensitive areas given extra scrutiny?
Check findings quality:
- โ Severity accurately assessed?
- โ Impact clearly explained?
- โ Fix actionable and concrete?
- โ False positives eliminated?
Check recommendation:
- โ Aligned with findings severity?
- โ Blockers clearly marked?
- โ Path forward unambiguous?
ALWAYS:
- Announce review start with scope and focus
- Run systematic checklist, don't skip categories
- Emit findings as discovered, don't batch at end
- Assess severity honestly (err toward caution)
- Provide concrete fixes, not just complaints
- Complete with summary and recommendation
- Mark false positives if checklist item doesn't apply
- Consider patterns (single issue or systemic?)
NEVER:
- Skip checklist review for "quick check"
- Assume code is safe without verification
- Flag style preferences as blockers
- Provide vague findings without fix guidance
- Approve severe findings "for later fix"
- Complete review without announcement protocol
- Miss security checks on user input paths
- Ignore test quality (execution != validation)
Core methodology:
- checklist.md โ extended checklist details, examples, severity guidance
Related skills:
- codebase-analysis โ evidence-based investigation (foundation for review)
- debugging โ structured bug investigation
