| name | triage-workflow |
| description | Use when /sc-plan or /sc-status needs to classify incoming issues, local Markdown issues, external PRs, feature requests, bug reports, stale tickets, ready-for-agent work, or wontfix decisions. |
Triage Workflow
Purpose
Move raw requests and existing issue files through a small state machine until each item is either agent-ready, human-owned, waiting for information, or intentionally rejected.
Announce: "I'm using the triage-workflow skill to classify and prepare issues."
Use this behind /sc-plan and /sc-status; do not add a standalone triage command.
State Model
Use category bug or enhancement and the canonical states in
status and done. Each issue
has one category and one state; conflicting states require a stop.
Process
1. Gather Context
Read the issue body, comments, linked FSD/PRD/BRD, related .scratch/ board, relevant code, tests, CONTEXT.md, and linked accepted ADRs.
Check two things before recommending work:
- Redundancy: is the requested behavior already implemented?
- Prior rejection: is the same enhancement already recorded under
.out-of-scope/ or project docs?
2. Recommend A State
Report the category, state, and short reasoning.
Before ready-for-agent, bugs need a reproduction/verification signal;
enhancements need concrete behavior, non-goals, acceptance, and verification.
For UI ready-for-agent, require ui_delivery_role, required_gate, and
qualified pinned contract refs. FIRST_VERTICAL_SLICE needs READY_FOR_SLICE;
SCALE_OUT_SLICE needs a first-slice issue at verified /
FIRST_VERTICAL_SLICE_VERIFIED, the same revision, and a VALIDATED baseline.
Only CONTRACT_ENABLER may bypass DRAFT/BLOCKED. HARDENING needs every UI
delivery slice verified, final refs, and a Business Owner for UAT. Missing or
stale evidence returns to needs-info/blocked.
3. Clarify When Needed
If underspecified, ask one focused question or record established facts and the
needed decision under Triage Notes, then use needs-info.
Use domain-modeling when terminology is fuzzy or disputed.
4. Produce Pointer-Only Agent Briefs
An issue pointer contains only metadata, qualified references to authority and
tests, Blocked by paths, UI role, pinned contract version, required gate, and
stop notes. It must not copy or duplicate requirements or acceptance prose.
Reference reproduction evidence by ID or path.
Issues generated by issue-workflow start fail-closed at needs-info. Triage
may promote them to ready-for-agent only after applicable gates pass; changed
or stale pointers must be rechecked. Without qualified authority refs, keep
needs-info and route specification to /sc-plan or its upstream owner.
5. Handle Rejections
For wontfix:
- Explain the reason concisely.
- If it is an already implemented request, point to the behavior and do not write out-of-scope memory.
- If it is a rejected enhancement, record the durable reason under
.out-of-scope/<concept>.md when future duplicate requests are likely.
Local Markdown Updates
When updating .scratch/<feature>/issues/*.md, preserve existing comments and append triage notes under ## Comments. Do not erase user-provided history.
Related Skills
issue-workflow creates issue-ready boardsdomain-modeling sharpens language and technical decision routingsystematic-debugging verifies bugsexecuting-plans consumes ready issues
