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...

Security Scan

The skill's instructions are coherent with a local code-review tool, but the SKILL.md requires the 'git' command and makes brittle assumptions (e.g., branch named 'master', reading full diffs) while the metadata declares no required binaries — this mismatch and a few scope assumptions are concerning and should be fixed before use.

Purpose & Capability

The skill's stated purpose (review local branch changes) matches the SKILL.md instructions, which require running git commands and reading repository files. However, the registry metadata lists no required binaries while the instructions explicitly call 'git diff' and rely on git being available. That mismatch is incoherent: a code-review skill legitimately needs git or an equivalent VCS tool declared.

Instruction Scope

SKILL.md gives a detailed, concrete review procedure (get full diff, read every changed file, map attack surface, run a checklist, verify, and report). It does not instruct contacting external endpoints or accessing unrelated system files. Two points to note: (1) it assumes the base branch is named 'master' (many repos use 'main' or other names), and (2) it explicitly tells the agent to read every changed file — which is expected for a repo review but could surface secrets or sensitive data if present in the repo. The instructions are otherwise appropriately scoped to code-review tasks.

Install Mechanism

There is no install spec and no code files; this is instruction-only, which is low risk for install-time arbitrary code. Nothing is written to disk by the skill itself.

Credentials

The skill declares no environment variables, no credentials, and no config paths. The SKILL.md also does not request secrets or external credentials. This is proportionate for a local code-review helper.

Persistence & Privilege

The skill is not force-enabled (always: false) and does not request persistent/high-privilege settings. Autonomous invocation is allowed (platform default) but that alone is not flagged. The skill does not request to modify other skills or system-wide settings.

What to consider before installing

This skill looks like a reasonable local code-review checklist, but fix the metadata mismatch before trusting it: declare 'git' as a required binary (or update instructions to handle missing git). Be aware the instructions will read every changed file in the branch — repositories often contain sensitive data (API keys, private certs, large logs). Only run this skill on repositories you trust and avoid running it in environments where reading the repo could expose secrets to the agent's outputs. Also consider updating the SKILL.md to (1) handle repos where the default branch is 'main' or another name, (2) allow the user to confirm the base branch or provide it explicitly, and (3) clarify how to handle very large diffs (paging, limits) to avoid inadvertent data exfiltration. If you want higher assurance, request the author to add explicit required-binaries metadata and a short note describing that the skill reads local files only and does not transmit data externally.

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.