Turn a vague bug report (Slack message, support ticket, "it's broken on mobile sometimes") into an actionable ticket — searchable symptom title, numbered repro steps from a clean state, expected vs actual, severity separated from priority, evidence tagged reported-vs-verified, and labeled hypotheses instead of root-cause guesses. Use when the user wants to triage a bug, write up a bug report, turn a complaint into a ticket, or make a flaky issue actionable.
Pack dev-teamTier standardJob Build and review softwarev0.1.0
In Claude Code, with the dev-team plugin installed, invoke it as:
/dev-team:bug-triage
Try it
A realistic prompt from the skill's acceptance evals:
Triage this report: 'checkout is broken on mobile sometimes, a customer complained in Slack this morning'.
What a good result looks like
An engineer can start without contacting the reporter. Either the repro stands alone or the no-repro diagnostics list says exactly what to collect.
Title findable by symptom search. If the words a future reporter would type don't appear in it, retitle.
Zero untagged claims. Every factual statement is [reported], [verified], or [assumption] — a triager's authority comes from the tags.
Severity and priority each have a stated reason, and they were judged independently — one line each, no shared justification.
Hypotheses ≤ 3, each with a concrete check. A hypothesis without a check is a vibe.
The verbatim error text is present when any error was shown — quoted exactly, not paraphrased.
How it's checked
Measured against plain Claude Code (2026-10-23): it met 58% of its checks, against 41% without it, and a blind judge preferred the agent without it. How skills are checked
19 assertions across 3 acceptance evals, and 8 trigger queries. Every skill's checks
What the output must do
An engineer could start work without contacting the reporter — either the repro steps stand alone, or a no-repro diagnostics list states exactly what to collect
The title is findable by symptom search, containing the words a future reporter would type
Repro steps are numbered and start from a clean state
Expected versus actual behaviour are stated separately
Every factual claim is tagged [reported], [verified], or [assumption] — nothing is asserted untagged
Severity is assigned with a stated reason rather than inherited from the reporter's tone
Uses the log to show that only one $6.50 was captured for acct_7781; the other $6.50 was an authorisation that was voided 30 minutes later, so the 'charged twice' claim is the customer's report, not a confirmed second charge
Points out that the same pattern appears on 2026-10-14 on app version 3.1.4, before 3.2.0 shipped, so the claim that 3.2 is the cause is not supported
Does not take on the 'P0, happening to everyone' framing; it notes 3 affected accounts out of 4,812 orders and sets urgency with its own stated reasons
Does not give a definite root cause; any cause is offered as a hypothesis together with what would confirm or rule it out
Notes the conflict between the log, which says a pass was issued for the captured order, and the customer saying no pass appeared
Does not invent a phone model, iOS version, error message or figures that are not in the files
The ticket itself fits on roughly one screen (about 40 lines or fewer)
Produces a short write-up of a few lines that IT could act on, not a long report
States the symptom clearly: being logged out after switching tabs, with unsaved register entries lost
Treats the lost register data as the serious part when judging how urgent it is
Lists the few details IT will need that the report does not give (for example browser, how long she was away from the tab, the time it happened) instead of guessing them
Does not invent a browser, device, error message or cause; any suggested cause is clearly marked as a guess
Delivers the write-up without stopping to ask questions first
When it should and shouldn't activate
Should activate:
Turn this vague bug report into an actionable ticket
A customer says it's broken on mobile sometimes — triage it
Write up this Slack complaint as a proper bug with repro steps
Triage and prioritize this support ticket
Should leave to another skill:
Review this diff for bugs and edge cases
Write the blameless postmortem for the outage
Split this epic into user stories
Write a test plan for this release
Hands off to
feature-implement-loop — when the defect is reproduced and scoped. Fix the triaged defect through the same capped loop a story gets.