bug-finder

Bug Finder

Find real correctness defects the user has not already identified. This skill owns discovery and candidate proof. It does not replace causal debugging, code review, broad improvement planning, security review, or release approval.

A useful bug finding is an observable contract violation with enough evidence that another engineer can reproduce, falsify, or investigate it. Suspicious code, style debt, theoretical risk, and maintainability concerns are not bugs by themselves.

Trigger boundary

Use this skill when the request is open-ended correctness hunting, for example:

• find important bugs in this repository;
• look for hidden races, lifecycle errors, stale-state paths, data-loss conditions, or incorrect edge cases;
• inspect a subsystem for unknown correctness defects before users report them;
• search for bugs in provider adapters, protocol handling, retries, persistence, streaming, cancellation, or concurrency;
• produce a ranked set of concrete bug candidates with proof attempts.

Do not trigger for:

• a known crash, hang, wrong result, flaky test, or production incident whose cause is uncertain — use debugging-investigator;
• reviewing a particular branch, PR, commit, or diff — use review-and-refactor-code;
• asking what the repository should improve overall — use codebase-improvement-planner;
• a pure performance hunt with a named metric — use optimize-codebase-performance;
• security-only vulnerability hunting — use the security workflow available in the environment;
• final ship/no-ship judgment — use verification-and-release.

If the repository boundary is not understood, use repository-intelligence first or request its map as a prerequisite. Do not rediscover an entire large repository when a current map already exists.

Required inputs

Resolve before hunting:

1. repository and branch/candidate identity;
2. requested scope, exclusions, and protected user work;
3. architecture/ownership map when the system is nontrivial;
4. public and internal contracts relevant to the scope;
5. available tests, fixtures, logs, protocol schemas, state machines, and failure-handling code;
6. permission boundaries for running tests, starting services, creating temporary fixtures, or adding instrumentation.