菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when following the Super Compound BRD -> PRD -> FSD -> GOAL -> IMPLEMENTATION -> VERIFICATION delivery path, artifact traceability, FSD authority, optional ADR handling, zero context bloat issue slicing, or OPEN-* stop conditions.
Use when an approved FSD goal or lightweight issue pointer is ready for implementation.
Use when multi-component work needs cross-component verification of API contracts, data flow, events, auth, config, UI, background jobs, or tests.
Use when /sc-plan needs FSD GOAL-* packets turned into lightweight issue pointers, local Markdown Kanban boards, blocker DAGs, or multi-agent task contracts.
Use when a plan or issue board has 2+ independent execution streams whose time saving exceeds coordination overhead. Dispatches agents in isolated git worktrees only after required delivery gates pass.
Use when an FSD and goal issue board need requirement coverage, goal quality, dependency DAG, sizing, and verification validated before execution.
| 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. |
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.
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.
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:
.out-of-scope/ or project docs?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.
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.
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.
For wontfix:
.out-of-scope/<concept>.md when future duplicate requests are likely.When updating .scratch/<feature>/issues/*.md, preserve existing comments and append triage notes under ## Comments. Do not erase user-provided history.
issue-workflow creates issue-ready boardsdomain-modeling sharpens language and technical decision routingsystematic-debugging verifies bugsexecuting-plans consumes ready issues