Triage

Assess issues on the project issue tracker and recommend what should happen next.

If this repo treats external pull requests as a request surface (see the issue-tracker config), triage covers them too: a PR is an issue with attached code, with a few deltas marked "for a PR" below. Resolve a bare #42 to an issue or PR per the tracker config.

Every comment or issue posted to the issue tracker during triage must start with this disclaimer:

> *This was generated by AI during triage.*

Reference docs

• AGENT-BRIEF.md: how to write durable agent briefs
• OUT-OF-SCOPE.md: how the .out-of-scope/ knowledge base works

Outcomes

Classify the request as a bug or enhancement, then recommend one outcome:

• Request more information from the reporter.
• Prepare it for human action.
• Close it without action.

These are recommendations, not tracker labels. Preserve the repository's existing labels and do not create, apply, or remove labels during triage.

Invocation

The maintainer invokes /triage and describes what they want in natural language. Interpret the request and act. Examples:

• "Show me anything that needs my attention"
• "Let's look at #42" (issue or PR)
• "Close #42 as already implemented"

Show what needs attention

Query open items and present them oldest first. Prioritise items with no prior AI triage comment, followed by items whose reporter has replied since the latest triage notes.

When PRs are in scope, include external PRs in the list and tag each line [PR] or [issue]. Discovery surfaces only external PRs (the tracker config defines who counts as external), so a collaborator's in-flight PR is not triage work. This filter is discovery-only; an explicitly named PR is always triaged regardless of author.

Show counts and a one-line summary per item. Let the maintainer pick.

Triage a specific issue or PR

1. Gather context. Read the full issue or PR (body, comments, labels, author, dates; for a PR, the diff too). Parse any prior triage notes so you don't re-ask resolved questions. Explore the codebase using the project's domain glossary, respecting ADRs in the area. Run two checks against the codebase: (a) redundancy: search for an existing implementation of the requested behavior by domain concept (not just the request's wording), and report where you looked. If found, recommend closing it as already implemented (step 5). (b) prior rejection: read .out-of-scope/*.md and surface any that resembles this request.

2. Recommend. Tell the maintainer whether this is a bug or enhancement and recommend an outcome with reasoning, plus a brief codebase summary relevant to the request (including whether it's already implemented). Wait for direction.

3. Verify the claim. Before any grilling, check that the claim holds up. For a bug, reproduce it from the reporter's steps. For a PR, confirm the diff does what it claims: check it out, run the relevant tests or commands. Report what happened: confirmed (with code path), failed, or insufficient detail (a strong signal to request more information). A confirmed verification makes a much stronger agent brief.

4. Grill (if needed). If the request needs fleshing out, call the Skill tool twice, for "grilling" and "domain-modeling", and grill it into shape a round of questions at a time, sharpening domain terms and updating GLOSSARY.md/ADRs inline as decisions land.

5. Apply the outcome:

   • Human action: post an implementation brief and note why it requires human judgment, external access, design decisions, or manual testing.
   • More information: post triage notes (template below).
   • Close without action: close the issue, with the comment depending on why:
     • Already implemented: the change already exists in the codebase. Point to where it lives; do not write to .out-of-scope/ (that KB is for rejected requests, not built ones).
     • Rejected (bug): give a polite explanation, then close.
     • Rejected (enhancement): write to .out-of-scope/, link to it from a comment, then close (OUT-OF-SCOPE.md).

Quick outcome override

If the maintainer specifies an outcome, trust them. Confirm what you're about to do (comment or close), then act. Skip grilling.

Triage notes template

## Triage Notes

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

- point 1
- point 2

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

- question 1
- question 2

Capture everything resolved during grilling under "established so far" so the work isn't lost. Questions must be specific and actionable, not "please provide more info".

Resuming a previous session

If prior triage notes exist on the issue or PR, read them, check whether the reporter has answered any outstanding questions, and present an updated picture before continuing. Don't re-ask resolved questions.