workflow-router

$npx mdskill add KerberosClaw/kc_ai_skills/workflow-router

Route user requests to appropriate workflow skills

  • Identify and triage user's current object for proper routing
  • Deploys user request to relevant kc_ai_skills workflow skill
  • Explains route in plain language, ensuring clarity and understanding
  • Delivers results or next steps directly to the user

SKILL.md

.github/skills/workflow-routerView on GitHub ↗
---
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:

```text
你現在主要要做哪件事？
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:

```text
用 `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.

More from KerberosClaw/kc_ai_skills

SkillDescription
character-loraUse when the user wants to build a consistent-identity LoRA for an original character — defining the character, generating a face/body-consistent multi-angle dataset (via the gpt-image-gen skill for codex image generation), captioning it, doing base-specific homework, training on a chosen base (Pony / Z-Image / others) on a local GPU, and producing a usable LoRA. This skill ORCHESTRATES the end-to-end pipeline and gates every expensive/irreversible step; it delegates actual image generation to gpt-image-gen and never improvises training settings from memory.
conference-reportUse when the user attended one or more sessions of a conference (with audio recordings + slide photos) and needs help building (1) faithful per-session reconstructions in markdown (slide visuals + speaker transcript with Whisper hallucination annotations), and (2) a downstream report deliverable whose scope and format are decided interactively with the user. Pipeline phase (raw → mlx_whisper Chinese SRT → per-slide multimodal reconstruction → official agenda cross-check via Playwright if available) is deterministic. Report phase is interactive — always quiz user on scope (single-session / single-day / multi-day synthesis), format (existing template / free-form fallback), recipient (formal / informal), and any business workstream mapping before drafting.
ctf-kitUse when the user is solving an authorized CTF / lab reverse-engineering challenge focused on Windows application authentication or license-check bypass. Guides triage → static analysis → dynamic experiment planning → bypass verification, with strong evidence discipline and VM safety boundaries. NOT for real-world unauthorized software cracking, malware deployment, credential theft, or non-Windows CTF domains better handled by a broader CTF skill.
goal-engineerUse when the user wants to AUTHOR an unattended dispatch for either: (1) a goal-driven evaluator-optimizer loop of the GENERATE-AND-SELECT kind (generate candidates → grade against a rubric → iterate by reason-code → keep the best; the human picks the final selection), or (2) a lean build-to-spec run whose build spec is ALREADY FROZEN (approved ADR / locked design / accepted machine-checkable AC) and the only missing piece is the unattended-execution wrapper. A fresh-session agent runs the dispatch hands-off while the human only watches traffic-light push notifications. Interview-style forcing questions lock the spec, then it emits a self-contained dispatch markdown + a channel-agnostic notification protocol. This is the upstream SPEC AUTHOR, NOT a runtime: the dispatch is run by Claude Code's /goal, a headless `-p` session, or any unattended agent — /goal is the engine, this writes what you feed it. It NEVER authors build specs, product decisions, or AC — creating a build spec / PRD from raw input is prd-create. NOT a time scheduler (/loop or cron), NOT a recurring-push registrar (skill-cron).
gpt-image-genUse when the user asks to generate an image via GPT/Codex (e.g. 「叫 gpt 生圖」「幫我用 gpt 生圖」「gpt 畫一個 X」). The skill drafts a Chinese + English prompt pair, iterates with the user until they explicitly approve, then dispatches Codex CLI ($imagegen skill, codex built-in image_gen) in the background, monitors progress, converts the result to a jpg in the current working directory, and writes a sidecar prompt log. Does text-to-image AND img2img — drop a reference image (on-disk file) and it runs Codex `-i` to lock a face/character across scenes.
grillUse when the user says 先討論 / wants to align on a fuzzy idea before building, or before any non-trivial implementation whose requirements are still ambiguous — interviews the user until shared understanding is confirmed, one question at a time, each with a suggested answer; facts answerable from the filesystem/code are looked up, never asked. Optionally maintains the repo's CONTEXT.md glossary when vocabulary settles during discussion. Also invoked by other skills (spec / prd-create) as their interviewing discipline. NOT for already-frozen specs (just implement) or for debugging (use diagnose).
job-scoutUse when the user is considering applying to, interviewing with, or accepting an offer from a company and wants due diligence on the company and optionally a specific role. Requires a company name, optionally a job title, then researches current public data, employee reviews, salary signals, product/tech quality, and red flags before giving a grounded recommendation. NOT for generic career coaching or resume editing.
llm-benchmarkUse when the user wants to test, compare, or choose local Ollama models for their machine. Checks Ollama/GPU state, recommends model sizes from available VRAM, preserves existing benchmark records, pulls only approved models, runs repeatable benchmarks, restores stopped services, and writes a markdown comparison report. NOT for hosted API model evaluation or subjective chat-quality judging without local benchmark commands.
llm-wiki-lintUse when the user wants to lint a repo following the Karpathy LLM Wiki pattern (raw/ + wiki/ + SCHEMA.md / index.md / log.md). The skill detects path, scans wiki pages + schema layer, reports frontmatter gaps, broken in-body links, source traceability breaks, stale claims, orphan pages, index synopsis contradictions, and SCHEMA-vs-reality drift. Phase 1 is read-only report; Phase 2 (fix + log.md LINT entry) only runs after the user explicitly approves.
md2pdfUse when the user wants to convert one Markdown file into a publication-ready A4 PDF, especially when the source may contain Mermaid diagrams, ASCII diagrams, CJK text, tables, or pandoc/weasyprint edge cases. Works by copying the source to a _pdf.md working file, converting diagrams, escaping PDF-breaking syntax, rendering with pandoc + weasyprint, then self-checking pages. NOT for batch conversion, slide decks, or editing the original Markdown in place.