breakdown —— 收斂式、行動優先的問題分解 是做什麼的？
/fanout 的收斂互補技能。/fanout 把問題「打開」（多個有效答案）； /breakdown 把問題「關閉」（一個糾結 → 一個下一步）。單次執行，無子代理， 成本約 1 倍。基於維護者會話記錄的爬梳：最強烈的摩擦是 「別解釋了，直接做」，因此此技能設計為行動優先、極簡文字。 如果你的輸出讀起來像溫柔的引導，那就錯了——砍掉它。
步驟 1 —— 取得糾結
透過 @提及、路徑或貼上文字接受問題。如果問題真的模糊，
只問一次一句或兩句。分解前，先將任何參照的檔案讀到 EOF。
如果糾結是（或命名了）一個專案成品，也先將該專案的 CHECKPOINT.md
讀到 EOF（收據/預覽不算讀取）——「真實目標」和「阻塞決策」
依賴即時專案狀態（截止日期、排序門檻、已決定事項），
而對專案狀態無知的分解會指向錯誤的下一個行動。只有在真的沒有專案時才跳過。
步驟 2 —— 精簡地依序輸出這五個區塊
無前言。沒有「我可以……」。不要大段重述問題。
- 真實目標（一句話）。「完成」的真正含義。如果陳述的目標與 真實目標不同，用一句話說明。
- 最小下一個行動（一個具體、可一次完成的實際步驟——例如 「打開 X 並寫下三個欄位名稱」，不是「設計綱要」）。然後 主動提議現在就做。不要先長篇解釋。
- 唯一阻塞決策—— 解鎖最多進度的單一分歧點，或者 「沒有——直接開始。」
- 完整計畫（收合）—— 在一行摘要下方的完整檢查清單， 明確淡化：「在步驟 2 完成前忽略這項。」
- 第一個陷阱—— 最可能的失敗模式及其最早的信號。
規則
- 只走關鍵路徑上的一條線。不要列出平行工作流。
- 用白話，不要發明代碼（將任何歸檔標籤翻譯成人類語言）。
- 在使用者選擇之前，不要開始執行。/breakdown 只規劃；它不執行。
- 預設不保留任何東西。如果值得保留，主動提議寫入專案的 CHECKPOINT「下一個步驟」行。