Code Review Preferences

---
name: code-review-preferences
description: Use when reviewing code, PRs, or discussing code quality standards. Applies team coding standards and review methodology.
---

<essential_principles>
## Code Review Philosophy

Reviews exist to:
1. **Catch bugs** before production
2. **Share knowledge** across the team
3. **Maintain consistency** in the codebase

Reviews do NOT exist to:
- Show off knowledge
- Enforce personal style preferences
- Block progress unnecessarily

## The 3-Pass Method

### Pass 1: Understand (don't comment yet)
- What is this change trying to do?
- What files are affected?
- What's the scope?

### Pass 2: Correctness
- Are there bugs?
- Are edge cases handled?
- Are there security issues?

### Pass 3: Improvements (max 5 comments)
- Is it readable?
- Is it maintainable?
- Are there better patterns?

## Review Checklist

### Must Check
- [ ] Tests pass
- [ ] No obvious bugs
- [ ] Edge cases handled
- [ ] No security vulnerabilities
- [ ] No secrets in code

### Should Check
- [ ] Code is readable
- [ ] Functions < 50 lines
- [ ] Clear naming
- [ ] Helpful error messages

### Nice to Check
- [ ] Performance considerations
- [ ] Documentation updated
- [ ] Consistent patterns

## Feedback Style

**DO:**
- Ask questions: "What happens if X is null?"
- Be specific: "Line 42: Consider guard clause"
- Acknowledge good work: "Nice refactor"
- Limit comments: Max 5 per review

**DON'T:**
- Dictate: "You must do X"
- Be vague: "This could be better"
- Nitpick style: "I prefer single quotes"
</essential_principles>

<intake>
What would you like me to review?

1. **Paste code/diff** - I'll review inline
2. **Reference file** - Use @filename
3. **Describe PR** - I'll ask questions

**Context:**
- Bug fix / New feature / Refactor / Performance

**Specific concerns?** (Security, breaking changes, etc.)
</intake>