claude-devfleet
affaan-m/ecc
Orchestrate parallel Claude Code agents on coding tasks with dependency chains and isolated worktrees.
What is claude-devfleet?
Claude DevFleet dispatches multiple Claude Code agents to work on coding tasks in parallel, each in an isolated git worktree. Plan projects into mission DAGs, dispatch agents, monitor progress, and read structured reports of changes and outcomes.
- Break down projects into chained missions with dependency graphs via AI planning
- Dispatch multiple Claude Code agents to run in parallel across isolated git worktrees
- Auto-merge completed work and trigger dependent missions when prerequisites finish
- Monitor agent progress and system slot availability via dashboard and status polling
- Generate structured reports showing files changed, work completed, errors, and next steps
How to install claude-devfleet
npx skills add null --skill claude-devfleet- Install and run the DevFleet server from https://github.com/LEC-AI/claude-devfleet
- Connect it via MCP: claude mcp add devfleet --transport http http://localhost:18801/mcp
- Verify the process on port 18801 is the DevFleet binary (see SECURITY.md)
How to use claude-devfleet
- 1.Call plan_project(prompt) to break your task into a mission DAG, or manually create_project and create_mission for step-by-step control
- 2.Review the plan with the user and get approval before proceeding
- 3.Dispatch the root mission (empty depends_on) via dispatch_mission; dependent missions auto-dispatch as their prerequisites complete
- 4.Poll get_mission_status or get_dashboard every 30–60 seconds to monitor progress without blocking
- 5.Call get_report(mission_id) on completed missions to read files changed, work done, errors, and next steps
- 6.Share results and failures with the user; retry failed missions after reviewing their reports
Use cases
- Build a REST API by having one agent implement endpoints while another writes tests in parallel
- Refactor a large codebase by splitting work across multiple agents on different modules
- Implement a feature with review: dispatch implementation, then auto-trigger a review mission once implementation completes
- Coordinate multi-component development where later tasks depend on earlier ones finishing
- Teams building complex features that benefit from parallel development
- Developers managing large refactors or multi-part projects
- Anyone using Claude Code who wants to orchestrate multiple agents on interdependent tasks
claude-devfleet FAQ
DevFleet runs up to 3 concurrent agents by default (configurable via DEVFLEET_MAX_AGENTS). Missions with auto_dispatch=true queue and launch automatically as slots free up.
The mission reaches a failed state. Call get_report(mission_id) to see errors and next steps, then decide whether to retry or manually fix issues.
Yes. Create missions with auto_dispatch=false, dispatch manually, review the report, then create and dispatch dependent missions only if you approve.
The agent's changes remain on its worktree branch for manual resolution. You can inspect and resolve the conflict before merging.
Prefer polling with get_mission_status every 30–60 seconds so the user sees progress updates. Use wait_for_mission only for short tasks where blocking is acceptable.
Full instructions (SKILL.md)
Source of truth, from affaan-m/ecc.
name: claude-devfleet description: Orchestrate multi-agent coding tasks via Claude DevFleet — plan projects, dispatch parallel agents in isolated worktrees, monitor progress, and read structured reports. metadata: origin: community
Claude DevFleet Multi-Agent Orchestration
When to Use
Use this skill when you need to dispatch multiple Claude Code agents to work on coding tasks in parallel. Each agent runs in an isolated git worktree with full tooling.
Setup
The DevFleet server is a separate project, not bundled with ECC. Install and run it from its repository first: https://github.com/LEC-AI/claude-devfleet
Then connect the running instance via MCP:
claude mcp add devfleet --transport http http://localhost:18801/mcp
Before first use, verify the process listening on port 18801 is the DevFleet binary you installed (see SECURITY.md on localhost MCP servers).
How It Works
User → "Build a REST API with auth and tests"
↓
plan_project(prompt) → project_id + mission DAG
↓
Show plan to user → get approval
↓
dispatch_mission(M1) → Agent 1 spawns in worktree
↓
M1 completes → auto-merge → auto-dispatch M2 (depends_on M1)
↓
M2 completes → auto-merge
↓
get_report(M2) → files_changed, what_done, errors, next_steps
↓
Report back to user
Tools
| Tool | Purpose |
|---|---|
plan_project(prompt) | AI breaks a description into a project with chained missions |
create_project(name, path?, description?) | Create a project manually, returns project_id |
create_mission(project_id, title, prompt, depends_on?, auto_dispatch?) | Add a mission. depends_on is a list of mission ID strings (e.g., ["abc-123"]). Set auto_dispatch=true to auto-start when deps are met. |
dispatch_mission(mission_id, model?, max_turns?) | Start an agent on a mission |
cancel_mission(mission_id) | Stop a running agent |
wait_for_mission(mission_id, timeout_seconds?) | Block until a mission completes (see note below) |
get_mission_status(mission_id) | Check mission progress without blocking |
get_report(mission_id) | Read structured report (files changed, tested, errors, next steps) |
get_dashboard() | System overview: running agents, stats, recent activity |
list_projects() | Browse all projects |
list_missions(project_id, status?) | List missions in a project |
Note on
wait_for_mission: This blocks the conversation for up totimeout_seconds(default 600). For long-running missions, prefer polling withget_mission_statusevery 30–60 seconds instead, so the user sees progress updates.
Workflow: Plan → Dispatch → Monitor → Report
- Plan: Call
plan_project(prompt="...")→ returnsproject_id+ list of missions withdepends_onchains andauto_dispatch=true. - Show plan: Present mission titles, types, and dependency chain to the user.
- Dispatch: Call
dispatch_mission(mission_id=<first_mission_id>)on the root mission (emptydepends_on). Remaining missions auto-dispatch as their dependencies complete (becauseplan_projectsetsauto_dispatch=trueon them). - Monitor: Call
get_mission_status(mission_id=...)orget_dashboard()to check progress. - Report: Call
get_report(mission_id=...)when missions complete. Share highlights with the user.
Concurrency
DevFleet runs up to 3 concurrent agents by default (configurable via DEVFLEET_MAX_AGENTS). When all slots are full, missions with auto_dispatch=true queue in the mission watcher and dispatch automatically as slots free up. Check get_dashboard() for current slot usage.
Examples
Full auto: plan and launch
plan_project(prompt="...")→ shows plan with missions and dependencies.- Dispatch the first mission (the one with empty
depends_on). - Remaining missions auto-dispatch as dependencies resolve (they have
auto_dispatch=true). - Report back with project ID and mission count so the user knows what was launched.
- Poll with
get_mission_statusorget_dashboard()periodically until all missions reach a terminal state (completed,failed, orcancelled). get_report(mission_id=...)for each terminal mission — summarize successes and call out failures with errors and next steps.
Manual: step-by-step control
create_project(name="My Project")→ returnsproject_id.create_mission(project_id=project_id, title="...", prompt="...", auto_dispatch=true)for the first (root) mission → captureroot_mission_id.create_mission(project_id=project_id, title="...", prompt="...", auto_dispatch=true, depends_on=["<root_mission_id>"])for each subsequent task.dispatch_mission(mission_id=...)on the first mission to start the chain.get_report(mission_id=...)when done.
Sequential with review
create_project(name="...")→ getproject_id.create_mission(project_id=project_id, title="Implement feature", prompt="...")→ getimpl_mission_id.dispatch_mission(mission_id=impl_mission_id), then poll withget_mission_statusuntil complete.get_report(mission_id=impl_mission_id)to review results.create_mission(project_id=project_id, title="Review", prompt="...", depends_on=[impl_mission_id], auto_dispatch=true)— auto-starts since the dependency is already met.
Guidelines
- Always confirm the plan with the user before dispatching, unless they said to go ahead.
- Include mission titles and IDs when reporting status.
- If a mission fails, read its report before retrying.
- Check
get_dashboard()for agent slot availability before bulk dispatching. - Mission dependencies form a DAG — do not create circular dependencies.
- Each agent runs in an isolated git worktree and auto-merges on completion. If a merge conflict occurs, the changes remain on the agent's worktree branch for manual resolution.
- When manually creating missions, always set
auto_dispatch=trueif you want them to trigger automatically when dependencies complete. Without this flag, missions stay indraftstatus.
Related skills
More from affaan-m/ecc and the wider catalog.
click-path-audit
Trace button handlers through state changes to find bugs where functions cancel each other out or leave UI inconsistent.
clickhouse-io
ClickHouse patterns for high-performance analytics, query optimization, and data engineering.
code-tour
Create CodeTour `.tour` files with real file anchors for guided codebase walkthroughs.
codebase-onboarding
Analyze unfamiliar codebases and generate structured onboarding guides with architecture maps and CLAUDE.md.
codehealth-mcp
Agent skill from affaan-m/ecc.
coding-standards
Baseline coding conventions for naming, readability, immutability, and code quality across projects.