code-review-preferences

<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 Standards

Must Check

• • Tests pass
• • No obvious bugs
• • Edge cases from PR description handled
• • No security vulnerabilities
• • No secrets in code

Should Check

• • Code is readable
• • Functions are reasonably sized (<50 lines)
• • Names are clear and descriptive
• • Error messages are helpful

Nice to Check

• • Performance considerations
• • Documentation updated
• • Consistent with existing patterns

Feedback Style

DO:

• •Ask questions: "What happens if X is null?"
• •Be specific: "Line 42: Consider using a guard clause"
• •Acknowledge good work: "Nice refactor here"
• •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"
• •Pile on: 20 comments is overwhelming </essential_principles>

1. •

   Format

   • •Paste the code/diff here
   • •Reference a file with @filename
   • •Describe the PR and I'll ask questions
2. •

   Context

   • •Bug fix
   • •New feature
   • •Refactor
   • •Performance optimization
   • •Other: ___
3. •

   Specific concerns? (Security, performance, breaking changes, etc.)

I'll wait for your answers before starting the review. </intake>