claude-devfleet

claude-devfleet skill の概要

claude-devfleet の役割

claude-devfleet は、Claude DevFleet を使って複数エージェントのコーディング作業を進めるための調整用スキルであり、一般的なコーディングプロンプトではありません。大きめのエンジニアリング要件を、計画済みの複数ミッションに分解し、それらを分離された git worktree に振り分け、進捗と完了を構造化された形で報告するのが役目です。

どんな人に向いているか

この claude-devfleet skill は、すでにローカルまたはチームの DevFleet 環境があり、依存関係を考慮した並列実行を使いたい人に最適です。機能追加、リファクタリング、テストの補完、あるいは自然に独立タスクや段階的タスクへ分割できる実装計画と相性が良いです。一方で、1件の修正、1ファイルだけの変更、あるいは素早い回答だけが欲しい場合にはあまり向きません。

プレーンなプロンプトより選ばれる理由

最大の差別化ポイントはオーケストレーションです。計画、承認、振り分け、監視、報告が明確な手順として分かれています。1人のエージェントに「全部やって」と頼むのではなく、claude-devfleet for Agent Orchestration を使うことで、依存関係付きのミッションに作業を分解し、それぞれを別の worktree で並行実行できるため、同時変更がすぐに衝突しにくくなります。

導入の最大のハードル

いちばん大きなハードルはセットアップの実態です。この skill は、MCP 経由で接続された稼働中の Claude DevFleet インスタンスを前提としています。DevFleet が未導入、到達不能、または想定の MCP エンドポイントで公開されていない場合、この skill は実質的に何もできません。これは独立したインストーラではなく、既存インフラの上で動く実行ワークフローだと理解してください。

claude-devfleet skill の使い方

インストール時の前提条件と接続の確認

claude-devfleet を使う前に、Claude Code から MCP 経由で DevFleet に到達できることを確認してください。skill のソースは稼働中インスタンスを明示的に想定しており、接続パターンとして次を示しています。

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

DevFleet サーバーが別のホストやポートで動いている場合は、その URL を調整してください。実際の導入判断として、ローカル MCP サービスが使えない環境なら、その問題を解決するまでこの skill は見送るのが妥当です。

実際に claude-devfleet が呼ばれる流れ

基本フローは次のとおりです。

1. plan_project(prompt) で、大まかな要件をプロジェクトとミッション DAG に変換する。
2. 実行前にユーザーに計画を確認してもらう。
3. dispatch_mission(mission_id, model?, max_turns?) で作業を開始する。
4. 設定済みなら、依存関係でつながったミッションを自動でディスパッチする。
5. get_report(mission_id) で、files_changed、完了作業、エラー、次の手順を要約する。

すでにタスクの分割が分かっているなら、create_project(...) と create_mission(...) を使って手動で計画を組むこともできます。ブレインストーミングよりも依存関係のグラフが重要なときは、手動作成を使ってください。

曖昧な目標を、良いプロンプトに変える

弱い入力: “Build a REST API.”

claude-devfleet skill 向けの、より強い入力:

• repo path または対象コードベース
• 作りたい endpoint と認証方式
• 永続化レイヤー
• テスト期待値
• 対象外の範囲
• 実行順序の制約

例:
“./app 用のプロジェクトを計画してください。projects と tasks の REST API を追加し、JWT 認証を使い、既存の DB レイヤー経由で PostgreSQL を利用し、現在の routes は維持し、integration tests を追加し、schema 変更は endpoint 実装と切り分けてください。安全な範囲では並列実行できる mission を優先してください。”

この方法が効く理由は、plan_project が境界、interface、実行順序の制約を把握できると、より良い mission graph を作れるからです。情報が足りないと、計画が曖昧になったり、ミッション同士が重なりすぎたりしがちです。

おすすめの進め方と、先に読むべき内容

まずは SKILL.md から確認してください。この repository では、実際の運用契約がそこにまとまっています。特に次を重視します。

• 必須の MCP 依存関係
• plan → approve → dispatch → report のワークフロー
• 利用可能な tools とその引数
• depends_on と auto_dispatch による依存関係の扱い

実務的な進め方は次のとおりです。

1. まず計画だけを出してもらう。
2. ミッションが本当に分離可能か確認する。
3. グラフを承認するか修正する。
4. まずは小さな最初のミッションを投げて、環境と repo 前提を検証する。
5. 1件でも成功レポートが出てから、並列ディスパッチを拡大する。

claude-devfleet skill の FAQ

claude-devfleet は初心者に向いていますか？

DevFleet がすでに動いている初心者なら、向いている場合があります。オーケストレーションの考え方自体は分かりやすいですが、実際の壁はインフラとタスク分解です。MCP や worktree の扱いに慣れていない初心者は、価値を感じる前に詰まりやすいでしょう。

普通のコーディングプロンプトではなく、これを使うべきなのはどんなときですか？

ミッション計画、分離実行、構造化レポートの恩恵があるくらい、作業が大きいときに claude-devfleet を使ってください。1ファイルの編集、素早いデバッグ、探索的な質問には使わないほうがよいです。その場合は普通のプロンプトのほうが速く、運用コストも低くなります。

この skill の範囲はどこまでですか？

この claude-devfleet guide が扱うのはオーケストレーションの挙動であり、環境の完全な provision ではありません。この skill は DevFleet が存在し、plan_project、create_mission、dispatch_mission、cancel_mission、get_report などの tool call が MCP 経由で利用できることを前提にしています。これらの tools がなければ、実質的に使えません。

チームのワークフローにも合いますか？

はい。特に、可視化された mission graph と、分離された git worktree による安全な並列化を求めるチームには向いています。一方で、小規模な repo や、コーディングフローに auto-merge や依存関係ベースの自動化を入れたくないチームには、魅力が小さいかもしれません。

claude-devfleet skill を改善するには

計画入力をより良くする

claude-devfleet の出力を最も早く改善する方法は、最初にアーキテクチャ制約と分割のヒントを具体的に伝えることです。次のような情報を入れてください。

• 対象 repo/path
• 受け入れ条件
• 衝突しやすい共有ファイル
• 先にやるべき task
• 並列で進められる task

こうすると、質の低い mission graph を避けやすくなり、2人のエージェントが同じホットスポットを触ってしまう事態も減らせます。

よくある失敗モードを見張る

主な失敗モードは、かなり予測しやすいです。

• DevFleet への MCP 接続がない
• mission の範囲が広すぎる
• 依存タスクを早くディスパッチしすぎる
• 並列 worktree 間で編集が重なる
• 複雑な mission に対して max_turns が足りない

mission が止まり続ける場合は、モデルを変えたりエージェントを増やしたりする前に、まずスコープを小さくしてください。

最初のレポート後に反復する

最初の計画を最終版だと思わないでください。get_report(...) の後は、次のように project を絞り込みます。

• 未完了の作業を、より細かい follow-up に分割する
• 見落としていた依存関係を追加する
• 重複作業をしていた mission を cancel する
• 正確な files、interfaces、test targets を含むよう prompt を書き直す

ここで claude-devfleet for Agent Orchestration は、1本の長いプロンプトより価値が出ます。ワークフロー自体が、一発必中ではなく、修正を前提に設計されているからです。

mission プロンプトを絞り込んで成果を上げる

良い mission プロンプトは、コード領域、望む出力、完了条件を明示します。たとえば次のように書きます。
“server/auth に JWT auth middleware を実装し、既存の protected routes に組み込み、token validation と expired tokens の unit tests を追加し、database schema は変更しないでください。”

このレベルまで具体的にすると、引き継ぎの品質が上がり、merge risk が下がり、最終レポートも実務で使いやすくなります。