playbooks

home / skills / steveclarke / dotfiles / find-bugs

find-bugs skill

/ai/skills/find-bugs

This skill helps you identify bugs, security flaws, and quality issues in current branch changes, guiding thorough code reviews.

This is most likely a fork of the find-bugs skill from getsentry
npx playbooks add skill steveclarke/dotfiles --skill find-bugs

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.7 KB
---
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 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.

Overview

This skill inspects local branch changes to find bugs, security vulnerabilities, and code-quality issues across the diff. It follows a structured multi-phase audit: gather full input, map the attack surface, run a comprehensive security checklist, verify findings, and produce a prioritized report. The output focuses on real, actionable issues with concrete fixes and evidence.

How this skill works

It starts by collecting the complete diff (git diff master...HEAD) and reading each changed file completely. For every changed file it enumerates user inputs, DB queries, auth checks, session/state ops, external calls, and crypto usage, then runs a checklist covering injection, XSS, CSRF, race conditions, crypto misuse, info disclosure, DoS, and business logic. Each potential issue is cross-checked against surrounding code and tests before being reported with severity, evidence, and a concrete fix suggestion.

When to use it

  • Before merging a feature or hotfix to ensure no regressions or vulnerabilities are introduced
  • When asked to perform a security review or audit of the current branch
  • After making changes to auth, session, or database-access code
  • When adding new external integrations, command execution, or crypto operations
  • Before a release to catch high-impact bugs early

Best practices

  • Always gather the full diff and read every changed file line-by-line to avoid truncated output
  • Map inputs-to-sinks for each file so every potential attack surface is covered
  • Treat missing tests or unclear context as verification gaps and document them
  • Prioritize findings by security impact first, then correctness, then maintainability
  • Provide concrete fixes and relevant standards (OWASP, RFCs) for remediation guidance

Example use cases

  • Review a branch that changes authentication or authorization logic for IDOR/privilege escalation
  • Audit changes that introduce shell commands or subprocess calls for command injection
  • Scan a branch that modifies templates or frontend output for XSS and escaping errors
  • Inspect code that adds new DB queries for SQL injection, race conditions, or missing transactions
  • Validate changes that introduce new crypto usage or key handling for proper algorithms and randomness

FAQ

Do you modify code during the audit?

No. The skill only inspects changes and reports issues with suggested fixes; code changes are left to the developer.

What if the diff output is truncated?

I will read each changed file individually until I have seen every changed line and will list all files reviewed.