Triage by @mattpocock · Skillet

Triage

Move issues and external PRs through a state machine of triage roles, categorise, verify, grill if needed, and write agent-ready briefs.

Permissions

Files

SKILL.md

triage

Move issues and external PRs through a state machine of triage roles, categorise, verify, grill if needed, and write agent-ready briefs.

disable-model-invocation: true

Triage

Move issues on the project issue tracker through a small state machine of triage roles.

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, using the same roles, same states, and same machine, 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.*

4 files · 19 KB6 KB

Version history

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, it's an already-implemented wontfix (step 5). (b) prior rejection: read .out-of-scope/*.md and surface any that resembles this request.
Recommend. Tell the maintainer your category and state recommendation with reasoning, plus a brief codebase summary relevant to the request (including whether it's already implemented). Wait for direction.
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 needs-info signal). A confirmed verification makes a much stronger agent brief.
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.
Apply the outcome:
- ready-for-agent: post an agent brief comment (AGENT-BRIEF.md).
- ready-for-human: same structure as an agent brief, but note why it can't be delegated (judgment calls, external access, design decisions, manual testing).
- needs-info: post triage notes (template below).
- For wontfix, 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).
- needs-triage: apply the role. Optional comment if there's partial progress.

## Triage Notes

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

- point 1
- point 2

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

- question 1
- question 2

Triage

Triage

Reference docs

Roles

Invocation

Show what needs attention

Triage a specific issue or PR

Quick state override

Needs-info template

Resuming a previous session