triage

name: triage description: Triage incoming bugs and feature requests through a state machine. Use when user wants to process a bug report, triage issues, review incoming requests, prepare work for an agent, or manage issue workflow.

Triage

Why This Matters

In any busy shop — a garage, a hospital, a help desk — work comes in faster than it can be done. The difference between a team that stays in control and one that drowns is triage: a disciplined process for deciding what gets worked on, in what order, and by whom.

Without it, developers work on whatever lands in front of them. Urgent bugs get buried under nice-to-haves. Work gets started that isn't well-defined enough to finish. Time gets spent on things that should have been declined.

This skill gives you a simple state machine: every incoming bug or feature request gets evaluated, categorized, and moved to the right next state — whether that's "needs more information," "ready for a developer to pick up," or "not something we're building." It keeps the queue honest and makes sure nothing important falls through the cracks.

This methodology is tool-agnostic. The triage process works the same whether you're using GitHub Issues, a task board, or a notes file. The AI can help evaluate and draft responses — but the decision on what gets worked is always a human call.

Move issues through a small state machine of triage roles.

Every comment posted during triage must start with this disclaimer:

> *This was generated by AI during triage.*

Roles

Two category roles:

• bug — something is broken
• enhancement — new feature or improvement

Five state roles:

• needs-triage — maintainer needs to evaluate
• needs-info — waiting on reporter for more information
• ready-for-agent — fully specified, ready for an AFK agent to implement
• ready-for-human — needs human implementation (judgment calls, design decisions, external access)
• wontfix — will not be actioned

Every triaged issue should carry exactly one category role and one state role.

wxKanban note: issues may live in GitHub Issues or in the wxKanban task DB. When working with the task DB, map these roles to task status values accordingly.

Invocation

The user invokes /triage and describes what they want in natural language. Examples:

• "Show me anything that needs my attention"
• "Let's look at BUG-42"
• "Move this to ready-for-agent"
• "What's ready for agents to pick up?"

Show what needs attention

Query the issue source and present three buckets, oldest first:

1. Unlabeled / unstatused — never triaged.
2. needs-triage — evaluation in progress.
3. needs-info with reporter activity since the last triage notes — needs re-evaluation.

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

Triage a specific issue

1. Gather context. Read the full issue (body, comments, labels, reporter, dates). Parse any prior triage notes so you don't re-ask resolved questions. Explore the codebase using CONTEXT.md vocabulary, respecting any ADRs in the area.

2. Recommend. Tell the maintainer your category and state recommendation with reasoning, plus a brief codebase summary relevant to the issue. Wait for direction.

3. Reproduce (bugs only). Before any grilling, attempt reproduction: read the reporter's steps, trace the relevant code, run tests or commands. Report what happened — successful repro with code path, failed repro, or insufficient detail (a strong needs-info signal). A confirmed repro makes a much stronger agent brief. For complex bugs, hand off to /diagnose.

4. Grill (if needed). If the issue needs fleshing out, run a design session to sharpen the requirements.

5. Apply the outcome:

   • ready-for-agent — write an agent brief (see template below).
   • ready-for-human — same structure as an agent brief, but note why it can't be delegated.
   • needs-info — post triage notes (see template below).
   • wontfix (bug) — polite explanation, then close/mark resolved.
   • wontfix (enhancement) — note why, link to any related spec, then close.
   • needs-triage — apply the state. Optional comment if there's partial progress.

Quick state override

If the user says "move this to ready-for-agent", trust them and apply directly. Confirm what you're about to do, then act. Skip grilling. If moving to ready-for-agent without a grilling session, ask whether they want to write an agent brief.

Needs-info template

> *This was generated by AI during triage.*

## Triage Notes

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

- point 1
- point 2

**What we still need from you:**

- question 1 (specific and actionable)
- question 2

Agent brief template

> *This was generated by AI during triage.*

## Agent Brief

**Category**: bug | enhancement
**Scope**: which part of the codebase

**What to build / fix**

A concise description of the end-to-end behavior. Not layer-by-layer — what should be true when done.

**Acceptance criteria**

- [ ] Criterion 1
- [ ] Criterion 2

**Relevant files**

- `src/path/to/file.ts` — reason it's relevant

**Blocked by**

None / list blockers.

Resuming a previous session

If prior triage notes exist, read them, check whether outstanding questions have been answered, and present an updated picture before continuing. Don't re-ask resolved questions.