home / skills / davila7 / claude-code-templates / code-review

This skill analyzes code changes for Sentry-style review, identifying runtime, performance, security, and design issues to improve quality.

This is most likely a fork of the code-review skill from getsentry
npx playbooks add skill davila7/claude-code-templates --skill code-review

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.7 KB
---
name: code-review
description: Perform code reviews following Sentry engineering practices. Use when reviewing pull requests, examining code changes, or providing feedback on code quality. Covers security, performance, testing, and design review.
---

# Sentry Code Review

Follow these guidelines when reviewing code for Sentry projects.

## Review Checklist

### Identifying Problems

Look for these issues in code changes:

- **Runtime errors**: Potential exceptions, null pointer issues, out-of-bounds access
- **Performance**: Unbounded O(n²) operations, N+1 queries, unnecessary allocations
- **Side effects**: Unintended behavioral changes affecting other components
- **Backwards compatibility**: Breaking API changes without migration path
- **ORM queries**: Complex Django ORM with unexpected query performance
- **Security vulnerabilities**: Injection, XSS, access control gaps, secrets exposure

### Design Assessment

- Do component interactions make logical sense?
- Does the change align with existing project architecture?
- Are there conflicts with current requirements or goals?

### Test Coverage

Every PR should have appropriate test coverage:

- Functional tests for business logic
- Integration tests for component interactions
- End-to-end tests for critical user paths

Verify tests cover actual requirements and edge cases. Avoid excessive branching or looping in test code.

### Long-Term Impact

Flag for senior engineer review when changes involve:

- Database schema modifications
- API contract changes
- New framework or library adoption
- Performance-critical code paths
- Security-sensitive functionality

## Feedback Guidelines

### Tone

- Be polite and empathetic
- Provide actionable suggestions, not vague criticism
- Phrase as questions when uncertain: "Have you considered...?"

### Approval

- Approve when only minor issues remain
- Don't block PRs for stylistic preferences
- Remember: the goal is risk reduction, not perfect code

## Common Patterns to Flag

### Python/Django

```python
# Bad: N+1 query
for user in users:
    print(user.profile.name)  # Separate query per user

# Good: Prefetch related
users = User.objects.prefetch_related('profile')
```

### TypeScript/React

```typescript
// Bad: Missing dependency in useEffect
useEffect(() => {
  fetchData(userId);
}, []);  // userId not in deps

// Good: Include all dependencies
useEffect(() => {
  fetchData(userId);
}, [userId]);
```

### Security

```python
# Bad: SQL injection risk
cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")

# Good: Parameterized query
cursor.execute("SELECT * FROM users WHERE id = %s", [user_id])
```

## References

- [Sentry Code Review Guidelines](https://develop.sentry.dev/engineering-practices/code-review/)

Overview

This skill performs code reviews following Sentry engineering practices, tuned for Python and Django projects but applicable to multi-language stacks. It helps reviewers spot runtime errors, performance regressions, security risks, and design or testing gaps. Use it to produce focused, actionable feedback that reduces risk while respecting developer time.

How this skill works

The skill inspects diffs and pull requests and highlights issues across security, performance, testing, and design. It checks for runtime error patterns, expensive query or loop patterns (N+1, O(n²)), API or schema changes, missing tests, and security anti-patterns. Feedback is written with polite, actionable suggestions and escalation guidance for risky changes.

When to use it

  • Reviewing pull requests that modify backend or frontend code
  • Evaluating database or API contract changes
  • Checking PRs that introduce new dependencies or frameworks
  • Validating test coverage for feature or bugfix work
  • Assessing security-sensitive or performance-critical code paths

Best practices

  • Prioritize runtime safety: flag potential exceptions, null reference, and bounds issues
  • Call out performance pitfalls: look for N+1 queries, unnecessary allocations, and O(n²) loops
  • Verify tests: require functional, integration, or end-to-end tests as appropriate and ensure edge cases are covered
  • Assess design fit: ensure changes align with project architecture and don’t introduce surprising side effects
  • Use a respectful tone: ask clarifying questions and offer concrete remediation steps rather than vague criticism

Example use cases

  • Spotting and fixing an N+1 Django ORM query and suggesting prefetch_related or select_related
  • Identifying missing dependency array entries in React useEffect and suggesting correct dependency lists
  • Flagging direct SQL string interpolation and recommending parameterized queries to prevent injection
  • Reviewing a schema migration and escalating to a senior engineer when it affects backward compatibility
  • Checking a feature PR to ensure it includes integration tests covering critical user flows

FAQ

When should I escalate a change to a senior engineer?

Escalate for database schema changes, API contract changes, new framework adoption, performance-critical paths, or any security-sensitive functionality.

Should I block PRs for stylistic issues?

No. Avoid blocking for style-only concerns; prefer automated linters and focus reviews on correctness, safety, and architecture.