Skip to content
Cadence

/c-find-bugs

Source of truth: skills/c-find-bugs/SKILL.md. For the why behind the diagnostics, read the Diagnostics deep dive.

Purpose

Section titled “Purpose”

Hunts for concrete, fixable defects in a doc or in code (each one named with a file-and-line citation, a severity, and a one-line fix direction) so a non-coder can see what’s actually wrong without reading the code.

When to use it

Section titled “When to use it”

Use /c-find-bugs when you want a specific defect list rather than a quality opinion: bugs on a branch before merge, logic errors in a plan, or problems in a single file. It is an off-pipeline, read-only diagnostic. Use /c-check instead when the question is “is this design good?” rather than “what specific defects exist?”

Invocation forms

Section titled “Invocation forms”
  • /c-find-bugs <design-folder>: logical defects in the proposed system.
  • /c-find-bugs <plan-folder>: execution bugs (missing dependency edges, name mismatches, impossible steps).
  • /c-find-bugs <branch-name>: code changes on a branch versus baseline.
  • /c-find-bugs <file-path>: one file’s source.
  • /c-find-bugs --repo: the whole repo (token-heavy; prints estimated scope and waits for explicit confirmation).

With no target, it defaults to the current branch’s diff against main (or the configured baseline); on main itself it asks for an explicit target.

Inputs & preconditions

Section titled “Inputs & preconditions”

An existing target: a design folder, plan folder, branch, file, or the repo. --repo scope requires explicit confirmation before it starts and excludes vendor/generated/build paths.

What it produces

Section titled “What it produces”

A citation-first report in chat: a plain-English health summary, defects grouped Critical / High / Medium / Low with a fix direction each, a mandatory “What’s working” section, and one recommended next action. After printing, it can optionally enter a fix mode to walk defects one at a time. It never fixes bugs on its own without your go-ahead.

Gates & guarantees

Section titled “Gates & guarantees”
  • Fans out one sub-agent per enabled defect category (correctness, logic, resources, concurrency, error handling, security, API misuse, time/date, plus doc-specific categories), then merges and deduplicates.
  • --repo runs only after it prints an estimated token count and you confirm.
  • It never writes or modifies code/plans/designs on its own, never audits plan completion (that’s /c-audit), never reviews for substance (that’s /c-check), and treats every run as fresh (no dedupe against a tracker).
Section titled “Related commands”