issue-triage
Issue triage
File a short, good-looking GitHub issue that someone else can pick up without asking follow-up questions. Four parts, plain prose, no ceremony.
Needs: gh, authenticated, in a repo with a GitHub remote. If gh auth status fails, stop and say to run gh auth login.
Never file an issue you weren't asked to file
Issues are public and hard to undo. Only act on an explicit ask. Before gh issue create, show the target repo from gh repo view --json nameWithOwner,visibility (say PUBLIC plainly if it is) plus the exact title and body, and wait for a yes.
1. Gather context with sub-agents
Don't read the codebase yourself, it burns context you need for writing. Spawn one or two Explore agents and ask them for a compact answer: which files and functions the problem lives in, what the code currently does, file:line for anything worth pointing at. Tell them to return a short summary, not file dumps.
One agent for "where does X live and what does it do" is usually enough. Add a second only when the issue spans two unrelated areas. Skip sub-agents entirely when the user already handed you the file and the error.
If something stays unknown after that, leave it out. Never invent a line number, an error string, or repro steps to sound concrete.