| name | deep-work |
| description | 用「規劃 → 對抗式反思 → 串行執行 → 整合驗證」的多 agent 流程，把複雜大任務跑完。 觸發時機：使用者要做跨多檔案的重構、遷移、大功能開發、系統審計、深度研究等 「不能一步到位、會動很多地方」的任務。手動召喚：/deep-work。 這是 fable5-scaffold 環節 5（多 agent 編排）的可召喚版——hook 做不到主動 spawn subagent，這個 skill 補上。
|
deep-work — 多 agent 編排工作流
把一個大到不該 single-pass 硬幹的任務，拆成「規劃者 → 對抗審查者 → 執行者群 → 整合者」四個角色跑完。
核心信念：複雜任務的失敗，多半不是不夠聰明，是太快動手、沒先想清楚、沒人挑戰計畫、做完不驗證。
什麼時候用 / 不用
用：跨 ≥3 個檔案的重構、資料遷移、大功能、系統審計、需要查很多來源的研究、任何「改錯一處會連環爆」的任務。
不用（殺雞用牛刀）：單檔小改、回答問題、查一個值、跑一個指令。這些直接做，別開四階段。
判準：你心裡覺得「這要分好幾步、而且我現在還不確定每步細節」→ 用。
四階段流程
階段 1：規劃（Planner）
先不動手。把任務拆成獨立子任務，每個標：
- 它改什麼（檔案/範圍）
- 依賴誰（要先做完哪個才能做它）
- 安全等級（會不會動到很多人依賴的核心？動核心的標「高風險」）
產出一張子任務清單。這階段只想不做。
階段 2：對抗式反思（Adversarial Review）
把階段 1 的計畫，丟給一個獨立的 agent 去挑戰（理想上換個視角、或用更強的 model）。prompt 它：
這是一份任務計畫。你的工作不是肯定它，是找出它會失敗的地方。
預設這個計畫有 60% 的機率漏掉了什麼。具體挑戰：
- 哪些子任務其實有隱藏依賴，串行順序排錯了？
- 哪些「以為簡單」的子任務其實會連環影響別處？
- 有沒有更簡單的做法（減法），不必做這麼多？
- 哪些步驟做完後無法驗證對錯？
必須用 ls / grep / 讀真實檔案來支持你的質疑，不要用想的。
被挑戰出來的問題 → 修正計畫。這一步是 deep-work 最值錢的部分，別跳過。
（如果你裝了 adversarial-verify skill，這階段可以直接呼叫它。）
階段 3：串行執行（Serial Executors）
逐子任務執行。鐵律：動同一個 git 工作樹的子任務，一定串行，不要並行。
為什麼：並行的 agent 會互相吃掉對方 staged 的改動，commit 變得張冠李戴。
每個子任務 spawn 一個 agent 時，給死規格，不要讓它自己探索：
- 改哪個檔、哪一行、改成什麼
- 改完怎麼驗證（跑哪個 test / 什麼 smoke）
- 一個子任務一個 commit（atomic）
互不相干、不碰同一檔的子任務，才可以並行。
階段 4：整合驗證（Synthesize & Verify）
所有子任務做完後：
- 收斂結果，看整體是否達成原任務
- 真實驗證治本生效——跑端到端 test、看真實輸出、確認改動真的起作用
- 不收「我做完了」的自報。要看證據（log / test 綠 / 實際行為），不是相信 agent 說它完成了
如果驗證發現沒真的修好 → 回階段 1 重新規劃那部分。
一句話流程圖
規劃（只想不做）
→ 對抗審查（spawn agent 找計畫漏洞，必看真實檔案）
→ 串行執行（死規格 / 動同一 git 樹串行 / atomic commit）
→ 整合驗證（看真實證據，不收自報）
→ 沒過就回頭重規劃
關鍵紀律速記
- 階段 1 只想不做（最貴的失敗是基於錯假設往前衝）
- 階段 2 別省（一個獨立視角挑戰，勝過自己再想一遍）
- 階段 3 串行防 race + 死規格
- 階段 4 驗真實證據，不信自報
