ワンクリックでManusで任意のスキルを実行

workflow-router

スター75

フォーク13

更新日2026年7月15日 00:33

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.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

KerberosClaw

KerberosClaw/kc_ai_skills

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

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

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

このリポジトリの他の Skills

同じリポジトリ

character-lora

KerberosClaw/kc_ai_skills

Use 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.

2026-07-1575

conference-report

KerberosClaw/kc_ai_skills

Use 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.

2026-07-1575

ctf-kit

KerberosClaw/kc_ai_skills

Use 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.

2026-07-1575

goal-engineer

KerberosClaw/kc_ai_skills

Use 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-cre

2026-07-1575

gpt-image-gen

KerberosClaw/kc_ai_skills

Use 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.

2026-07-1575

job-scout

KerberosClaw/kc_ai_skills

Use 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.

2026-07-1575

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 — 工程流程入口分流

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

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