claude-devfleet

Overview of claude-devfleet skill

What claude-devfleet does

claude-devfleet is a coordination skill for running multi-agent coding work through Claude DevFleet, not a general coding prompt. Its job is to turn one larger engineering request into a planned set of missions, dispatch those missions to isolated git worktrees, and return structured progress and completion reports.

Who should install it

This claude-devfleet skill is best for users who already have a local or team DevFleet setup and want parallel execution with dependency-aware sequencing. It is a strong fit for feature builds, refactors, test backfills, or implementation plans that naturally split into independent or staged tasks. It is a weak fit if you only need one edit, one file change, or a quick answer.

Why users pick it over a plain prompt

The main differentiator is orchestration: planning, approval, dispatch, monitoring, and reporting are explicit steps. Instead of asking one agent to “do everything,” claude-devfleet for Agent Orchestration helps you break work into missions with dependencies, then run them in separate worktrees so concurrent changes do not immediately collide.

The main adoption blocker

The biggest blocker is setup reality: this skill requires a running Claude DevFleet instance connected through MCP. If DevFleet is not installed, reachable, and exposed at the expected MCP endpoint, the skill cannot do anything useful. Read it as an execution workflow on top of existing infrastructure, not a self-contained installer.

How to Use claude-devfleet skill

Install context and prerequisite connection

Before trying claude-devfleet usage, make sure Claude Code can reach DevFleet over MCP. The skill source explicitly expects a running instance and shows this connection pattern:

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

If your DevFleet server is on another host or port, adjust that URL. Practical install decision: if your environment does not allow local MCP services, skip this skill until that part is solved.

How claude-devfleet is called in practice

The core flow is:

1. plan_project(prompt) to turn a broad request into a project and mission DAG.
2. Review the plan with the user before execution.
3. dispatch_mission(mission_id, model?, max_turns?) to start work.
4. Let dependency-linked missions auto-dispatch when configured.
5. Use get_report(mission_id) to summarize files_changed, completed work, errors, and next steps.

You can also build the plan manually with create_project(...) and create_mission(...) when you already know the task breakdown. Use manual creation when the dependency graph matters more than brainstorming.

Turn a rough goal into a strong prompt

Weak input: “Build a REST API.”

Stronger input for the claude-devfleet skill:

• repo path or target codebase
• desired endpoints and auth method
• persistence layer
• test expectations
• non-goals
• sequencing constraints

Example:
“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.”

Why this works: plan_project can create a better mission graph when it knows boundaries, interfaces, and sequencing constraints. Without those, you often get a vague plan or missions that overlap too much.

Suggested workflow and what to read first

Start with SKILL.md because this repository provides the real operating contract there. Focus on:

• required MCP dependency
• the plan → approve → dispatch → report workflow
• available tools and their parameters
• dependency handling via depends_on and auto_dispatch

A practical workflow:

1. Ask for a plan only.
2. Inspect whether missions are truly separable.
3. Approve or revise the graph.
4. Dispatch a small first mission to validate environment and repo assumptions.
5. Scale up parallel dispatch only after one successful report.

claude-devfleet skill FAQ

Is claude-devfleet good for beginners?

Only if the beginner already has DevFleet running. The orchestration model is conceptually clear, but the real barrier is infrastructure and task decomposition. A beginner without MCP or worktree familiarity will likely get blocked before seeing value.

When should I use this instead of a normal coding prompt?

Use claude-devfleet when the task is large enough to benefit from mission planning, isolated execution, and structured reporting. Do not use it for single-file edits, quick debugging, or exploratory questions. In those cases, a normal prompt is faster and has less operational overhead.

What are the boundaries of the skill?

This claude-devfleet guide covers orchestration behavior, not full environment provisioning. The skill assumes DevFleet exists and that tool calls such as plan_project, create_mission, dispatch_mission, cancel_mission, and get_report are available through MCP. If those tools are missing, the skill is effectively unusable.

Does it fit team workflows?

Yes, especially when teams want a visible mission graph and safer parallelism through isolated git worktrees. It is less compelling for tiny repos or teams that do not want auto-merge or dependency-driven automation in their coding flow.

How to Improve claude-devfleet skill

Give better planning inputs

The fastest way to improve claude-devfleet output is to specify architecture constraints and splitting hints up front. Mention:

• target repo/path
• acceptance criteria
• shared files likely to cause conflicts
• tasks that must happen first
• tasks that may run in parallel

This reduces poor mission graphs and avoids two agents touching the same hotspots.

Watch for common failure modes

The main failure modes are predictable:

• no MCP connection to DevFleet
• missions that are too broad
• dependent tasks dispatched too early
• overlapping edits across parallel worktrees
• insufficient max_turns for complex missions

If a mission keeps stalling, shrink scope before changing models or adding more agents.

Iterate after the first report

Do not treat the first plan as final. After get_report(...), refine the project by:

• splitting unfinished work into narrower follow-ups
• adding dependencies that were missed
• canceling missions that duplicated effort
• rewriting prompts to include exact files, interfaces, or test targets

This is where claude-devfleet for Agent Orchestration becomes more valuable than a single long prompt: the workflow is designed for revision, not one-shot perfection.

Improve results with tighter mission prompts

A good mission prompt names the code area, desired output, and definition of done. For example:
“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.”

That level of specificity improves handoff quality, lowers merge risk, and makes the final report more actionable.