fable-codex-brief 是 baton-skill-factory 收錄的第一個開源技能。它把一個 bug、需求或另一個 AI 的失敗輸出,轉成結構化的 Fable 5 任務簡報:Fable 5 保留規劃、判斷與最終驗收,把調查與實作等耗 token 的範疇工作委派給 Codex。這份手冊涵蓋安裝、六段簡報結構、委派指令與一則完整使用實例。
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」等你補齊。技能預設不會自動觸發,只在你明確要求時才產生簡報。
技能就是純文字檔——一個 SKILL.md 加上 agents/openai.yaml。安裝方式是把整個技能資料夾複製到你的工具技能目錄,然後重啟 session。從 README 抄下來的兩行如下:
安裝後,用 $fable-codex-brief 前綴明確呼叫,把要轉換的內容貼在後面。README 給的範例是:
agents/openai.yaml 明確設定 allow_implicit_invocation: false——這是刻意的。塑造工作流程的技能若隱式啟動,容易在你只想閒聊或快速修一行時劫持整段對話。所以你必須主動打出 $fable-codex-brief 才會產生簡報。
簡報不會自己執行任何事。它把每一項要交出去的工作,對應到一條 Codex 指令。SKILL.md 引用的這幾條 /codex:* 指令構成委派的骨架:調查與實作走 rescue,唯讀審查走 review,有風險的設計決定走 adversarial-review,背景工作再用 status、result、cancel 管理。每一次委派都必須寫清楚三件事:範疇、目標、預期回傳格式。
| 這項工作是什麼 | 委派指令 | 會不會動 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,避免自動觸發劫持對話。
不虛構 repository 事實或使用者沒提供的檔案路徑。細節不足時,列在「Open Questions / Placeholders」等你補齊,而不是猜。
來源 · SKILL.md每一項交給 Codex 的工作,都必須界定範疇(scope)、目標(goal)與預期回傳格式(expected return format)。含糊的委派不算數。
來源 · SKILL.md「Fable 5 owns the plan; Codex executes scoped work.」除非明確要求,Codex 不得自行制定整體計畫或做產品、架構決定。
來源 · SKILL.md有風險的實作要在合併前跑 /codex:adversarial-review,讓 Codex 挑戰設計選擇,而不是直接放行。
Review and Acceptance 階段要確認 Codex 有守住範疇、達成目標、用了安全做法,且沒有做未經授權的決定,再由 Fable 5 拍板。
來源 · SKILL.md
以下是一段情境示意:你手上有一個瀏覽器相容性的 bug,細節還不完整。你用 $fable-codex-brief 把它轉成一份 Fable 5 任務簡報。注意輸出並不急著解題——它先把問題結構化、界定 Fable 5 與 Codex 的分工,並在資訊不足處留下 placeholder,而不是編造。
技能沒有替你除錯,而是把一段模糊的 bug 敘述,拆成 Fable 5 能直接執行的分工文件。資訊不足的地方變成 placeholder,而不是被編造的檔名或版本號——這正是 SKILL.md「不虛構 repository 事實或使用者沒提供的路徑」的規則在起作用。
每一項委派都寫清楚 scope / goal / return 三要素,調查與實作分開委派,觸及認證核心的改動還會先走對抗審查。你省下的不是一個工程師,而是把判斷力集中在真正該由你決定的地方——規劃與驗收。
allow_implicit_invocation: false 是設計,不是限制。你必須主動打 $fable-codex-brief;它不會在你隨口描述問題時自動生成簡報。
/codex:rescue、/codex:review、/codex:adversarial-review 等指令。你的環境要真的接了對應的 Codex 執行層,簡報才跑得起來,否則它只是一份計畫。
最實用的事實:技能就是純文字。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——呼叫介面與明確呼叫政策。