triage-workflow

name	triage-workflow
description	Evaluate a request and recommend the appropriate workflow — GitHub issue only, GitHub issue + SDD spec, or full SDD spec — based on scope, complexity, and architectural impact.

Workflow Triage

Analyze a request and determine whether it warrants a GitHub issue only or a full Spec-Driven Development (SDD) workflow (with or without a preceding issue).

When to Use

Invoke this skill before starting any significant piece of work to select the right process and avoid over- or under-engineering the workflow.

/triage-workflow "<description of the request>"

---

Scoring Rubric

Evaluate the request on five dimensions. Score each 1–3.

Dimension	1 — Low	2 — Medium	3 — High
Scope	Single file or function	Multiple files, one subsystem	Cross-layer or multiple subsystems
Complexity	Solution path is obvious	Some design decisions required	Requires architectural design or research
Architectural impact	No interface/layer changes	New interface or minor restructure	Changes contracts, layer boundaries, or data models
Risk	Isolated, easily reversible	Moderate risk to adjacent code	Could break existing features or APIs
Ambiguity	Requirements are clear	Some clarification needed	Requirements are incomplete or contested

Total score range: 5–15

---

Decision Table

Total Score	Recommendation
5–7	GitHub Issue only — implement directly
8–11	GitHub Issue + SDD Spec — create an issue to track, then run the spec workflow
12–15	Full SDD Spec — spec-driven design first; issue is created as part of spec output

---

Execution Steps

Step 1 — Read the request

If $ARGUMENTS is provided, use that as the request description. Otherwise, ask the user to describe the request in 1–3 sentences.

Step 2 — Score each dimension

Think through each of the five dimensions carefully. Write a 1-sentence rationale for each score. Sum the scores.

Step 3 — Output the recommendation

Follow the format below. Always include:

• The score breakdown table
• The recommendation label
• Concrete next steps (commands or actions)

Step 4 — Offer to proceed

Ask the user: "Shall I proceed with the recommended workflow?" If yes, execute the first step of that workflow automatically.

---

Output Format

## Workflow Triage

**Request**: {brief restatement of the request}

### Dimension Scores

| Dimension | Score | Rationale |
|-----------|-------|-----------|
| Scope | {1–3} | {one sentence} |
| Complexity | {1–3} | {one sentence} |
| Architectural impact | {1–3} | {one sentence} |
| Risk | {1–3} | {one sentence} |
| Ambiguity | {1–3} | {one sentence} |
| **Total** | **{5–15}** | |

### Recommendation: {GitHub Issue only | GitHub Issue + SDD Spec | Full SDD Spec}

{2–3 sentence explanation of why this workflow fits.}

### Next Steps

{Bullet list of concrete actions, e.g.:}
- Create GitHub issue: `gh issue create --title "..." --body "..."`
- Run spec init: `/kiro:spec-init "<description>"`
- Or: implement directly with a feature branch and PR

---

Examples

Example A — Minor fix (score 5–7)

"Fix the typo in the error message when config file is missing"

• Scope: 1 (single string in one file)
• Complexity: 1 (trivial change)
• Architectural impact: 1 (none)
• Risk: 1 (no logic change)
• Ambiguity: 1 (clear)
• Total: 5 → GitHub Issue only

Example B — Medium feature (score 8–11)

"Add a --dry-run flag to the CLI that skips side effects but logs what would happen"

• Scope: 2 (CLI parsing + service layer)
• Complexity: 2 (needs consistent propagation through services)
• Architectural impact: 2 (new port parameter or flag threading)
• Risk: 2 (touches execution path)
• Ambiguity: 2 (behaviour in edge cases needs definition)
• Total: 10 → GitHub Issue + SDD Spec

Example C — Major redesign (score 12–15)

"Redesign the memory system to support multiple backends with a pluggable adapter interface"

• Scope: 3 (domain + application + infra + tests)
• Complexity: 3 (multiple design options, trade-offs to evaluate)
• Architectural impact: 3 (new port interface, adapter contracts)
• Risk: 3 (existing memory behaviour must be preserved)
• Ambiguity: 2 (goal is clear, implementation path is not)
• Total: 14 → Full SDD Spec

---

Design Principles

• Bias toward lightweight: When on the boundary, prefer the lighter-weight workflow.
• One recommendation: Output a single clear recommendation, not a range.
• Action-oriented: Always end with runnable commands or instructions.
• No over-engineering: A GitHub issue is a valid and often correct answer.