一個把問題轉成委派簡報的技能。
baton-skill-factory 是一個開源專案,目標是把可重複的 AI 協作流程封裝成「有版本、可安裝、可稽核」的技能。它目前只收錄一個技能:fable-codex-brief。這個技能的職責很窄——把一個 bug、需求、調查結果,或另一個 AI 的失敗輸出,轉成一份結構化的 Fable 5 任務簡報。它本身不解題,而是產出「該怎麼分工去解」的文件。
技能的核心是一條分工原則,直接寫在 SKILL.md 裡:Fable 5 負責規劃、協調、判斷與最終驗收;調查、實作、審查這類機械性、重複性、耗 token 的工作,則委派給 Codex。簡報不會替 Fable 5 做決定,而是把每一項要交給 Codex 的工作,都寫清楚範疇、目標與預期回傳格式,讓 Fable 5 的判斷力不被瑣事稀釋。
產出的簡報有固定六段:Problem(問題)、Fable 5 Role(角色定位)、委派調查、委派實作與審查、Review and Acceptance(驗收)、Expected Fable 5 Output(預期產出)。缺少的細節不會被編造,而是列在「Open Questions / Placeholders」等你補齊。技能預設不會自動觸發,只在你明確要求時才產生簡報。
Problem
Fable 5 Role
Delegate
Review
Accept
「You are responsible for planning, coordination, judgment, and final acceptance. Do not spend Fable 5 tokens on broad repo exploration, mechanical implementation, or routine review if that work can be scoped and delegated.」
Clone, 複製一個資料夾就完成。
技能就是純文字檔——一個 SKILL.md 加上 agents/openai.yaml。安裝方式是把整個技能資料夾複製到你的工具技能目錄,然後重啟 session。從 README 抄下來的兩行如下:
# 1 · clone 整個 skill factory
git clone https://github.com/VicZhang6/baton-skill-factory.git
# 2 · 把技能複製到你的技能目錄,然後重啟 session
cp -R baton-skill-factory/skills/fable-codex-brief ~/.codex/skills/怎麼呼叫它
安裝後,用 $fable-codex-brief 前綴明確呼叫,把要轉換的內容貼在後面。README 給的範例是:
$fable-codex-brief Turn this bug report into a Fable 5 task brief:
# [ 把你的 bug / 需求 / 失敗輸出貼在這裡 ]簡報把工作, 交給這幾條指令。
簡報不會自己執行任何事。它把每一項要交出去的工作,對應到一條 Codex 指令。SKILL.md 引用的這幾條 /codex:* 指令構成委派的骨架:調查與實作走 rescue,唯讀審查走 review,有風險的設計決定走 adversarial-review,背景工作再用 status、result、cancel 管理。每一次委派都必須寫清楚三件事:範疇、目標、預期回傳格式。
Delegate · 01
/codex:rescue
範疇執行
界定範疇的調查或實作:找相關檔案與程式路徑、追根因、查測試或建置為何失敗,以及修正、重構、補測試。
Delegate · 02
/codex:review
唯讀審查
只讀不改的程式審查。回報發現,不動 code——適合把一段 diff 交給 Codex 看第二眼。
Delegate · 03
/codex:adversarial-review
對抗審查
針對有風險的設計選擇提出質疑。合併前先挑戰假設,而不是被動接受。
Manage · 04
/codex:status
工作狀態
查詢背景 Codex 工作的目前進度,不必守著等它跑完。
Manage · 05
/codex:result
取回結果
取回已完成 Codex 工作的產出,交回 Fable 5 做驗收判斷。
Manage · 06
/codex:cancel
取消工作
中止進行中的背景 Codex 工作,例如範疇判斷有誤、需要重新委派時。
該用哪條委派?一張表決定
| 這項工作是什麼 | 委派指令 | 會不會動 code |
|---|---|---|
| 找檔案 / 追根因 / 查建置失敗 | /codex:rescue | 否(調查) |
| 修 bug / 重構 / 補測試 | /codex:rescue | 是(範疇內) |
| 看一段 diff、只要意見 | /codex:review | 否(唯讀) |
| 有風險的變更、合併前要挑戰 | /codex:adversarial-review | 否(質疑) |
簡報之所以可靠的八條規則。
以下八條全部出自專案文件,不是社群傳聞。前三條是 baton-skill-factory 對「一個技能該長什麼樣」的設計原則,後五條是 fable-codex-brief 的 SKILL.md 對簡報品質與角色分工立下的硬規則。理解這些,你才會知道簡報為什麼刻意不替你做決定。
原則 · 範疇單一,只做一件事
技能被設計成「scoped」——聚焦把一件事做好。fable-codex-brief 只產出簡報,不投入調查或實作,輸出因此可預期。
來源 · README 設計原則
原則 · 可稽核:純文字呈現
技能以純文字呈現,方便直接審閱。簡報本身就是一份可讀、可改、可版本控管的文件,而不是黑箱流程。
來源 · README 設計原則
原則 · 必須明確呼叫,不隱式啟動
塑造工作流程的技能刻意「manual when appropriate」。設定檔明訂 allow_implicit_invocation: false,避免自動觸發劫持對話。
來源 · agents/openai.yaml
守則 04 · 不編造事實與路徑
不虛構 repository 事實或使用者沒提供的檔案路徑。細節不足時,列在「Open Questions / Placeholders」等你補齊,而不是猜。
來源 · SKILL.md
守則 05 · 每次委派都寫三要素
每一項交給 Codex 的工作,都必須界定範疇(scope)、目標(goal)與預期回傳格式(expected return format)。含糊的委派不算數。
來源 · SKILL.md
守則 06 · Fable 5 擁有計畫
「Fable 5 owns the plan; Codex executes scoped work.」除非明確要求,Codex 不得自行制定整體計畫或做產品、架構決定。
來源 · SKILL.md
守則 07 · 風險變更先對抗審查
有風險的實作要在合併前跑 /codex:adversarial-review,讓 Codex 挑戰設計選擇,而不是直接放行。
來源 · SKILL.md
守則 08 · 驗收時檢查範疇
Review and Acceptance 階段要確認 Codex 有守住範疇、達成目標、用了安全做法,且沒有做未經授權的決定,再由 Fable 5 拍板。
來源 · SKILL.md
看一份 bug 回報怎麼變成委派簡報。
以下是一段情境示意:你手上有一個瀏覽器相容性的 bug,細節還不完整。你用 $fable-codex-brief 把它轉成一份 Fable 5 任務簡報。注意輸出並不急著解題——它先把問題結構化、界定 Fable 5 與 Codex 的分工,並在資訊不足處留下 placeholder,而不是編造。
$ You › $fable-codex-brief
Turn this into a Fable 5 task brief:
登入頁在 Safari 提交後一直轉圈、不跳轉,Chrome 正常。
上週開始出現,影響部分用戶登入。
claude: Fable 5 Task Brief ›
hl: 1 · Problem
· 觀察到:Safari 上送出登入後停在載入狀態,不導向。
· 預期:登入成功後導向 dashboard,與 Chrome 一致。
· 影響:部分用戶無法登入;上週開始。
hl: 2 · Fable 5 Role
保留規劃、協調、判斷與最終驗收。
不投入廣泛 repo 探索與機械性修改——交給 Codex。
hl: 3 · Delegate Investigation → /codex:rescue
scope : 登入提交到導向的前端流程 + 認證回呼
goal : 定位 Safari 卡住的根因(事件 / cookie / 導向)
return : 根因假設 + 相關檔案清單 + 重現步驟
hl: 4 · Delegate Implementation → /codex:rescue
scope : 僅修正確認後的根因,不擴大重構
goal : Safari 登入導向正常,並補一條 regression test
return : diff + 測試結果
hl: 5 · Review and Acceptance
確認 Codex 守住範疇、達成目標、未做未授權決定,
由 Fable 5 判斷是否驗收。
hl: 6 · Expected Fable 5 Output
最終診斷 · 已建立的 Codex 任務 · 審過的結果 ·
決策與風險 · 下一步。
ok: [brief ready · 貼給 Fable 5 即可開始執行]
「Codex must not invent the overall plan or make product or architecture decisions unless explicitly asked. Fable 5 owns the plan; Codex executes scoped work.」
這份簡報為什麼值得拆解
技能沒有替你除錯,而是把一段模糊的 bug 敘述,拆成 Fable 5 能直接執行的分工文件。資訊不足的地方變成 placeholder,而不是被編造的檔名或版本號——這正是 SKILL.md「不虛構 repository 事實或使用者沒提供的路徑」的規則在起作用。
每一項委派都寫清楚 scope / goal / return 三要素,調查與實作分開委派,觸及認證核心的改動還會先走對抗審查。你省下的不是一個工程師,而是把判斷力集中在真正該由你決定的地方——規劃與驗收。
知道邊界, 再把它放進流程。
把它改成你團隊的委派範本。
最實用的事實:技能就是純文字。SKILL.md 與 agents/openai.yaml 都可以直接打開來改,不需要寫 code。以下是幾條可行的下一步。
進階玩法地圖
**1. 客製簡報段落。**打開 skills/fable-codex-brief/SKILL.md,在六段結構裡加你團隊要求的欄位——例如每份簡報都要附「回滾方案」或「受影響服務」。下次產出的簡報就會帶上。
**2. 對接你自己的 Codex 執行層。**簡報委派到 /codex:rescue、/codex:review、/codex:adversarial-review。先確認這些指令在你的環境可用,簡報才能從「計畫」變成「執行」。
3. 調整呼叫介面。agents/openai.yaml 定義了 display name、short description 與 default prompt。改這裡可以換成你團隊習慣的觸發語,並維持 allow_implicit_invocation: false 的明確呼叫原則。
**4. 依 factory 原則加你自己的技能。**baton-skill-factory 的設計原則是 practical / reusable / scoped / auditable。把你團隊重複的協作流程,照同樣格式封裝成新的 skills/<name>/,就能沿用同一套安裝與稽核方式。
最該讀的幾份延伸閱讀
① skills/fable-codex-brief/SKILL.md——簡報六段結構、委派規則與角色分工的完整定義。 ② README.md(另有 README.zh-CN.md)——專案理念、設計原則與安裝步驟。 ③ agents/openai.yaml——呼叫介面與明確呼叫政策。
Practical, reusable, scoped, auditable— and manual when the tool shapes your workflow.