issue-triage

Issue Triage

Move each issue through a small state machine. Every triaged issue carries exactly one category role and one state role:

• Category: bug (something is broken) · enhancement (new feature or improvement)
• State: needs-triage (awaiting evaluation) · needs-info (waiting on the reporter) · ready-for-agent (fully specified, an AFK agent can take it) · ready-for-human (needs human implementation) · wontfix (won't be actioned)

These are canonical role names; the actual label strings for a repo may differ — docs/agents/triage-labels.md holds the mapping when present. Run autonomously: there is no maintainer to ask mid-run. Where you'd want direction, either make the call and apply the label, or post a comment and stop — the async comment is the conversation.

Your job is to classify the issue and pin down the problem statement — clarify what's actually being asked, and ask for missing information when it's under-specified. You do not design or plan the implementation: you have only read-only context and no deep exploration, so solution design is left to the downstream build agent, which has full source access.

0. Ensure the labels exist

Before applying any label, create the canonical set in a single idempotent github_ensure_labels call — pass every row below as one labels array ({name, color}). It lists once and creates only the missing ones, so it never errors on labels that already exist:

If the call is denied (the token lacks the permission), fall back to using only the labels that already exist on the repo and skip the rest. Done when the labels you need are present or you've confirmed you can't create them.