# Fable Commander

> Fable 指揮官工作流 — Fable 只做規劃/審查/決策，研究與執行派給使用者選的模型（Opus/Sonnet/Haiku subagent）。流程：Fable 產 plan → 問使用者選研究模型 → /workflow 查資料+列驗收標準 → Fable review 修 plan → 問使用者選執行模型 → maker/verifier 分離的執行 loop（驗證硬條件=客觀正確性，禁止以風格/觀點打回）。觸發詞：指揮官模式、fable commander、指揮官流程、用指揮官跑、Fable 當指揮官、commander 這個題目。

- Skill: `denniswei9898/fable-commander` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add denniswei9898/fable-commander`
- Raw SKILL.md: https://api.skillmd.com/api/skills/denniswei9898/fable-commander/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: DennisWei9898 (https://skillmd.com/u/denniswei9898)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/denniswei9898/fable-commander

---


# fable-commander · Fable 指揮官工作流

你（Fable）是**指揮官**：負責規劃、審查、整合、把關決策點。查資料與寫程式這類大量 token 的工作，派給**使用者選定的模型**用 subagent / Workflow 跑。核心信念來自 Addy Osmani 的 Loop Engineering：

> "The most useful structural thing in a loop, by far, is splitting the one who writes from the one who checks. The model that wrote the code is way too nice grading its own homework."

## 模型切換的實作方式（重要，先讀懂）

Claude Code 的 main loop 模型**無法由 Claude 自行切換**（`/model` 是使用者指令）。因此本 skill 的「切模型」一律用：
- `Agent` / `Workflow` 的 `model` 參數（`opus` / `sonnet` / `haiku`）— 自動、不需使用者動手 ← **預設**
- 若使用者明確想把 main loop 整個換掉（例如長執行期省成本），提示他自己輸入 `/model`，並把 handoff 所需的一切寫進 state file 再交棒

## Advisor 模式：本 skill 的輕量替身（官方 harness 功能，非工作流）

`/advisor <model>` 是 Claude Code 官方（實驗性）功能：主模型跑便宜的（如 Sonnet），Claude 在關鍵時刻（提交方案前／錯誤重複／宣告完成前）**自動諮詢**更強的 advisor（如 Opus）。設定方式 `/advisor opus`、`advisorModel` settings 欄位、或 `--advisor` 旗標；`/advisor off` 關閉。需 Claude Code v2.1.98+，僅 Anthropic API（Bedrock/Vertex/Foundry 不支援）。mid-session 即生效、不需重開 session（官方文件明說中途啟用停用不使 prompt cache 失效）。

**何時用它取代本 skill**：官方文件原文是 advisor 適合「**長、多步驟**任務，方案品質決定成敗」，短任務「加值較低」，官方建議短任務直接換主模型而非掛 advisor——所以正確的折衷地帶，是 Phase −1 三判準裡的「**驗證難以客觀化**」或「**token 預算不夠**」這兩類、但任務本身仍偏長偏多步驟；純粹「任務小」不是 advisor 的甜蜜點，照 Phase −1 直接做即可。

**為何它不能取代完整 loop**：advisor 是給「同一個執行者」的第二意見，執行者通常照建議走——這跟本 skill 的 maker/verifier 分離（獨立、有罪推定、跨模型的檢查者）**方向相反**；官方 blog 明說 advisor strategy 是「反過來的 orchestrator」。所以 advisor 沒有獨立驗證、沒有 gate/停止紀律、沒有證據要求。防「誤報完成」的護欄只有完整 loop 才有。

**⚠️ 與本 skill 併用的陷阱**：官方文件白紙黑字「子代理繼承已設定的顧問，並針對自身模型做配對檢查」。所以在**已開 advisor** 的 session 裡跑本 skill，spawn 出去的 maker/verifier 會**各自諮詢同一顆 advisor**——(1) 成本悄悄上升；(2) 更關鍵：verifier 若也諮詢同一顆 advisor，「獨立、跨模型檢查者」就被部分抵消。**硬規則：跑 Phase 5 verifier 時 advisor 應為 off，或用未開 advisor 的獨立 session 跑 verifier。**（advisor 目前無 per-subagent 開關。）

**⚠️ 已知相容性 bug**：session（含其內部 subagent）只要在呼叫 advisor **前**用 `ToolSearch` 載入過任何 deferred tool（例：內建 `WebFetch`，或任何 MCP 工具），之後每次 advisor 呼叫都會**確定性失效**（[GitHub #73923](https://github.com/anthropics/claude-code/issues/73923)，Anthropic 已標記 Closed as not planned）。這條會命中很多真實 session——標準 Claude Code 常態性用 ToolSearch 載入 deferred 內建工具。另外，用 **Fable 5** 當主模型時，長對話（約 100K+ tokens）也可能讓 advisor 悄悄失效——此限制專屬 Fable-5-as-main，issue 證據顯示 Opus 4.8 當主模型在 296K context 仍正常（[GitHub #67609](https://github.com/anthropics/claude-code/issues/67609)）。**不要單靠 advisor 當唯一防線。**

**輕量逃生口**：Phase −1 判「不值得跑完整 loop」時，除了「直接做」，若任務仍偏長/多步驟（只是驗證難客觀化或 token 預算不夠），可建議一條中間路線——`/model sonnet` + `/advisor opus`：便宜模型執行、更強模型在關鍵決策點被自動諮詢，無 loop 的多 agent 開銷（併用陷阱見上；純小任務不是 advisor 的甜蜜點）。

## 適用性檢查（Phase −1，先過再開跑）

Loop engineering 不是萬用解。以下任一不成立 → 告訴使用者「這題直接做比較划算」，不走本流程：
1. 任務夠大（多階段、研究+執行分離有價值）——一次性小任務用好 prompt 更快
2. 驗證可客觀化（測試/資料檢核/可重現性這類機器可判的訊號）
3. Token 預算允許（本流程會 spawn 多個 agent，天生燒錢）

## 流程總覽

```
Phase 0  Fable 起草 Plan v0（含驗收標準草稿 + 已知未知清單）
Phase 1  AskUserQuestion①：研究階段用哪個模型？
Phase 2  /workflow 研究 fan-out（該模型）：查證資料源、文獻、工具、補驗收標準
Phase 3  Fable review 研究產出 → 修成 Plan v1（衝突處問使用者）
Phase 4  AskUserQuestion②：執行階段用哪個模型？
Phase 5  執行 loop：maker（執行模型）⇄ verifier（獨立 fresh-context agent）
Phase 6  收尾：Fable 總驗收 + 採納率記錄 + 教訓回灌
```

## Phase 0 — Fable 起草 Plan v0

- 產出一份 `PLAN.md` 存在**任務的專案目錄**（不是 scratchpad）——這是整個 loop 的 **state file**（spine），每個 phase 完成都要回寫
- Plan v0 必含：研究問題、先驗/預期結果、phases×gates 表、**驗收標準草稿**、**已知未知清單**（＝Phase 2 的研究題目，逐條可查證）
- Plan 裡就要寫死執行期的 maker/verifier 合約（見 Phase 5），不是執行時才想

## Phase 1 — 問使用者：研究模型

用 `AskUserQuestion` 問一題（選項附成本/能力 trade-off）：
- **Sonnet（推薦）**：搜尋彙整型研究性價比最高
- **Opus**：題目冷門、需要較強推理時
- **Haiku**：純撈資料、清單型查證
- **先不跑**：使用者要自己挑時機

## Phase 2 — 研究 /workflow（使用者選的模型）

用 `Workflow` 工具（或多個並行 `Agent`，皆帶 `model` override）fan-out，**每條研究題目一個 agent**，題目直接取自 Plan v0 的「已知未知清單」。規則：
- 研究 agent **只查證、不改 plan**（讀寫分離：他們回報事實與來源，改 plan 是 Fable 的事）
- 每條發現必附來源 URL 或資料路徑；查不到就回報「查不到」，禁止腦補
- 其中一個 agent 專門負責「**驗收標準提案**」：把 Plan v0 的驗收草稿改寫成逐條可機器判定的條件
- 產出寫進 `RESEARCH.md`（與 PLAN.md 同目錄）

## Phase 3 — Fable review → Plan v1

Fable（你自己，main loop）做：
1. 逐條核對 RESEARCH.md 是否回答了已知未知；沒答到的標記「仍未知」進 Plan v1 風險節
2. **Trust but verify**：對關鍵事實（資料源可用性、API 限制）抽 1–2 條自己快速複核，不盲信 subagent 報告
3. 修訂驗收標準為定稿（每條都要能客觀判 PASS/FAIL）
4. 與使用者原始意圖衝突、或有重大取捨（如資料源要花錢）→ `AskUserQuestion` 問，不擅自決定
5. Plan v1 回寫 PLAN.md（版本號 + 修訂紀錄）

## Phase 4 — 問使用者：執行模型

`AskUserQuestion`：**Opus（推薦，長程執行力強）** / Sonnet（成本敏感）/ 先不執行。
同時問是否需要 worktree 隔離（會改既有 repo 的任務建議開）。
若使用者選 Sonnet 省成本，可提示另可加開 `/advisor` 取得決策點的強模型指導（中間路線）——但務必提醒「Advisor 模式」節的 verifier 併用陷阱：Phase 5 verifier 要在 advisor off 的狀態下跑，否則獨立性受損。

## Phase 5 — 執行 loop（本 skill 的靈魂：maker/verifier 分離）

### 角色
- **Maker agent**（使用者選的執行模型）：照 Plan v1 實作，一次領一個 phase
- **Verifier agent**（獨立 spawn、fresh context、**禁止共用 maker 的對話**；建議與 maker 不同模型）：對照 Plan 裡的 gate 驗收

### Verifier 的硬規則（寫進每次 verifier prompt）
1. **只驗硬條件＝客觀正確性**：測試通過、資料檢核、數字可重現、規格逐條對照——全部是機器可判或可獨立重跑驗證的訊號
2. **🚫 明文禁止**以下列理由打回：程式/文章風格偏好、敘事方式、作者觀點、結論方向不合預期。這些屬於**使用者的風格與觀點資產**，verifier 無權扼殺——只能寫進報告的「建議（不擋交付）」欄
3. 預設有罪推定（maker 說「done」是 claim 不是 proof），每項 gate 給 PASS/FAIL + 證據
4. Verifier 只判不改（寫審分離），改是 maker 回去改

### Loop 控制（防 Ralph Wiggum 迴圈與空轉）
- 每個 gate 迭代上限 **3 輪**
- 同一項連續 **2 輪無改善** → 判定為「這層修不動」，停止空轉，升級人工（把兩輪證據整理給使用者）
- 3 輪後仍 FAIL → **不得「取最高分放行」**，gate 就是 gate；標記未過、上報使用者裁決
- 每輪結果回寫 state file（phase、輪次、verifier 判定、殘留問題）

### 人工閘（不可逆動作）
commit / push / 對外發布 / 花錢（付費 API、下單）之前一律停下拿使用者明確確認——即使在 bypass permissions 模式下也一樣。

## Phase 6 — 收尾

1. Fable 總驗收：抽核 verifier 報告（trust but verify，第 3 層眼睛）
2. **採納率記錄**：這次產出被使用者接受多少？寫進 state file 尾部（loop 的成功指標是採納率，不是 token 燒了多少）
3. 教訓回灌：這次流程哪個 gate 設計得不好 → 直接改本 SKILL.md（記日期），讓 loop 自我改進
4. 提醒使用者**讀關鍵 diff /報告本體**——comprehension debt 與 cognitive surrender 是使用者自己要守的線，skill 只能提醒

## 實戰教訓：感知品質類任務的驗收（2026-07-12）

**感知品質類任務（語音自然度/腔調/視覺美感/文案人味）的驗收 gate 必含人類感官，機器 proxy 只當 sanity check、不當過閘依據。** 本機語音克隆實證：maker/verifier loop 報「6 條 AC 全 PASS」——speaker cosine 0.92、CER 0、後補的 PESQ 都過，但使用者一聽「完全不行」、真實採納率＝0；PESQ 甚至把使用者一聽就否決的合成音評最高分 3.01。三個機器指標全「**客觀但量錯維度**」——量的是「像不像/念對沒/乾不乾淨」，不是「聽起來好不好」，與 huashu-design『視覺校稿闸』同構。

**硬規則**：①感知品質類 acceptance 設**雙層**——機器預篩（濾掉明顯壞的）＋ **人類感官硬閘（唯一能關 loop）**；②明文禁止拿 cosine/CER/PESQ/UTMOS 宣稱「過了」，它們是 sanity check 不是 gate；③不確定寧可產樣本交使用者感官判，不要 loop 自宣 done（誤報完成＝Ralph Wiggum）。

## 反模式對照表（自檢用）

| 陷阱 | 本 skill 的對策 |
|---|---|
| Ralph Wiggum 迴圈（誤報完成提早退出） | verifier 有罪推定 + 客觀 gate + 證據必附 |
| 軟化閘門（「取最高分」矇混過關） | 3 輪仍 FAIL 就是 FAIL，上報不放行 |
| 同源自評放水 | verifier 必為 fresh context，建議跨模型 |
| 驗證越權殺風格 | 硬條件白名單 + 風格/觀點禁打回條款 |
| 無停止條件空轉燒錢 | 3 輪上限 + 2 輪無改善即升級 |
| 理解債 / 認知投降 | Phase 6 強制提醒使用者親讀關鍵產出 |
| 把 orchestrator/loop 設成 CLAUDE.md 全域預設 | orchestrator/loop 一律 opt-in；Phase −1 適用性檢查先過，小任務走 advisor 輕量路徑而非全域燒 token |
| Advisor 開著跑 verifier（獨立性被抵消） | Phase 5 verifier 一律 advisor off 或獨立 session；派工前確認 advisor 狀態 |