剛剛 last30days 收斂出來的 Fable 5 建議，核心是這幾條：
不要拿 Fable 5 做普通 chat 或機械任務
用在判斷密集工作：架構、策略、migration plan、pre-mortem、root-cause、複雜決策、工作方法論診斷。

Fable 做 architect，不做 builder
最佳模式是：
Fable = frame / plan / decompose / review
Codex / Sonnet / cheaper model = implement / test / cleanup
另一個模型 = verifier

先給真實上下文，再問它該做什麼
不要問「Fable 可以幹嘛」。要給它你的 repo、目標、限制、目前卡點，然後問：
「這裡最高槓桿的 3 個問題是什麼？哪個值得我花 Fable 成本解？」

問題發現跟問題解決分開
先用便宜模型列出各專案最難、最有價值的技術/營運問題，再挑最重要的交給 Fable 解。這是 Aniket 那條 playbook 裡最值得吸收的點。

Prompt 寫 outcome，不寫 step-by-step
給它：
目標
成功條件
限制
stop condition
approval gate
可用 artifacts
少給「第一步做 X、第二步做 Y」這種弱模型 scaffold。

每次 Fable run 都要有 budget / stop rule
因為它很貴，也可能一直鑽。每次都要先定：
最多花多久
最多看哪些檔
產出格式
什麼情況停止
什麼情況交給 cheaper model

注意 safety reroute / fallback
有些請求可能被擋或轉給 Opus 4.8，所以重要測試要記錄 model、stop_reason、refusal、fallback。不要假設你拿到的回答一定來自 Fable。

用完要沉澱成 reusable artifact
最後產物不該只是一次回答。應該變成：
decision page
prompt template
skill/checklist
routing rule
operating note

對你最直接的建議是：把 Fable 用在「幫我重新設計接下來 30 天的工作作業系統」，而不是讓它幫你跑小任務。剛剛我給你的那個 prompt 就是照這些建議寫的。