reviewclaude-codecodexcursorEvidence not reviewed
Find bugs: bugs, vulns and quality issues in branch changes
Find bugs, security vulnerabilities, and code quality issues in local branch changes.
Upstream publishes this file as a Claude skill (SKILL.md). Cursor reads the same SKILL.md shape. This page does not claim either product ships the file.
What the research says
Evidence not reviewedNobody has reviewed the evidence for this skill yet.
Let your agent do it
Copy a prompt for Claude Code, Codex, or Cursor.
Paste it into your coding agent in this repo. It does the setup and asks before anything leaves your machine.
Runs the same job in your agent session, on the plan you are signed in with. No API key, no Action.
Install the "Find bugs: bugs, vulns and quality issues in branch changes" agent skill from AgentFlows (https://agentflows.sh/skills/getsentry-find-bugs) and use it with the plan I'm signed in with. No API key needed. Install these agent skills first. Download each SKILL.md from its source (respect its license) into .claude/skills/<name>/SKILL.md, or wherever this agent loads skills from: - Find bugs: bugs, vulns and quality issues in branch changes: https://github.com/getsentry/skills/tree/main/skills/find-bugs (Apache-2.0), notes at https://agentflows.sh/skills/getsentry-find-bugs Then confirm the skill loaded, tell me in two lines when it kicks in, and offer to run it now on this repo.
The file
SKILL.md
Copy the upstream file, including its own frontmatter, into .claude/skills/getsentry-find-bugs/SKILL.md.
.claude/skills/getsentry-find-bugs/SKILL.md
--- 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.