Code review
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.From its SKILL.md
npx -y skills add BTN101/claude-skill-pack --skill code-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.7 KB, 523 tokens by cl100k_base, as published. Nobody here has run it
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
# 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
// Bad: Missing dependency in useEffect
useEffect(() => {
fetchData(userId);
}, []); // userId not in deps
// Good: Include all dependencies
useEffect(() => {
fetchData(userId);
}, [userId]);
Security
# 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
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most code review skills give in 523 tokens
Counted across 668 of the 814 authors here whose files we hold, read 2026-09-06
- Provide technical reasoning when pushing backin 84 of 668, across 70 files
- Fix critical issues immediatelyin 77 of 668, across 60 files
- Dispatch a code reviewer subagentin 76 of 668, across 59 files
- Fix important issues before proceedingin 73 of 668, across 56 files
- Ask for clarification on unclear itemsin 68 of 668, across 56 files
- Verify feedback against codebase before implementationin 66 of 668, across 55 files
- Implement fixes one at a timein 64 of 668, across 53 files
- Test each fix individuallyin 62 of 668, across 51 files
- Restate technical requirements in own wordsin 57 of 668, across 46 files
- Reply to inline comments in the specific threadin 51 of 668, across 40 files
- Note minor issues for laterin 49 of 668, across 34 files
- Group findings by severityin 48 of 668, across 47 files
Said here and by no other author read
- Flag database schema changes for senior review
- Flag security sensitive code for senior review
- Provide actionable suggestions instead of vague criticism
- Phrase uncertain feedback as questions
- Approve pull requests when only minor issues remain
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.