Fable 5 一次性制度化提示詞

這是我這輩子唯一一次使用 Fable 5 的機會。這個 session 結束後，我的環境將由較小的模型（Sonnet、Opus、Haiku 等）長期運作。所以你的任務只有一個：把你的判斷力轉成可長期沿用的制度與檔案，讓之後每一個較弱模型的 session 都因此變強。用這個 session 立制度，不要拿去執行日常任務。

作業規則（先讀完再動手）：
1. 自主作業。環境能查的自己查（CLAUDE.md、可用 subagent、模型與 effort 參數、MCP、skill、記憶機制）。開場最多問我一批問題，五題以內，之後不再停下來等我。
2. 價值排序＋隨做隨寫。先做價值最高的產出，每完成一項立刻寫進檔案再做下一項。這個 session 隨時可能中斷，中斷時已落檔的就是我拿到的全部。
3. 改任何既有檔案前先留備份副本。新內容寫成新檔，CLAUDE.md 只放精簡路由指向新檔。
4. 你的讀者是較弱的模型。你自己不需要被逐步指揮，但寫給它們的規則要具體、可執行、有判準與範例；抽象要求（例如「保持高品質」）等於沒寫。
5. 產出不可依賴只有你能做到的能力，全部要在 Sonnet 等級就跑得動。
6. 環境允許的話用最高 effort 跑，長回合沒關係。

交付清單（按價值排序執行）：
A. 快速診斷：我目前 harness 最漏 token、最容易失焦、最容易出錯的前三名，各附具體修法。這份先寫，供後面所有產出引用。
B. 重寫 CLAUDE.md：最高槓桿的檔案，未來每個 session 都會載入。收斂重複規則、刪過時內容、把長內容抽成引用檔，套用「弱模型需要明確、強模型需要留白」的寫法。
C. 模型調度守則（獨立檔案）：指揮官不下場（大量讀取、掃 repo、查網頁、批次改檔一律派 subagent，主對話只進結論）；派工三件套（目標與動機、驗收條件、回報格式）；顯式指定 model 與 effort（按我環境實際可用的型號寫，不憑印象）；回報合約（subagent 只回結論與檔案:行號，長產物落檔傳路徑）；升降級路徑（小模型錯一次直接升級、中階模型同一子任務連錯兩次帶完整失敗軌跡升級、解出的模式降回便宜模型批次套用、同一件事最多重試兩輪）；驗證不自驗（驗收派 fresh-context agent：檔案用 read-back、程式碼用測試或實跑、高風險判斷加第二意見或多答案評審選優）。
D. 判斷力外化（獨立檔案）：把只有你這個等級才擅長的判斷，寫成弱模型可執行的 rubric 與 checklist。至少涵蓋：何時該升級模型、何時算真的完成、何時該停下來問使用者、什麼訊號代表方向錯了該換路而非重試、品質底線怎麼驗。每條判準附一個正例和一個反例。
E. 派工 prompt 模板：給未來主模型直接套用的委派模板（含驗收條件與回報格式的填空），常見任務型態各一份：搜尋、實作、重構、研究、審查。
F. 維護協議：未來的弱模型怎麼安全地更新以上檔案。哪些可以自行改、哪些動之前要先問使用者、每次踩坑後教訓寫回哪裡、用什麼格式、累積多長要精簡。
G. 給未來 session 的信：三件我沒問、但你認為對這個環境最重要的事，加上你認為這套制度最可能的退化方式與預防法。

收尾（必做，不可省略）：
1. 開一個 fresh-context subagent 對抗審查全部產出：找規則互相打架、路徑或工具名錯誤、弱模型會誤讀的模糊語句，修完為止。
2. read-back 驗證每個檔案確實落地、內容完整。
3. 給我一頁總結：改了什麼、為什麼、明天開始怎麼用。
4. 如果 context 快用完：立刻停下手上的產出，先完成收尾前三步，把未完成項目寫進「給未來 session 的信」交接。

誠實條款：標註 harness 的極限。拆解、驗證、多樣本評審補得了執行品質；模糊題與品味判斷補不了，要寫明遇到時怎麼辦（升級模型、外部第二意見、或明說做不到）。不確定的事就查，查不到就標註，不要編造。