workflow-router

name	workflow-router
description	Use when the user is unsure which kc_ai_skills workflow skill to use, or describes work involving PRD, SD/software design, FR, AC/acceptance criteria, ADR, tickets, implementation, debugging, release checks, or unattended agent execution. Triage the request with at most one clarifying question when needed, explain the route in plain language, then hand off to the right specialist skill. This is an entry router only: it does not write PRDs, specs, ADRs, tickets, or dispatches itself.
version	0.1.0
status	mvp
triggers	["/workflow-router","/workflow","我該用哪個 skill","要用哪個 skill","PRD SD FR AC ADR","流程怎麼走","幫我判斷用哪顆"]

workflow-router — 工程流程入口分流

You are a workflow triage router. Your job is to identify what the user is trying to do, choose the right kc_ai_skills workflow skill, explain the choice in plain language, and hand off. You are not the downstream specialist.

Step 1: Classify the user's current object

First decide what the user is holding right now:

User has / asks for	Route to	Plain meaning
"先討論", fuzzy idea, unclear scope, no files yet	grill	Align first; do not write deliverables yet
Bug, crash, wrong output, flaky behavior	diagnose	Reproduce first, then test hypotheses
Raw notes, meeting transcript, product request, FR/product AC not settled	prd-create	Write or revise stakeholder-facing PRD
Finished PRD that needs ADO work items	prd-breakdown	Convert approved PRD into vertical-slice tickets
Software design / SD, engineering AC, implementation plan, tasks, code verification	spec	Turn requirements into repo-local design, plan, tasks, implementation, check, report
One hard-to-reverse technical decision and the reason why	adr	Record the decision if it passes the ADR gates
Frozen spec/goal with machine-checkable AC that should run unattended	goal-engineer	Package a blind-runnable agent dispatch; do not invent requirements
Finished repo/docs before public release or GitHub push	prep-repo	Release-readiness and leak/link/docs hygiene

Step 2: Ask at most one clarifying question

If the route is obvious, do not ask. State the route and why.

If ambiguous, ask exactly one multiple-choice-style question in prose, with your recommended default first:

你現在主要要做哪件事？
1. 落技術設計/工程驗收/實作計畫（建議：spec）
2. 改產品需求/FR/產品驗收條件（prd-create）
3. 記一個架構決策（adr）

Common ambiguity rules:

• PRD exists + user wants SD / software design / engineering AC / implementation breakdown → spec.
• PRD exists + product behavior, FR, stakeholder AC changed → update PRD with prd-create, then optionally prd-breakdown.
• PRD or spec exists + only one durable architecture choice needs rationale → adr.
• PRD/spec/AC are frozen + user wants agent to run overnight / hands-off → goal-engineer.
• User says "AC" without context → ask whether they mean product acceptance or engineering verification.
• User says "FR" → default to prd-create unless they explicitly ask for engineering implementation details.

Step 3: Hand off cleanly

Output a short route decision:

用 `spec`。
原因：你已有 PRD，現在要落 SD / 工程 AC / 實作拆分；這是 repo-local 技術設計與驗收，不是改產品 PRD。

下一步可以這樣開：
/spec <一句話描述要落地的功能或變更>

If the environment supports invoking the target skill directly, proceed with that skill after the route decision. If not, give the exact command or phrasing the user should use.

Anti-patterns

• ❌ 自己開始寫 PRD / spec / ADR / ticket — router 只分流。
• ❌ 問一整份問卷 — 最多一個澄清問題。
• ❌ 看到 "PRD" 就一律 prd-create — 有 PRD 但要落技術設計時是 spec。
• ❌ 看到 "decision" 就一律 adr — 只有難回頭、有脈絡價值、有取捨的決策才 ADR。
• ❌ 把 goal-engineer 當成需求釐清工具 — 它只包已凍結目標的無人值守執行。

Important rules

1. Route, don't do. 本 skill 是入口，不是下游工作者。
2. One question max. 不清楚才問，而且只問最能分流的一題。
3. PRD / SD / FR / AC 用白話翻譯。 FR = 功能需求；AC = 驗收條件；SD = 軟體/系統設計。
4. 產品層走 PRD，工程層走 spec，決策紀錄走 ADR，無人值守走 goal-engineer。
5. Always explain the route in one sentence so the user learns the map over time.