skill-router

skill-router 技能總覽

skill-router 是做什麼的

skill-router 是多技能 Claude Code 設定中的前置分流器。它不會直接替你完成任務，而是先分析請求內容、判斷最適合交給哪個專門技能，並在需求過於模糊、無法有把握地分流時主動提出釐清問題。若你正在評估 agent-playbook，或想讓以技能為核心的工作流程更容易被團隊成員實際採用，skill-router 往往是最先能降低摸索成本的那一塊。

哪些人適合安裝 skill-router

skill-router 最適合手上有不只一個技能可用，且常遇到這類提示的人：「我該用哪個技能？」「幫我處理這個專案」「幫我挑一個技能來做這件事」。它特別適合：

• 想把 agent 的技能選擇方式標準化的團隊
• 剛接觸某套技能庫的新使用者
• 同一個模糊請求，實際上可能指向 review、debugging、docs、testing 或 design 工作流程的場景

如果你平常只用一兩個技能，而且本來就很清楚該叫用哪一個，skill-router 的附加價值就會比較有限。

skill-router 真正要解決的問題

skill-router 真正要處理的，不只是「推薦一下用哪個技能」。它的價值在於把定義不足的請求，轉成可執行的下一步：選出技能、說明原因，並補齊剛好足夠往下做的上下文。這件事很重要，因為很多技能系統不是敗在執行品質，而是在第一個決策點就選錯方向。

skill-router 的關鍵差異點

和一般的「我該用哪個工具？」提示相比，skill-router 有幾個實務上的優勢：

• 它明確被設計成要在流程一開始就觸發，避免太早選錯專門技能
• 它帶有技能目錄導向，會把使用者意圖對應到現有技能清單
• 當意圖不明時，它支援先做釐清
• 它會透過 after_complete hook 記錄分流決策；如果你想觀察團隊長期是怎麼選技能的，這點很有用

安裝 skill-router 前最該確認的事

採用 skill-router 前，先確認兩件事：

1. 你的環境裡是否真的有一組值得分流的下游技能
2. 你的使用者是否常帶著模糊目標進來，而不是一開始就把任務講得很精準

skill-router 最適合放在一個經過整理、具備明確技能目錄的生態系裡擔任 dispatcher。若技能清單很小、已過時，或做了很多客製化卻沒有同步更新 router 邏輯，它作為獨立資產的價值就會明顯變弱。

如何使用 skill-router 技能

skill-router 的安裝位置與情境

在這個 repository 裡，skill-router 位於 skills/skill-router。repo 的 README 展示的是以 symlink 為主的安裝方式：

ln -s ~/Documents/code/GitHub/agent-playbook/skills/skill-router/SKILL.md ~/.claude/skills/skill-router.md

如果你的環境支援 skill manager，請依本機技能目錄調整安裝路徑。重點是要讓 SKILL.md 能被 Claude Code 的 skill loader 以預期的技能名稱正確發現。

建議先讀哪些檔案

若想快速判斷值不值得裝，先讀：

1. skills/skill-router/SKILL.md
2. skills/skill-router/README.md

SKILL.md 會告訴你實際的啟動邏輯、允許使用的工具、分流行為，以及可用技能目錄。README.md 比較適合看高層流程與範例，但真正與安裝判斷最相關的細節，主要還是在 SKILL.md。

什麼時候該先觸發 skill-router

當請求在「該選哪個技能」這一層還不夠明確時，就應該先用 skill-router，例如：

• 「幫我看看這個 codebase」
• 「用一個技能來改善這個」
• 「這個 PR 我該用哪個技能？」
• 「我需要幫忙，但不確定這算 debugging 還是 refactoring」

repository 也明確把 skill-router 定位成與技能相關請求的預設入口，特別是當使用者提到「skill」、「which」、「how to」，或直接表現出不確定時。

skill-router 需要哪些輸入資訊

skill-router 在以下資訊齊備時效果最好：

• 任務目標
• 產物類型：PR、bug、README、test suite、design file、commit 等
• 想達成的結果
• 對需要哪一類協助仍有哪些不確定

這些資訊能讓 router 更有把握把意圖映射到某個技能，而不是退回到很寬泛的釐清提問。

把模糊需求改寫成可分流的提示

較弱的輸入：

• 「幫我的專案用個技能處理一下」

較強的輸入：

• 「我需要協助 review 一個 Node.js API 的 pull request。我想要針對 correctness、security 和 maintainability 給我回饋。Which skill should I use?」

為什麼這樣比較好：

• 點出了處理對象
• 說明了關注的品質面向
• 縮小了可能的技能類別
• 但仍把分流決策交給 skill-router

常見的 skill-router 使用模式

直接分流的情境：

• 「我這些 staged changes 想寫一則乾淨的 commit message，該用哪個技能？」
• 「我需要診斷一個 Python service 裡失敗的 test suite。哪個技能最適合？」
• 「Use skill-router for Skill Discovery across docs, testing, and refactoring tasks in this repo.」

預期會先釐清的模糊分流情境：

• 「幫我在 release 前把這個專案整理好。」
• 「幫這個 design handoff 選個技能處理。」
• 「我卡住了，不確定自己需要的是 debugging、review 還是 refactoring。」

skill-router 分流後建議怎麼接續

一個實用的工作流程是：

1. 先用粗略任務描述呼叫 skill-router
2. 針對它的釐清問題，簡短但具體地回答
3. 確認它推薦的技能
4. 帶著整理過的任務敘述，切換到對應的專門技能
5. 保留剛才釐清出的上下文，讓下游技能一開始就有足夠細節可用

skill-router 的價值就在這裡：它把從模糊意圖到可執行專門技能呼叫之間的交接成本壓縮掉。

可預期的 skill-router 目錄分類

從 repository 摘錄可看出，skill-router 是圍繞一份技能目錄設計的，涵蓋的區域包括：

• core development
• design and UX
• documentation and testing

目錄中點名的範例包含 commit-helper、code-reviewer、debugger、refactoring-specialist、figma-designer，以及偏 documentation 的技能。這表示當你的請求能落進這些已被編目的路徑時，skill-router 會最有用。

使用 skill-router 的實際限制

skill-router 不能取代專門技能。它是 selector，不是最後的 executor。若你的任務已經精準到可以直接交給 debugger 或 code-reviewer，先走分流反而可能只是多一層流程成本。

它也高度依賴目錄品質。如果你實際安裝的技能組，和 SKILL.md 內建目錄不一致，推薦結果就可能過時，甚至誤導使用者。

值得注意的工具與行為

這個技能允許使用 Read、AskUserQuestion、WebSearch 和 Grep。在實務上，最關鍵的是 AskUserQuestion，因為只要在推薦前先把模糊處釐清，分流品質通常會明顯提升。

它也為 session-logger 定義了 after_complete hook，原因是「Log skill routing decisions」。如果你在意可稽核性，或想分析使用者最常在哪些任務類型上不知道怎麼分類，這是很有價值的實作細節。

skill-router 技能 FAQ

skill-router 適合新手嗎？

適合，特別是當新手面對一長串可用技能，卻不知道該從哪裡開始時。skill-router 能把「我需要有人幫我處理 X」轉成「下一步請用這個具體技能」，降低進入門檻。

skill-router 只適合拿來做 Skill Discovery 嗎？

不是，但 skill-router for Skill Discovery 的確是它最強的使用情境之一。它也很適合當作團隊工作流程中的標準分流層，尤其是在大家是否熟悉技能目錄不是重點、而一致的第一步判斷更重要的情況下。

skill-router 和一般 prompt 有什麼不同？

一般 prompt 也可以要求模型推薦技能，但 skill-router 把這件事包裝成可重複使用、可觸發的技能，具備明確的啟動訊號、已知的技能目錄，以及釐清邏輯。這會讓分流步驟更一致，也更容易落地到實際流程中。

什麼情況應該跳過 skill-router？

以下情況可以跳過：

• 你已經知道正確的專門技能是什麼
• 你的環境裡技能很少
• skill-router 內的目錄沒有反映你實際安裝的技能集合
• 你想立刻直接執行，而且任務幾乎沒有歧義

skill-router 在客製化技能生態系裡好用嗎？

可以，但前提是你有持續讓目錄和真實技能保持一致。router 的價值來自準確映射；在高度客製化環境裡，目錄內容過時會是最大的導入風險。

安裝 skill-router 值得嗎？

通常值得，尤其是多人共用同一套技能庫，或使用者經常提出寬泛、定義不足的問題時。如果你的技能使用情境偏個人、頻率不高，而且你本來就很清楚怎麼選技能，那安裝它可能屬於可選，而不是必備。

如何改進 skill-router 技能

給 skill-router 更明確的分流訊號

想最快改善 skill-router 的結果，最直接的方法就是提供更好的第一輪輸入，包含：

• 任務類型
• 目標產物或對象
• 想達成的結果
• 限制條件，例如語言、repo 區域或 deadline

例如，「我需要處理 packages/api 裡一個失敗的 CI test，想先找出 root cause」會比「有東西壞掉了」更容易被正確分流。

回答釐清問題時，要給決策層級的細節

當 skill-router 問後續問題時，不要只回答像「就幫我改善一下」這種籠統說法。更好的回答應該指出你想改善的是什麼：correctness、readability、docs quality、UX fidelity、test coverage，還是 release readiness。這些差異會直接改變該選哪個技能。

維持 skill-router 的技能目錄為最新狀態

skill-router 最大的結構性改進點，就是技能目錄維護。如果 repository 新增、移除，或重新命名了下游技能，就要盡快更新 router。router 能有多好，取決於它知道哪些可選項。

為 skill-router 加上更強的去歧義規則

最常見的失敗模式，是相鄰技能類別彼此重疊，例如 debugging vs refactoring，或 documentation vs review。要改進 skill-router，可以強化區分這些情況的判斷線索：

• diagnosis 與 code improvement 的差異
• review 與 generation 的差異
• design interpretation 與 implementation planning 的差異

為真實的模糊請求補上更多範例

這個技能已經提供直接與模糊兩類範例。若想更容易推動採用，建議再增加一些更貼近日常內部請求的例子，例如：

• release prep
• root cause 未知的 failing CI
• 「把這個 PR 弄到 ready」
• 把 design files 轉成 implementation tasks

這類範例能幫助使用者學會怎麼表達需求，進而得到更乾淨的分流結果。

利用分流紀錄持續修 skill-router

因為 skill-router 會透過 session-logger 記錄分流決策，如果你拿得到這些 logs，值得定期回頭檢查。特別要找：

• 一直重複出現的釐清循環
• 經常被分錯類的請求
• 常見但沒有明確對應技能的意圖

這個回饋迴路，是長期改善 skill-router 最實際的方法之一。

第一次推薦不夠準時，繼續迭代 skill-router 輸入

如果第一個推薦看起來接近，但又不是很對，不要立刻放棄這個技能。改用補齊缺漏上下文的方式重述任務：

• 產物到底是什麼？
• 你需要的是 diagnosis、review、generation 還是 restructuring？
• 什麼結果才算成功？

很多時候，第二輪就能把原本偏廣的推薦，收斂成正確的專門技能交接。

用一條簡單規則提升團隊採用 skill-router

一條很好用的操作原則是：只要使用者的請求重點是「找出該用哪種協助」，而不是「直接執行一項已明確定義的工作」，就先用 skill-router。這樣能讓 router 專注在最有價值的 triage 場景，而不是被硬塞進每一條工作流程。