triage-workflow

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 boards
• domain-modeling sharpens language and technical decision routing
• systematic-debugging verifies bugs
• executing-plans consumes ready issues