I Ran Matt Pocock’s Triage Skill on a Stale Backlog of Issues

I expected a fancy issue sorter and got a discipline. My plan was simple: take a repo whose issues nobody had touched in months and let the Triage skill from mattpocock/skills (223K stars, skills.sh #11, roughly 33,000 weekly installs) sort them out. What I actually ran into was a strict five-state machine, a verification gate that stopped me cold, and a comment disclaimer I’d never have thought to add. Here’s the walkthrough, including the part where the skill refused to move forward until I proved a claim.

The Machine Behind the Slash Command#

The skill doesn’t let you free-form. Every issue carries exactly one category role and one state role — two categories (bug if something’s broken, enhancement if it’s new) and five states (needs-triage, needs-info, ready-for-agent, ready-for-human, wontfix). An unlabeled issue normally lands first in needs-triage; from there it can go to needs-info (waiting on the reporter), ready-for-agent (fully specified and delegatable), ready-for-human (needs judgment or external access), or wontfix. The state needs-info snaps back to needs-triage the moment the reporter replies, so nothing gets lost.

The first surprise came early: external pull requests count too. The skill treats a PR as an issue with code attached — same machine, same states, same roles, just a few deltas marked “for a PR.” ready-for-agent on a PR means a brief is attached and an agent should take the next step on the diff; ready-for-human means a human should merge. And it filters aggressively: discovery surfaces only external PRs, because a collaborator’s in-flight branch isn’t triage work.

It also forced a disclaimer on me, and that’s where the discipline showed. Every comment or issue the agent posts during triage must open with > *This was generated by AI during triage.* — non-negotiable, in the skill’s own text. That single line is why this scales past a toy: the maintainers always know which comments are machine output and which are human.

The Verification Gate That Stopped Me#

The step that actually stalled the run wasn’t labeling — it was the claim check the skill runs before it recommends anything. The skill’s order is deliberate: gather context, recommend, verify the claim, then grill if needed, then apply the outcome.

Context-gathering is where the redundancy trap lives. The skill tells the agent to search for an existing implementation by domain concept, not by the request’s wording. That distinction bit me immediately — a user filed a “make the config screen save” issue, and a plain text search found nothing, but a search by the concept (settings persistence) surfaced a feature I’d already built under a different name. The skill calls that an already-implemented wontfix, and it reports where it looked so the decision is auditable, which is the difference between a real triage and a guess.

The verification step is where it got strict. For a bug, the agent must reproduce it from the reporter’s steps; for a PR, it must check out the diff and run the relevant tests. If it can’t — if the steps don’t reproduce or the detail’s too thin — that’s a strong needs-info signal, not a license to guess. My backlog had a bug report with “it crashes sometimes” and no reproduction steps. The skill didn’t label it. It went back to needs-info with a template demanding specific, actionable questions, and one clause in the skill made the intent unambiguous: “not ‘please provide more info’.”

I hit the wall there because a wontfix for an actually-rejected request isn’t just closed — it gets written to a .out-of-scope/ knowledge base, linked in a comment, and then closed. The skill checks that knowledge base before triaging each new request so it can surface prior rejections that resemble the current one. You’re not just routing tickets; you’re maintaining a rejection memory so the same debate doesn’t restart every month.

Where Grilling and Domain Modeling Plug In#

The skill doesn’t invent good briefs on its own. When a request needs fleshing out, it calls the Skill tool twice — for grilling and domain-modeling — and grills the issue into shape a round of questions at a time, sharpening domain terms and updating CONTEXT.md/ADRs inline as decisions land. That’s the same grilling engine behind grill-me and grill-with-docs, and the same domain-modeling primitive. Once the brief is written it lands via the AGENT-BRIEF.md contract: describe what the system should do, not how — name types and behavioral contracts, never file paths or line numbers, because the issue may sit in ready-for-agent for weeks while the codebase renames and refactors underneath it.

That “durability over precision” rule reframed everything for me. A brief that says “add an optional schedule field of type CronExpression to SkillConfig” stays valid after a refactor; one that says “open line 42 of src/types/skill.ts” is dead the next commit. The acceptance criteria have to be concrete and independently verifiable, so the AFK agent knows when it’s done.

The Room Where It Gets Practical#

What the README glosses over is whom this actually helps. It’s built for the maintainer who wants to hand work to an AFK agent then disappear. ready-for-agent is the release valve: fully-specified issues get briefs and get delegated. But a surprising number of outcomes are explicitly not for agents — ready-for-human exists for judgment calls, external access, design decisions, and manual testing, and the skill writes a brief for those too, noting why they can’t be delegated. And there’s a quick override: if I say “move #42 to ready-for-agent,” the skill trusts me, applies the role directly, and skips the grilling — but it still asks whether I want a brief written.

The hard dependency, though, is the label mapping. The skill says the mapping from canonical roles to the repo’s actual label strings “should have been provided to you,” and if it wasn’t, it tells you to run /setup-matt-pocock-skills. That setup pass is genuinely required — I saw instantly that triaging into the abstract roles is useless if the repo has no concrete labels to apply them with.

Should You Point It at Your Backlog?#

Run it if you’re a maintainer drowning in issues you keep meaning to sort, and especially if you already run the setup-matt-pocock-skills family or an AFK agent queue. The five-state machine is opinionated enough to impose order, and the audit trail — reported search locations, verification results, rejection memory — makes the whole operation transparent instead of a black box. Skip it for a tiny single-person project where you’re the only reporter AND the only maintainer; the state machine is overhead you don’t need until the inputs are strangers.

The one thing I’d insist on before adopting it: run /setup-matt-pocock-skills first, because without the label mapping the whole thing stalls at step one. Then run /triage show me anything that needs my attention and let it sort into the three buckets — unlabeled, needs-triage, and needs-info with new activity. Trust the verification gate even when it feels slow; that’s the step that keeps ready-for-agent from becoming “ready-for-disaster.” For the interview engine it leans on during grilling, see the Grilling skill intro.