# Find Bugs

> Find important, high-confidence correctness bugs and edge cases in an existing codebase. Use when the user asks to inspect a repository, subsystem, or implementation for bugs, failure modes, incorrect behavior, or overlooked edge cases.

- Skill: `minghinmatthewlam/find-bugs` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add minghinmatthewlam/find-bugs`
- Raw SKILL.md: https://api.skillmd.com/api/skills/minghinmatthewlam/find-bugs/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: minghinmatthewlam (https://skillmd.com/u/minghinmatthewlam)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/minghinmatthewlam/find-bugs

---


# Find Bugs

Understand the real behavior before judging it. Trace relevant entrypoints,
callers, tests, state transitions, invariants, and failure paths.

## Investigate

- Prioritize high-confidence, high-impact findings. When impact and confidence
  are similar, favor lower-complexity fixes, but do not hide a severe bug
  because its fix is complex.
- Explore adaptively. Use subagents when they materially improve coverage, keep
  their scopes distinct, and consolidate their findings centrally.
- Verify consequential findings with a focused reproduction, test, or runtime
  probe when practical.
- Remain read-only unless the user asks for fixes.

## Report Findings

For each material finding:

- put priority, expected fix complexity, finding confidence percentage, and fix
  confidence percentage in the heading so they are immediately scannable, for
  example
  `P1 — [Medium fix, 98% finding confidence, 90% fix confidence] Cache entries are not isolated`;
- state the proposed fix direction that the fix estimates refer to;
- state the expected impact of the fix and explain material risk, blast radius,
  trade-offs, or unknowns behind the fix confidence.

Include enough of the following to substantiate it:

- affected files and symbols;
- trigger or edge case;
- expected versus actual behavior;
- user or system impact;
- concrete code, test, or runtime evidence;

Keep simple findings compact; omit fields that do not add clarity.

Only call something a bug when the execution path and expected contract support
that conclusion. Separate verified bugs from plausible investigation leads. Do
not report style preferences, intentional trade-offs, or unrealistic edge cases
as correctness bugs.