/find-bugs
Find bugs, security vulnerabilities, and code quality issues in local branch changes. Use when asked to review changes, find bugs, security review, or audit code on the current branch.
$ npx -y skills add getsentry/sentry-skills --skill find-bugs --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/find-bugs
Context preview
The summary Claude sees to decide when to auto-load this skill.
Find bugs, security vulnerabilities, and code quality issues in local branch changes. Use when asked to review changes, find bugs, security review, or audit code on the current branch.
SKILL.md
find-bugs.SKILL.mdname: find-bugs
description: Find bugs, security vulnerabilities, and code quality issues in local branch changes. Use when asked to review changes, find bugs, security review, or audit code on the current branch.
Find Bugs
Review changes on this branch for bugs, security vulnerabilities, and code quality issues.
Phase 1: Complete Input Gathering
1. Get the FULL diff: `git diff $(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name')...HEAD` 2. If output is truncated, read each changed file individually until you have seen every changed line 3. List all files modified in this branch before proceeding
Phase 2: Attack Surface Mapping
For each changed file, identify and list:
- All user inputs (request params, headers, body, URL components)
- All database queries
- All authentication/authorization checks
- All session/state operations
- All external calls
- All cryptographic operations
Phase 3: Security Checklist (check EVERY item for EVERY file)
- [ ] **Injection**: SQL, command, template, header injection
- [ ] **XSS**: All outputs in templates properly escaped?
- [ ] **Authentication**: Auth checks on all protected operations?
- [ ] **Authorization/IDOR**: Access control verified, not just auth?
- [ ] **CSRF**: State-changing operations protected?
- [ ] **Race conditions**: TOCTOU in any read-then-write patterns?
- [ ] **Session**: Fixation, expiration, secure flags?
- [ ] **Cryptography**: Secure random, proper algorithms, no secrets in logs?
- [ ] **Information disclosure**: Error messages, logs, timing attacks?
- [ ] **DoS**: Unbounded operations, missing rate limits, resource exhaustion?
- [ ] **Business logic**: Edge cases, state machine violations, numeric overflow?
Phase 4: Verification
For each potential issue:
- Check if it's already handled elsewhere in the changed code
- Search for existing tests covering the scenario
- Read surrounding context to verify the issue is real
Phase 5: Pre-Conclusion Audit
Before finalizing, you MUST:
1. List every file you reviewed and confirm you read it completely 2. List every checklist item and note whether you found issues or confirmed it's clean 3. List any areas you could NOT fully verify and why 4. Only then provide your final findings
Output Format
**Prioritize**: security vulnerabilities > bugs > code quality
**Skip**: stylistic/formatting issues
For each issue:
- **File:Line** - Brief description
- **Severity**: Critical/High/Medium/Low
- **Problem**: What's wrong
- **Evidence**: Why this is real (not already fixed, no existing test, etc.)
- **Fix**: Concrete suggestion
- **References**: OWASP, RFCs, or other standards if applicable
If you find nothing significant, say so - don't invent issues.
Do not make changes - just report findings. I'll decide what to address.
Read more
name: find-bugs description: Find bugs, security vulnerabilities, and code quality issues in local branch changes. Use when asked to review changes, find bugs, security review, or audit code on the current branch.
Find Bugs
Review changes on this branch for bugs, security vulnerabilities, and code quality issues.
Phase 1: Complete Input Gathering
1. Get the FULL diff: `git diff $(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name')...HEAD` 2. If output is truncated, read each changed file individually until you have seen every changed line 3. List all files modified in this branch before proceeding
Phase 2: Attack Surface Mapping
For each changed file, identify and list:
- All user inputs (request params, headers, body, URL components)
- All database queries
- All authentication/authorization checks
- All session/state operations
- All external calls
- All cryptographic operations
Phase 3: Security Checklist (check EVERY item for EVERY file)
- [ ] **Injection**: SQL, command, template, header injection
- [ ] **XSS**: All outputs in templates properly escaped?
- [ ] **Authentication**: Auth checks on all protected operations?
- [ ] **Authorization/IDOR**: Access control verified, not just auth?
- [ ] **CSRF**: State-changing operations protected?
- [ ] **Race conditions**: TOCTOU in any read-then-write patterns?
- [ ] **Session**: Fixation, expiration, secure flags?
- [ ] **Cryptography**: Secure random, proper algorithms, no secrets in logs?
- [ ] **Information disclosure**: Error messages, logs, timing attacks?
- [ ] **DoS**: Unbounded operations, missing rate limits, resource exhaustion?
- [ ] **Business logic**: Edge cases, state machine violations, numeric overflow?
Phase 4: Verification
For each potential issue:
- Check if it's already handled elsewhere in the changed code
- Search for existing tests covering the scenario
- Read surrounding context to verify the issue is real
Phase 5: Pre-Conclusion Audit
Before finalizing, you MUST:
1. List every file you reviewed and confirm you read it completely 2. List every checklist item and note whether you found issues or confirmed it's clean 3. List any areas you could NOT fully verify and why 4. Only then provide your final findings
Output Format
**Prioritize**: security vulnerabilities > bugs > code quality
**Skip**: stylistic/formatting issues
For each issue:
- **File:Line** - Brief description
- **Severity**: Critical/High/Medium/Low
- **Problem**: What's wrong
- **Evidence**: Why this is real (not already fixed, no existing test, etc.)
- **Fix**: Concrete suggestion
- **References**: OWASP, RFCs, or other standards if applicable
If you find nothing significant, say so - don't invent issues.
Do not make changes - just report findings. I'll decide what to address.
For skills to help set up Sentry in your project or debug production issues, see Agent skills for Sentry employees, following the Agent Skills open format.
Repo: getsentry/sentry-skills
Other skills on sentry-skills.
- /agents-md
Creates and maintains concise AGENTS.md and CLAUDE.md project instruction files. Use when asked to create AGENTS.md, update AGENTS.md, maintain agent docs, set up CLAUDE.md, document repository agent conventions, or keep coding-agent instructions minimal and reference-backed.
Open skill - /blog-writing-guide
Write, review, and improve blog posts for the Sentry engineering blog following Sentry's specific writing standards, voice, and quality bar. Use this skill whenever someone asks to write a blog post, draft a technical article, review blog content, improve a draft, write a
Open skill - /brand-guidelines
Write copy following Sentry brand guidelines. Use when writing UI text, error messages, empty states, onboarding flows, 404 pages, documentation, marketing copy, or any user-facing content. Covers both Plain Speech (default) and Sentry Voice tones.
Open skill - /claude-settings-audit
Analyze a repository to generate recommended Claude Code settings.json permissions. Use when setting up a new project, auditing existing settings, or determining which read-only bash commands to allow. Detects tech stack, build tools, and monorepo structure.
Open skill - /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.
Open skill - /code-simplifier
Simplifies and refines code for clarity, consistency, and maintainability while preserving all functionality. Use when asked to "simplify code", "clean up code", "refactor for clarity", "improve readability", or review recently modified code for elegance. Focuses on
Open skill

