find-bugs

steveclarke's avatarfrom steveclarke

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.

⭐22stars🔀0forks📁View on GitHub🕐Updated Jan 10, 2026
[Code Review]

When & Why to Use This Skill

The find-bugs Claude skill is a comprehensive automated code auditing tool designed to identify security vulnerabilities, logic bugs, and quality issues in local Git branches. By following a rigorous five-phase methodology—including attack surface mapping and a detailed security checklist—it helps developers catch critical risks like SQL injection, XSS, and race conditions before code is merged into the master branch.

Use Cases

  • Pre-merge Security Auditing: Automatically scan local branch changes for OWASP Top 10 vulnerabilities such as injection, broken authentication, and sensitive data exposure before opening a Pull Request.
  • Logic Bug Identification: Detect complex business logic errors, race conditions (TOCTOU), and edge case violations in new feature development to improve software reliability.
  • Attack Surface Mapping: Systematically identify all new user inputs, database queries, and cryptographic operations in a diff to evaluate the security impact of recent changes.
  • Code Quality Assurance: Review code for technical debt and quality issues, prioritizing high-severity security risks and functional bugs over stylistic formatting.
  • Automated Security Checklist: Execute a standardized security review process that ensures every modified file is checked for CSRF, IDOR, and information disclosure vulnerabilities.
namefind-bugs
descriptionFind 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 master...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.