
Code Review
- 157 installs
- 898 repo stars
- Updated August 3, 2026
- getsentry/sentry-skills
This is a copy of code-review by getsentry - installs and ranking accrue to the original listing.
Run a structured Sentry-style code review on a diff or PR, surfacing reliability, observability, security, and maintainability issues before merge.
About
Encodes Sentry’s code review expectations for agents reviewing pull requests: inspect diffs for failure modes, missing instrumentation, unsafe patterns, and test gaps, then return prioritized comments teams can apply before merging to production branches.
- Diff-focused review checklist
- Observability and error-handling gaps
- Security and data-handling red flags
- Test coverage and regression risk notes
- Actionable, severity-ranked feedback
Code Review by the numbers
- 157 all-time installs (skills.sh)
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/getsentry/sentry-skills --skill code-reviewAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 157 |
|---|---|
| repo stars | ★ 898 |
| Last updated | August 3, 2026 |
| Repository | getsentry/sentry-skills ↗ |
What it does
Run a structured Sentry-style code review on a diff or PR, surfacing reliability, observability, security, and maintainability issues before merge.
Files
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])