Understand Issue

Collaboratively investigate a GitHub issue or reported bug — trace the history of related code, understand the architecture involved, and work with the user to diagnose whether the issue is valid and what's actually causing it. Both you and the user should walk away with genuine understanding, not just a guess.

Do not produce walls of text. Responses should be short, dense, and information-dense. Minimize fluff. Be direct.

Pacing: Phases 1–3 are research — do them all proactively without stopping for user input. The first pause is Phase 4 (Diagnosis), where you present your findings and opinion for collaborative validation. Don't pause before that.

Shell note: gh output often contains ANSI color codes that break jq. Use gh's built-in --jq flag instead of piping to jq, or prefix commands with NO_COLOR=1.

Phase 1: Identify the Issue

Figure out what we're investigating.

1. Parse the issue input and optional --working-file <path> from $ARGUMENTS.
2. If --working-file is present, verify the file exists and read it first. Treat it as caller-provided context, follow its handoff instructions, and update that same file with findings before returning to the caller. Do not treat the working file as the final user-facing output. If the file does not exist, tell the user and end.
3. Never post comments without explicit approval.

The user may provide: