| name | code-review-standards |
| description | Code review framework and criteria. References security-sentinel for security checks. Use when performing code reviews or defining review standards. |
| allowed-tools | Read, Grep |
Code Review Standards
When to Use
- Reviewing pull requests
- Performing code reviews
- Defining review criteria
- Establishing review process
Overview
Code review standards ensure consistent, thorough reviews that catch bugs before they reach production. This skill aggregates criteria from specialized skills.
Review Framework
4-Level Severity Classification
CRITICAL 🔴 - Must fix before merge
- Security vulnerabilities
- Data loss risks
- Authentication bypasses
- SQL injection risks
HIGH 🟠- Should fix before merge
- TypeScript strict mode violations
- Missing error handling
- Performance issues (N+1 queries)
- Missing input validation
MEDIUM 🟡 - Fix soon (can merge with plan)
- Code quality issues
- Missing tests
- Poor naming
- Missing documentation
LOW 🟢 - Nice to have
- Style suggestions
- Optimization opportunities
- Refactoring ideas
Review Checklist
1. Correctness
→ See: correctness-criteria.md
- Logic is correct for all test cases
- Edge cases handled (null, empty, max, min)
- Error conditions properly handled
- Return types match function signatures
- Async operations properly awaited
- No race conditions
- No off-by-one errors
2. Security
→ See: security-sentinel skill → See: security-checklist.md
CRITICAL - Must check every review:
- No hardcoded secrets
- Input validation with Zod (ALL inputs)
- Authentication checked on protected routes
- Authorization enforced (resource ownership)
- SQL injection prevented (using Drizzle)
- XSS prevented (no dangerouslySetInnerHTML without sanitization)
- CSRF protection on state-changing operations
- No sensitive data in logs
- Passwords hashed (bcrypt, 12+ rounds)
- JWTs properly verified
For complete security criteria: → security-sentinel/SKILL.md
3. TypeScript Quality
→ See: typescript-strict-guard skill
- No
anytypes - No
@ts-ignorewithout extensive comment - No
!non-null assertions without comment - Explicit types on all function parameters
- Explicit return types on all functions
- Type guards used for unknown types
- Proper use of generics
- No implicit any
4. Testing
→ See: quality-gates/test-patterns.md
- Tests exist for new code
- Tests follow AAA pattern
- Coverage meets thresholds (75%/90%)
- UI tests verify DOM state (not just mocks)
- E2E tests for visual changes
- No skipped tests without reason
- Tests are independent
- Tests clean up after themselves
5. Performance
→ See: performance-criteria.md
- No N+1 query problems
- Database queries optimized
- Async operations parallelized where possible
- Large datasets paginated
- Images optimized
- No unnecessary re-renders
- Expensive calculations memoized
6. Code Quality
→ See: maintainability-rules.md
- No console.log in production code
- No commented-out code
- No TODO without GitHub issue
- Functions have single responsibility
- Variable names are descriptive
- No dead code
- No duplicated logic
- Proper error messages
7. Architecture Compliance
→ See: architecture-patterns skill
- Correct pattern chosen for problem
- Pattern implemented correctly
- No pattern violations
- Follows Next.js best practices
- Server vs Client Components correct
- State management appropriate
Review Process
Step 1: Pre-Review (2 minutes)
- Read PR description
- Understand what changed and why
- Check CI/CD status (tests, build, coverage)
- Identify high-risk areas (auth, payments, data handling)
Step 2: Security Review (5 minutes)
For ALL PRs:
- Check for hardcoded secrets
- Verify input validation
- Check authentication/authorization
For Auth/API/Data PRs:
- Run security-sentinel skill
- Review OWASP Top 10 criteria
- Check for injection risks
Step 3: Code Review (10-20 minutes)
- Correctness: Does it work as intended?
- TypeScript: Strict mode compliance?
- Testing: Adequate coverage and quality?
- Performance: Any obvious issues?
- Quality: Readable, maintainable code?
- Architecture: Follows established patterns?
Step 4: Write Feedback (5 minutes)
Use severity levels and templates: → review-templates.md
Format:
## 🔴 CRITICAL Issues
- [ ] [Security] Hardcoded API key in auth.ts:45
- **Risk**: API key exposed in version control
- **Fix**: Move to environment variable
- **File**: src/lib/auth.ts:45
## 🟠HIGH Issues
- [ ] [TypeScript] Using `any` type in processData()
- **Issue**: No type safety
- **Fix**: Define explicit interface
- **File**: src/utils/process.ts:12
## 🟡 MEDIUM Issues
- [ ] [Testing] Missing tests for error cases
- **Coverage**: Only happy path tested
- **Needed**: Test null input, invalid format
- **File**: tests/unit/process.test.ts
## 🟢 LOW Issues / Suggestions
- Consider extracting helper function for readability
Step 5: Verdict
Choose one:
- ✅ APPROVE - No critical/high issues
- 🔄 REQUEST CHANGES - Critical or multiple high issues
- 💬 COMMENT - Questions or low/medium issues only
Review Templates
Security Issue Template
🔴 **[Security] [Vulnerability Type]**
**Location**: `src/path/file.ts:123`
**Issue**: [Description of vulnerability]
**Risk**: [What could go wrong]
**Fix**:
```typescript
// Suggested fix
Reference: [OWASP link or skill reference]
### TypeScript Issue Template
```markdown
🟠**[TypeScript] [Issue Type]**
**Location**: `src/path/file.ts:45`
**Issue**: [What's wrong]
**Fix**:
```typescript
// Current (bad)
function process(data: any) { }
// Suggested (good)
function process(data: ProcessData): ProcessedResult { }
Reference: typescript-strict-guard skill
### Performance Issue Template
```markdown
🟡 **[Performance] [Issue Type]**
**Location**: `src/path/file.ts:78`
**Issue**: N+1 query problem in getUserProjects()
**Impact**: Linear time complexity, slow for large datasets
**Fix**:
```typescript
// Use join instead of separate queries
const projects = await db
.select()
.from(projectsTable)
.leftJoin(usersTable, eq(projectsTable.userId, usersTable.id))
---
## Common Review Patterns
### Code Smells
**Long Functions**
```typescript
// 🔴 BAD: 100+ line function
function processEverything() {
// ... 100 lines
}
// ✅ GOOD: Extracted helpers
function processEverything() {
const validated = validateInput()
const processed = processData(validated)
const saved = saveToDatabase(processed)
return saved
}
Deeply Nested Logic
// 🔴 BAD: 4+ levels of nesting
if (user) {
if (user.projects) {
if (user.projects.length > 0) {
if (user.projects[0].status === 'active') {
// ...
}
}
}
}
// ✅ GOOD: Early returns
if (!user) return
if (!user.projects || user.projects.length === 0) return
if (user.projects[0].status !== 'active') return
// ...
Magic Numbers
// 🔴 BAD: Unexplained numbers
setTimeout(callback, 3600000)
// ✅ GOOD: Named constants
const ONE_HOUR_MS = 60 * 60 * 1000
setTimeout(callback, ONE_HOUR_MS)
Progressive Disclosure
- SKILL.md (this file) - Review framework overview
- security-checklist.md - OWASP Top 10 checklist
- performance-criteria.md - Performance review criteria
- maintainability-rules.md - Code quality rules
- review-templates.md - Feedback templates
Integration with Other Skills
Code review aggregates criteria from:
- security-sentinel - Security vulnerability checks
- typescript-strict-guard - Type safety validation
- quality-gates - Quality checkpoint framework
- architecture-patterns - Pattern compliance
- nextjs-15-specialist - Next.js best practices
Example Review
# Code Review: Add User Authentication
## Summary
Adds JWT-based authentication with login/logout endpoints.
## 🔴 CRITICAL Issues
### 1. Hardcoded JWT Secret
**File**: `src/lib/auth.ts:12`
**Issue**: JWT secret is hardcoded as "secret123"
**Risk**: Anyone can forge JWTs
**Fix**:
```typescript
- const secret = "secret123"
+ const secret = process.env.JWT_SECRET
+ if (!secret) throw new Error('JWT_SECRET not set')
🟠HIGH Issues
2. Missing Input Validation
File: src/app/api/auth/login/route.ts:15
Issue: User input not validated before use
Fix: Add Zod schema validation
const loginSchema = z.object({
email: z.string().email(),
password: z.string().min(8),
})
const validated = loginSchema.parse(body)
🟡 MEDIUM Issues
3. Missing Tests
File: tests/integration/auth.test.ts
Issue: No tests for error cases
Needed:
- Test invalid email format
- Test wrong password
- Test expired JWT
Verdict
🔄 REQUEST CHANGES - Fix critical and high issues before merge.
Once fixed, this will be a solid authentication implementation.
---
## See Also
- security-checklist.md - OWASP Top 10 checklist
- performance-criteria.md - Performance review guide
- maintainability-rules.md - Code quality rules
- review-templates.md - Feedback templates
- ../security-sentinel/SKILL.md - Security patterns
- ../quality-gates/SKILL.md - Quality framework