Codex Skills 越裝越多，怎麼讓它們真的協作？用 Workflow Skill Router 建立自己的 Skill Tree

當 Codex 裡只有兩三個 Skills 時，事情通常很單純。

你知道該用哪個 Skill，也知道下一步要做什麼。像是改一個函式、檢查一段程式碼，或做一個簡單頁面，直接指定 Skill 就能開始。

但當 Skills 越裝越多，問題就不再是「有沒有工具可以做」，而是：

這些 Skills 到底該怎麼分工、什麼時候使用、又該由誰先開始？

這也是我開發 Workflow Skill Router 的原因。

它不只是替 Codex 選擇 Skill，更重要的是讓你把自己的工作方式整理成一棵可重複使用的 Skill Tree，讓 Codex 在面對不同類型的任務時，能依照你定義的流程工作。

GitHub Repository：
https://github.com/eric861129/Workflow-skill-router

完整文件：
https://huangchiyu.com/Workflow-skill-router/

Blog：
https://huangchiyu.com/ChiYu-Blog/posts/workflow-skill-router-v2-runtime

先講結論：它不是每個人都需要

如果你目前只裝了一兩個 Skills，而且平常的工作大多像這樣：

• 解釋一段錯誤訊息
• 修改一個函式
• 寫一份文件
• 做一個簡單頁面
• 跑一次程式碼檢查

那你大多不需要 Workflow Skill Router。

例如：

使用 frontend-app-builder 建立一個登入頁面

或：

使用 security-scan 檢查這個 Repository

這類任務裡，使用者已經明確指定要用的 Skill，Codex 也不需要額外建立一套路由計畫。

硬要加上一層 Router，反而可能增加：

• 額外的任務分類
• 多一層路由判斷
• 更多 Context
• 不必要的流程說明
• 比實作本身還久的規劃時間

所以，Workflow Skill Router 不是「安裝 Codex 後一定要加上的套件」。

它比較適合另一種情況：你的 Skill 環境和工作流程，已經開始變複雜了。

什麼時候會開始需要它？

假設你的 Codex 環境裡已經有這些能力：

需求分析
系統設計
前端開發
後端開發
資料庫設計
測試規劃
安全掃描
GitHub 操作
CI/CD
文件撰寫
部署驗證

而你平常的工作，也不只是單點任務，而是像這樣一路串起來：

分析需求
  ↓
設計系統
  ↓
修改前後端
  ↓
執行測試
  ↓
安全檢查
  ↓
建立 Pull Request

這時候，常見的問題就會慢慢出現：

• Codex 不知道應該先使用哪一個 Skill。
• 一開始就載入太多其實還用不到的 Skills。
• 小任務被套進完整開發流程，變得太重。
• 不同 Skills 的責任範圍開始重疊。
• 同類型任務每次走的順序都不一樣。
• Agent 還沒測試，就想直接進入發布流程。
• 使用者明明指定了一個 Skill，Agent 卻自行換成別的能力。
• Skill 雖然存在，但目前 Host 不一定真的提供執行能力。

如果你已經開始遇到這些狀況，Workflow Skill Router 才會開始有價值。

Workflow Skill Router 想解決的，不是讓每一個任務變複雜。

相反地，它想做的是：

當你的 Skill 環境已經很複雜時，還是能讓每一次任務維持最小、清楚，而且可驗證的執行路徑。

它最重要的功能：建立自己的 Skill Tree

很多人第一次看到 Workflow Skill Router，會以為它只是自動幫 Codex 挑選 Skill。

這當然是其中一部分，但我認為更核心的價值是：

把你原本放在腦中的工作習慣，整理成 Codex 可以理解、可以重複執行的 Skill Tree。

每個工程師、每個團隊，其實都有自己習慣的做事方式。

例如，開發一支 API 時，我可能習慣這樣做：

先設計 API Contract
  ↓
再進行程式實作
  ↓
最後執行測試與驗證

但另一個團隊可能會要求：

需求分析
  ↓
資料權限檢查
  ↓
API Contract
  ↓
後端實作
  ↓
安全掃描
  ↓
Integration Test
  ↓
Pull Request Review

兩種流程都合理，差別只在於你希望怎麼交付。

問題是，一般 Agent 不會自動知道你的習慣。即使你已經裝好了所有相關 Skills，Codex 看到的可能仍只是一份清單：

api-designer
csharp-developer
qa-test-planner
playwright
security-scan
github

它知道這些能力存在，卻未必知道：

• 哪個 Skill 應該先做？
• 哪一個是這個階段的主要負責者？
• 哪些只是輔助？
• 什麼條件滿足後才能進到下一步？
• 哪些任務其實根本不需要完整流程？
• 使用者有沒有同意加入額外 Skills？

Skill Catalog 回答的是：

我有哪些 Skills？

Skill Tree 回答的則是：

面對這一類任務時，我希望這些 Skills 怎麼一起工作？

把工作方法畫成一棵樹

假設我想建立一套 API Delivery Workflow，可以先把它拆成三個階段：

API Delivery
│
├── Phase 1：Contract
│   ├── Primary：api-designer
│   ├── Support：api-guidelines-skill
│   └── Exit Gate：contract-reviewed
│
├── Phase 2：Implementation
│   ├── Primary：csharp-developer
│   ├── Support：無
│   └── Exit Gate：implementation-complete
│
└── Phase 3：Verification
    ├── Primary：qa-test-planner
    ├── Support：playwright
    └── Exit Gate：tests-passed

這棵 Tree 定義的不只是 Skill 名稱，而是整個協作方式：

• 工作分成哪些階段
• 各階段的順序
• 每個階段由誰主責
• 哪些 Skill 可以輔助
• 滿足什麼條件才能往下一階段走

因此，當使用者提出：

請幫我開發一支學生資料 API。

Router 不需要一開始就把 API 設計、C# 開發、Playwright、安全掃描與 GitHub 全部丟進 Context。

它可以先走：

Contract
  ↓
Implementation
  ↓
Verification

每個階段只帶入當下真正需要的能力。

每個 Phase 只需要一個 Primary Skill

在 Workflow Skill Router 裡，每一個 Phase 都應該有一個明確的 Primary Skill。

Primary Skill 的意思很單純：

目前這個階段，誰是主要負責完成工作的人？

以 API Contract 階段為例，api-designer 應該負責 Endpoint、Request、Response 與 Error Contract 的設計。

而 api-guidelines-skill 的角色比較像協作者，協助檢查命名、HTTP Method、Status Code 與格式規範；它不需要搶走整個階段的主導權。

這樣做，可以避免多個 Skills 同時主導同一件事，最後各自給出一套不同做法。

Supporting Skills 只在真的需要時加入

除了 Primary Skill，每個 Phase 也可以定義 Supporting Skills。

例如：

Contract
Primary：api-designer
Support：api-guidelines-skill

或：

Verification
Primary：qa-test-planner
Support：playwright

Supporting Skill 的目的，是補足目前階段需要的能力，而不是把所有「可能有用」的 Skill 都塞進來。

目前 Profile 會限制每個 Phase 最多設定三個立即使用的 Supporting Skills。這個限制其實很有用，因為如果一個階段同時需要六、七個輔助能力，通常代表那個 Phase 拆得還不夠清楚。

與其硬塞，不如把流程拆成更多階段。

Exit Gate：不是做過，而是真的完成

每個 Phase 還可以定義 Exit Gate。

Exit Gate 要回答的是：

什麼條件成立後，這個階段才算完成？

例如，Contract 階段不是產出一份 OpenAPI 文件就算結束。

contract-reviewed 可以代表：

• Endpoint 已定義
• Request Schema 已完成
• Response Schema 已完成
• Error Response 已完成
• Naming 與 HTTP Method 已檢查
• 沒有未處理的 Contract 問題

同樣地，tests-passed 也不只是「我有寫測試」。

它可能代表：

• Unit Tests 通過
• Integration Tests 通過
• 必要的 End-to-End Tests 通過
• 沒有阻止交付的錯誤

這樣 Agent 就不會因為「已經做了一些事」，便直接跳到下一階段。

將 Skill Tree 寫成 Personal Routing Profile

當流程想清楚後，就可以把它寫成一份 JSON Profile：

{
  "schema_id": "workflow-skill-router/routing-profile",
  "schema_version": "1.0.0",
  "artifact_kind": "routing-profile",
  "profile_id": "personal:api-delivery",
  "scope": "personal",
  "enabled": true,
  "rules": [
    {
      "rule_id": "api-delivery",
      "priority": 100,
      "match": {
        "objective_keywords": [
          "api",
          "應用程式介面",
          "openapi"
        ],
        "domains": [
          "api"
        ],
        "tags": [],
        "work_modes": []
      },
      "route": {
        "work_mode": "phased",
        "skill_tree": [
          {
            "phase_id": "contract",
            "primary_skill_id": "skill:api-designer",
            "support_skill_ids": [
              "skill:api-guidelines-skill"
            ],
            "exit_gate": "contract-reviewed"
          },
          {
            "phase_id": "implementation",
            "primary_skill_id": "skill:csharp-developer",
            "support_skill_ids": [],
            "exit_gate": "implementation-complete"
          },
          {
            "phase_id": "verification",
            "primary_skill_id": "skill:qa-test-planner",
            "support_skill_ids": [
              "skill:playwright"
            ],
            "exit_gate": "tests-passed"
          }
        ]
      }
    }
  ]
}

這份設定其實就是你的 Skill Tree。

它的意思是：

當任務和 API、OpenAPI 或「應用程式介面」有關，
而且 Domain 為 api 時：

採用 phased 工作模式。

第一階段設計 Contract。
第二階段進行實作。
第三階段完成驗證。

Personal Profile：把自己的習慣留下來

Personal Routing Profile 適合保存個人偏好的工作方法。

例如：

我做 API 時，習慣先設計 Contract，再實作，最後測試。

你可以用：

{
  "profile_id": "personal:api-delivery",
  "scope": "personal"
}

除了 API，也可以建立其他常用流程：

personal:frontend-feature
personal:security-review
personal:bug-fixing
personal:github-release
personal:technical-writing

例如 Bug Fix Workflow：

Reproduce
  ↓
Root Cause Analysis
  ↓
Implementation
  ↓
Regression Test

或 Security Fix Workflow：

Finding Discovery
  ↓
Finding Validation
  ↓
Fix
  ↓
Security Verification

這代表你不必每次都重新提醒 Codex：

先重現問題，找到 Root Cause 後再修；修完一定要做 Regression Test。

你可以把這套方法直接保存成可重複使用的路由規則。

Workspace Profile：把團隊流程放進專案裡

除了 Personal Profile，也可以在 Repository 裡建立 Workspace Profile：

.codex/workflow-skill-router.json

Workspace Profile 適合放團隊或專案共用的規範，例如：

• 專案的開發流程
• 團隊共同的測試要求
• 特定技術架構的 Skill 選擇
• 安全檢查與 Release 流程
• 不同類型任務的標準作業程序

例如校務系統專案可以有：

需求分析
  ↓
權限影響檢查
  ↓
後端開發
  ↓
前端開發
  ↓
Integration Test
  ↓
Security Review

Workspace Profile 可以設定為：

{
  "profile_id": "workspace:school-system-development",
  "scope": "workspace"
}

當 Personal Profile 和 Workspace Profile 同時符合時，優先順序大致是：

系統、安全與 Host 限制
  ↓
使用者目前明確指定的 Skill
  ↓
Workspace Profile
  ↓
Personal Profile
  ↓
Built-in Routing

換句話說，專案規範會高於個人的預設習慣；但使用者在當前任務中明確指定的 Skill，仍然有更高優先權。

另外，Router 不會隨意把 Personal Tree 和 Workspace Tree 混在一起，拼出一套沒有人真正定義過的流程。Workspace Profile 命中時，會採用完整的 Workspace Tree。

怎麼驗證自己的 Skill Tree？

建立 Profile 後，可以先驗證格式：

python plugins/workflow-skill-router/runtime/workflow_skill_router.pyz profile validate .\my-profile.json

接著執行 Lint：

python plugins/workflow-skill-router/runtime/workflow_skill_router.pyz profile lint .\my-profile.json

Lint 可以協助檢查：

• 重複的 Rule
• 永遠不會命中的 Rule
• Priority 與 Specificity 相同造成的衝突
• Primary Skill 同時出現在 Support 中
• Phased Workflow 裡不存在的 Phase

安裝前，也可以先預覽實際會怎麼路由：

python plugins/workflow-skill-router/runtime/workflow_skill_router.pyz profile preview `
  --objective "請幫我設計並開發一支學生資料 API" `
  --work-mode phased `
  --domain api `
  --explain

加上 --explain 後，你可以看到：

• Router 檢查了哪些 Rules
• 最後命中了哪一條 Rule
• 哪些條件符合
• 哪些條件沒有符合
• 為什麼最後選擇這條路由

確認沒問題後，再安裝 Profile：

python plugins/workflow-skill-router/runtime/workflow_skill_router.pyz profile install .\my-profile.json

查看目前已安裝的 Profiles：

python plugins/workflow-skill-router/runtime/workflow_skill_router.pyz profile list

Skill Tree 定義的是工作意圖，不是執行權限

這一點很重要。

建立一棵 Skill Tree，代表的是：

我希望遇到這類任務時，按照這個流程處理。

它不代表：

這些 Skills 現在一定存在，而且一定可以執行。

Profile 命中後，結果仍可能是：

intended-unverified

Runtime Capability Discovery 還會確認：

• Skill 是否已安裝
• Host 是否真的暴露該能力
• 版本是否相容
• Authentication 是否完成
• Policy 是否允許
• Runtime 資訊是否仍然有效

假設你的 Skill Tree 指定：

skill:playwright

但目前環境裡沒有 Playwright Skill，Router 不應該偷偷換成別的測試 Skill。

它應該保留原本的工作意圖，並清楚告訴你：

Intended Skill：playwright
Runtime Status：Unavailable

Personal Routing Profile 負責定義「你想怎麼工作」；Runtime Capability Discovery 則確認「你現在能不能這樣工作」。

它不是單純的 Skill Selector

所以，我不會只把 Workflow Skill Router 定義為：

一個幫 Codex 自動選擇 Skill 的工具。

更完整的說法是：

一個讓你建立自己的 Skill Tree，並在 Runtime 中選擇最小、可驗證執行路徑的工作流路由層。

它主要處理三件事。

第一層：我想怎麼工作？

透過 Personal Profile 與 Workspace Profile，定義自己的 Skill Tree。

分析
  ↓
設計
  ↓
開發
  ↓
測試

第二層：現在該做哪一個階段？

Router 不會一次載入整棵 Tree，而是根據目前 Phase，只規劃當下需要的 Primary 與 Supporting Skills。

第三層：這些能力現在真的能用嗎？

由 Runtime Capability Discovery 確認 Skill 是否存在、是否被 Host 暴露，以及是否符合目前的權限與政策限制。

這樣能避免兩種極端：

裝了很多 Skills，但每次都不知道該用哪一個。

以及：

不管什麼任務，都套用同一套巨大工作流。

Workflow Skill Router 想走的是中間那條路：

保留你自己的工作方法，同時讓每個階段只啟用真正需要的能力。

哪些人最值得試試看？

如果你的情況是：

只有一兩個 Skills
每次都是單一任務
通常會直接指定 Skill
沒有固定的多階段工作流程

那你現在不一定需要 Workflow Skill Router。直接使用原本的 Skills，反而更簡單。

但如果你的情況是：

已經安裝許多不同用途的 Skills
經常需要多個 Skills 協作
有固定的開發、測試、Review 或發布流程
希望每次都按照一致的階段執行
希望保存自己的工程方法
希望團隊共用一套 AI 工作流
開始遇到 Skill 過度載入或選擇混亂

那就很適合試著導入 Workflow Skill Router。

尤其當你開始有這個感覺時：

我不是缺少 Skill，而是不知道這些 Skills 應該怎麼一起工作。

這就是 Router 最適合介入的時機。

結語：從安裝 Skills，走向設計工作流

當 Codex Skills 還不多時，我們在意的是：

有沒有一個 Skill 可以完成這件事？

但當 Skills 越來越多，問題會慢慢變成：

這些 Skills 該怎麼分工？
誰要先做？
什麼時候才能進到下一個階段？
哪些能力現在真的可以使用？

Workflow Skill Router 的目的，不是鼓勵大家安裝更多 Skills，也不是要把每一件小事都變成複雜流程。

它真正想提供的是：

當你的工作本來就需要多種 Skills 時，讓你能把自己的工程方法定義成一棵 Skill Tree，並讓 Codex 按照這套工作流協作。

如果你的 Skill 環境還很簡單，就不必為了嘗試新工具而硬裝。

但如果你已經在使用很多 Skills，也希望它們能更穩定、更清楚、更符合自己或團隊的習慣一起工作，歡迎試試看 Workflow Skill Router。

GitHub Repository：
https://github.com/eric861129/Workflow-skill-router

完整文件：
https://huangchiyu.com/Workflow-skill-router/

我最想收到的回饋，也不只是 GitHub Star。

更想知道的是：

你平常會使用哪些 Skills？
如果把你的工作方式畫成一棵 Skill Tree，它會長什麼樣子？