Guide AI agents through engineering workflows with composable skills

Triage moves issues (and external pull requests, treated as "an issue with attached code" - same roles, same states) through a small state machine: two category roles (bug, enhancement) and five state roles (needs-triage, needs-info, ready-for-agent, ready-for-human, wontfix), with every triaged item carrying exactly one of each. Every AI-posted comment or issue during triage must open with a fixed disclaimer that it was generated by AI during triage, and canonical role names map to whatever actual labels the issue tracker uses.

Use it to move issues and external PRs through categorize/verify/grill/brief - invoked via /triage plus natural language ("show me anything that needs attention," "move #42 to ready-for-agent"). Discovery of what needs attention surfaces only external PRs per the tracker's own definition of "external" - a collaborator's in-flight PR isn't triage work by default, though an explicitly named PR is always triaged regardless of author. Conflicting state roles or unusual maintainer-requested transitions get flagged and confirmed before acting rather than applied silently.

Triaging a specific issue runs five steps: gather context (read the full issue/PR including diff for a PR, parse prior triage notes to avoid re-asking resolved questions, and run a redundancy check - searching the codebase for an existing implementation by domain concept, not just the request's wording - plus a prior-rejection check against .out-of-scope/*.md); recommend a category/state with reasoning and wait for maintainer direction; verify the claim before any grilling (reproduce a bug from the reporter's steps, or check out a PR's diff and run the relevant tests, reporting confirmed/failed/insufficient-detail); grill if needed by running /grilling and /domain-modeling together, updating CONTEXT.md/ADRs inline as terms sharpen; and apply the outcome - an agent brief for ready-for-agent, the same structure noting why it can't be delegated for ready-for-human, a structured needs-info template ("established so far" / "still need from you") for needs-info, or a close for wontfix whose comment depends on why: already-implemented gets pointed to its code location (never logged to .out-of-scope/, which is for rejected requests only), a rejected enhancement gets written there and linked, a rejected bug gets a polite explanation.

> *This was generated by AI during triage.*

Depends on the project's issue tracker having a role-to-label mapping already configured (via /setup-matt-pocock-skills if missing), and composes directly with /grilling (interview mechanism) and /domain-modeling (glossary/ADR capture) for fleshing out an underspecified request, plus companion reference docs AGENT-BRIEF.md and OUT-OF-SCOPE.md defining the brief format and the rejected-request knowledge base.

Maintainers who want a consistent, verified triage process for their issue tracker - separating what's genuinely ready for an autonomous agent from what needs a human, information, or a polite close - without re-litigating already-rejected requests or writing agent briefs for claims that haven't actually been verified.