deep-work

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 驗真實證據，不信自報