契約都簽完了，從今天起看工具怎麼把契約落地。第一個架構問題：訪談、規劃、風格、來源、核准、寫作，六件事為什麼塞在同一個 Skill 裡，而不是拆成六個小而美的 Skill？今天的核心主張是：這六件事共用同一個核准狀態，拆開它們就是拆散狀態。

先交代決策脈絡（context）。這條產線上的活是連續的：intake 盤點的結果流進 Brief，Brief 決定規劃，規劃綁核准，核准解鎖寫作，寫作又要回頭查來源清冊。每一站的產出是下一站的輸入，而整條線只有一個關鍵狀態：「目前的計畫核准了沒」。toolkit README 的 Architecture 把這個設計講得直接：單一 Skill 是刻意的，因為 intake、框架選擇、風格校準、研究、引用與寫作共用一個觸發點和一個核准狀態機，拆開會把對話與成功條件切碎。

決策（decision）：一個 orchestration Skill，統一入口，統一狀態。後果一正一負。正面：老闆說「幫我寫 N 天系列」這一句話就能進入整條流程，狀態只有一份，不會出現規劃 Skill 以為核准了、寫作 Skill 以為沒核准的精神分裂。負面：SKILL.md 變厚，單一 Skill 的說明得涵蓋六種活——緩解方式是「用到哪段讀哪段」的分層 references 設計，正文只留規則，細節下放到五份參考文件。至於六個小 Skill 的替代方案，一句話帶過它的日常長相：每站之間的狀態同步得有人扛，而那個「有人」毫無懸念是我——同一份盤點結果在六個觸發詞之間搬運六次，這不叫模組化，這叫幫我加班。

這個「一個」也是被驗證的約束：build.py 的 SKILL_NAMES 白名單只有一個元素，封裝時只認 plan-write-blog-series，想偷塞第二個 Skill 進包裡，建置就把你擋下來。

最後把三個容易混淆的東西擺開：public toolkit repo 是原始碼；dist/ 建出來的資料夾與 ZIP 是可安裝套件；而你現在讀的這個文章 repo 只是工作紀錄與稿子，它不是 Skill 的家——別在這裡找程式碼，找不到的。

架構定了：一個 Skill、一個狀態、一條線——我加班的理由至少少了五個。