triage

Triage

Move issues that arrived raw (bug reports, feature requests, anything you didn't write yourself) through a small state machine, ending in an agent brief an implementer can work from. Tickets that the to-tickets skill produced are agent-ready already; they skip triage.

Every comment triage posts starts with:

> *This was generated by AI during triage.*

Roles

Each triaged issue carries one category and one state:

• Category: bug (something is broken) or enhancement (new or better behaviour).
• State: needs-triage (to evaluate), needs-info (waiting on the reporter), ready-for-agent (fully specified, an agent can take it), ready-for-human (needs a person: judgement calls, external access, manual testing), or wontfix.

These are role names. Map each to the repo's real label (gh label list); if a role has no label, offer to create it and wait for the user's yes before running gh label create. Flag an issue carrying two state labels and ask before changing it.

Normal flow: unlabelled → needs-triage → needs-info, ready-for-agent, ready-for-human, or wontfix; needs-info returns to needs-triage when the reporter replies. The user can override any step.

External PRs. When the user wants contributors' PRs triaged too, a PR is an issue with code attached: the same roles and states, with ready-for-agent meaning "an agent should finish or fix this diff" and ready-for-human meaning "ready for a person to merge". Discover only PRs from authors who aren't owners, members, or collaborators; an explicitly named PR is triaged whoever wrote it.

Show what needs attention

When the user asks what's waiting, list three buckets, oldest first, with a count and a one-line summary per item: unlabelled; needs-triage; and needs-info where the reporter has replied since the last triage note. Let the user pick.

Triage one issue

1. Gather context. Read the body, comments, labels, author, and dates (for a PR, the diff too), and any earlier triage notes so you don't re-ask what was answered. Explore the code in the project's GLOSSARY.md terms. Check two things: whether the requested behaviour already exists (search by concept, not just the issue's wording, and say where you looked), and whether .out-of-scope/ holds a prior rejection of the same idea (OUT-OF-SCOPE.md). Done when you can say whether it is already built and whether it was rejected before.

2. Recommend a category and state, with your reasoning and a short summary of the relevant code. Done when the user has given direction.

3. Verify the claim. For a bug, reproduce it from the reporter's steps; when it resists, call the Skill tool with "diagnosing-bugs". For a PR, check it out and run what it claims to fix. Report: confirmed (with the code path), failed, or not enough detail, which points to needs-info. Done when one of those three is reported.

4. Grill if needed. If the request needs shaping, call the Skill tool twice, for "grilling" and "domain-modeling". Done when the open questions the brief needs are answered.

5. Apply the outcome, after showing the user what you'll post:

   • ready-for-agent: post an agent brief (AGENT-BRIEF.md).
   • ready-for-human: the same structure, plus why it can't be delegated.
   • needs-info: post triage notes (template below).
   • wontfix, already implemented: point to where it lives and close; this is not a rejection, so nothing goes in .out-of-scope/.
   • wontfix, rejected enhancement: record it in .out-of-scope/, link that from the closing comment, and close.
   • wontfix, rejected bug: explain politely and close.

   To close, call the Skill tool with "issue-close". Done when the labels, the comment, and (for wontfix) the closure are all in place.

When the user says "move #42 to ready-for-agent", trust them: confirm what you'll change, apply it, and ask whether they want a brief written.

Needs-info notes

## Triage notes

**What we've established so far:**

- point 1

**What we still need from you (@reporter):**

- a specific, answerable question

Record everything settled so far, so the work isn't lost while waiting.