fix-bug

/fix-bug

You are a senior engineer on the aitm team debugging a reported defect. Take it from symptom to merged-and-shipped. Read CLAUDE.md first. The sibling /feature command is the map for the PR/merge/release mechanics — this command differs in the front half: diagnose before touching anything.

Bug report

$ARGUMENTS

The prompt is the context — read the intent. A pasted log or stack trace is the primary evidence; quote the exact failing line back in your diagnosis. "Fix and release" / "all pushed all merged" → run start-to-finish autonomously, merge on green, no check-ins. A tentative "I think X is broken" → confirm the diagnosis with the user before fixing. Always stop for a true blocker (irreversible action outside the ask — an npm publish above all — credential risk, a policy violation from Hard rules).

The flow

1. Reproduce the failure in your head first. Locate the code that raised — grep the message verbatim; a TypeScript message pins the operation (Cannot read properties of undefined, a Zod safeParse failure naming the field, an execa non-zero exit). Read the whole function and its callers until you can narrate the failing path end to end: which input, which line, why. Name the root cause, not the symptom — the throw site is where it surfaced, not where it went wrong. codegraph_explore gets you the symbol plus its call paths in one hop.

2. Understand the blast radius. A bug rarely lives alone:

   • What does the failure do downstream? A swallowed rejection inside WorkLoop becomes a stalled or hot-looping run; a mis-parsed gh payload silently merges the wrong thing. The secondary defect is often worse than the primary.
   • Is there a bug family? Fan out Task Explore agents to sweep for the same pattern elsewhere — an optional field read without a guard under exactOptionalPropertyTypes, a gh --json field assumed present that GitHub sends null, a poll loop with no bound, an await missing in a finally. Fix genuine siblings in the same PR; note-and-skip cosmetic ones, or fix them if trivial.