核心概念
任務與交接
任務（Task）是 MindMux 把已經達成共識的討論轉化為執行動作的方式。
任務的角色
MindMux 不想變成一個完整的專案管理系統。它的任務模型被刻意限制在更窄的職責範圍內：
- 彙集正確的上下文
- 選擇合適的執行路徑
- 乾淨地派發工作
- 保留足夠的狀態，方便理解任務的來龍去脈
先討論，再建任務
任務應該在工作已經清楚到可以交接之後再建立。它不是用來承載整場討論的。
判斷標準：這件事能不能由當前對話的 agent 直接完成？
- 能 → 不是任務，讓 agent 在對話內透過 MCP 工具完成。
- 不能（需要獨立 agent 長時間執行、worktree 或獨立上下文）→ 才是任務。
建立流程
- 在會話中把行動方向聚焦到一個明確的動作上。
- agent 呼叫
create_task生成任務草案。 - 聊天中彈出 任務確認卡片，展示目標、專案大腦頁面、執行渠道和隔離方式。
- 使用者確認後，任務立即派發，進入
dispatched狀態。
執行方式
當前所有任務都走 agent 模式：
- 啟動一個獨立的 sub-agent run。
- 與對話共享同一個
(runtime, profile)繫結。 - 可選 worktree / tempdir 隔離，避免弄髒主工作區。
- 實時事件流回流到右側任務面板。
隔離性
對於編碼類工作，MindMux 預設採用隔離執行：
worktree：獨立的 git worktree，不影響當前分支。tempdir：臨時目錄，適合產出 out-of-tree 檔案的任務。
具體隔離方式由 TaskType 決定，使用者在確認卡片中可見。
任務之後怎麼處理
MindMux 也刻意把任務後處理環節設計得更窄。任務完成後，你應該追問：
- 這次結果是否改變了專案事實？
- 是否應該更新某個頁面或根文件？
- 是否產生了後續任務或修正動作？
小的後續修正可以透過對話中的 suggest_patch 引導式補丁解決，而不是把整段對話直接變成一個不受約束的編輯環境。
與 handoff skill 的關係
handoff skill 仍然保留，用於“手動把上下文貼給某個外部 agent”的場景。任務功能則是它的結構化升級版：
- 產出從“一段文字”升級為“結構化任務物件”
- 分發從“複製貼上”升級為“一鍵路由 + 狀態迴流”
為什麼這很重要
產品的價值不在於“有任務功能”。真正的價值在於，任務會繼承正確的專案大腦和討論上下文，讓執行從更好的資訊狀態開始。