claude-devfleet

claude-devfleet skill 概覽

claude-devfleet 的作用是什麼

claude-devfleet 是一個透過 Claude DevFleet 執行多代理程式開發協作的編排型 skill，不是一般的寫程式提示詞。它的核心用途，是把一個較大的工程需求拆成有規劃的 mission 集合，派發到彼此隔離的 git worktree 中執行，最後回傳結構化的進度與完成報告。

什麼樣的使用者適合安裝

這個 claude-devfleet skill 最適合已經有本機或團隊版 DevFleet 環境，並且希望支援平行執行與相依順序控管的使用者。它很適合用在功能開發、重構、補測試、或本來就能拆成獨立任務或分階段任務的實作計畫。反過來說，如果你只需要改一個地方、動一個檔案，或只是想快速問一個問題，它就不太適合。

為什麼使用者會選它，而不是一般 prompt

claude-devfleet for Agent Orchestration 的主要差異，在於它把編排流程做成明確步驟：規劃、核准、派發、監控、回報。不是把所有事情一次丟給單一 agent「全部做完」，而是先把工作拆成彼此有相依關係的 missions，再分別放到獨立 worktree 裡執行，降低並行修改一開始就互相衝突的風險。

導入時最大的阻礙

最大的阻礙其實很務實：這個 skill 需要一個透過 MCP 連上的 Claude DevFleet 執行個體。如果 DevFleet 沒有安裝、無法連線，或沒有暴露在預期的 MCP endpoint，這個 skill 就幾乎派不上用場。比較正確的理解方式，是把它當成建構在既有基礎設施之上的執行工作流，而不是一個自帶安裝能力的獨立工具。

如何使用 claude-devfleet skill

安裝前提與必要連線條件

在開始使用 claude-devfleet 之前，先確認 Claude Code 可以透過 MCP 連到 DevFleet。這個 skill 的原始說明明確預期會有一個正在運作的 instance，並示範了這種連線方式：

claude mcp add devfleet --transport http http://localhost:18801/mcp

如果你的 DevFleet server 不在這個 host 或 port，請自行調整 URL。實務上的安裝判斷很簡單：如果你的環境不允許本機 MCP 服務，那在這個問題解決之前，先不要安裝這個 skill。

claude-devfleet 在實際流程中怎麼呼叫

核心流程如下：

1. 用 plan_project(prompt) 把較寬泛的需求轉成 project 與 mission DAG。
2. 在執行前，先和使用者一起檢視並確認這份 plan。
3. 用 dispatch_mission(mission_id, model?, max_turns?) 開始執行。
4. 若有設定，讓帶有相依關係的 missions 自動派發。
5. 用 get_report(mission_id) 彙整 files_changed、已完成工作、錯誤與下一步。

如果你本來就很清楚怎麼拆任務，也可以直接用 create_project(...) 和 create_mission(...) 手動建立計畫。當你更在意 dependency graph 的精準度，而不是先發散腦力激盪時，手動建立會更合適。

怎麼把模糊目標變成高品質的 claude-devfleet 輸入

較弱的輸入：Build a REST API.

更適合 claude-devfleet skill 的輸入，最好包含：

• repo 路徑或目標程式碼庫
• 需要的 endpoints 與驗證方式
• persistence layer
• 對測試的期待
• 明確的非目標
• 執行順序限制

例如：

“Plan a project for ./app: add a REST API for projects and tasks, JWT auth, PostgreSQL via existing DB layer, preserve current routes, add integration tests, and keep schema changes isolated from endpoint work. Prefer missions that can run in parallel where safe.”

這樣寫的原因是：plan_project 只有在明確知道邊界、介面與順序限制時，才比較能產出高品質的 mission graph。若缺少這些資訊，最後常會得到過於空泛的 plan，或是彼此重疊太多、容易互撞的 missions。

建議工作流，以及一開始先看哪些內容

先從 SKILL.md 開始看，因為這個 repository 真正的操作契約主要寫在那裡。建議優先注意：

• 必要的 MCP 相依條件
• plan → approve → dispatch → report 的工作流程
• 可用工具及其參數
• 透過 depends_on 與 auto_dispatch 處理相依關係的方式

一個實務上很穩妥的流程是：

1. 先只要求產生 plan。
2. 檢查 missions 是否真的能拆開獨立執行。
3. 核准這個 graph，或先修改再核准。
4. 先派發一個小型的首個 mission，用來驗證環境與 repo 假設是否正確。
5. 等第一份 report 成功產出後，再放大成平行派發。

claude-devfleet skill 常見問題

claude-devfleet 適合新手嗎？

只有在新手本來就已經把 DevFleet 跑起來的前提下，才算適合。它的編排模型在概念上不難理解，但真正的門檻在於基礎設施與任務拆解能力。若是對 MCP 或 worktree 還不熟的新手，通常還沒看到價值之前，就先卡在環境或流程上了。

什麼時候該用它，而不是一般 coding prompt？

當任務大到值得先做 mission 規劃、隔離執行與結構化回報時，就適合用 claude-devfleet。若只是單檔修改、快速除錯，或探索性提問，就不建議用它。這些情況下一般 prompt 會更快，而且操作成本低得多。

這個 skill 的邊界在哪裡？

這份 claude-devfleet 指南說明的是 orchestration 行為，不包含完整的環境建置。這個 skill 預設 DevFleet 已經存在，而且像 plan_project、create_mission、dispatch_mission、cancel_mission、get_report 這些 tool call 都能透過 MCP 使用。若這些工具不存在，這個 skill 幾乎就無法使用。

它適合團隊工作流嗎？

適合，尤其是團隊想要看得到 mission graph，並透過隔離的 git worktree 來安全地做平行開發時，更有價值。相對地，對很小的 repo，或是不希望在開發流程中引入 auto-merge 與 dependency-driven automation 的團隊來說，吸引力就沒那麼高。

如何改善 claude-devfleet skill 的使用效果

先給出更好的規劃輸入

想讓 claude-devfleet 產出更好結果，最快的方法就是一開始就把架構限制與拆分提示講清楚。建議明確提供：

• 目標 repo/path
• 驗收標準
• 容易發生衝突的共用檔案
• 哪些任務一定要先做
• 哪些任務可以平行進行

這能減少品質不佳的 mission graph，也能避免兩個 agents 同時修改同一批熱點檔案。

注意常見失敗模式

主要失敗模式其實很固定：

• 沒有連上 DevFleet 的 MCP
• missions 範圍抓太大
• 有相依關係的任務太早派發
• 平行 worktree 之間出現重疊修改
• 複雜 mission 的 max_turns 不足

如果某個 mission 一直卡住，優先先縮小範圍，而不是急著換 model 或再加更多 agents。

在第一份報告後持續迭代

不要把第一版 plan 當成最終版。拿到 get_report(...) 之後，可以這樣微調 project：

• 把未完成工作拆成更窄的後續任務
• 補上原本漏掉的 dependencies
• 取消那些其實重複投入的 missions
• 重寫 prompts，補上精確的檔案、介面或測試目標

這也是 claude-devfleet for Agent Orchestration 比單一長 prompt 更有價值的地方：它的工作流本來就是為了反覆修正而設計，不是追求一次到位。

用更精準的 mission prompt 提升結果

好的 mission prompt 會清楚指出程式區域、預期產出，以及完成定義。例如：

“Implement JWT auth middleware in server/auth, wire it into existing protected routes, add unit tests for token validation and expired tokens, do not change database schema.”

這種具體程度能改善交接品質、降低合併風險，也讓最終 report 更容易直接採取行動。