Build what's next on GitHub, the place for anyone from anywhere to build anything.
Join us October 28-29 in San Francisco or online for GitHub Universe, our flagship developer event uniting people, agents, and the world's code.
/fleet lets Copilot CLI dispatch multiple agents in parallel. Learn how to write prompts that split work across files, declare dependencies, and avoid common pitfalls.
What if GitHub Copilot CLI could work on five files at the same time instead of one? That’s where /fleet comes in.
/fleet is a slash command in Copilot CLI that enables Copilot to simultaneously work with multiple subagents in parallel. Instead of working through tasks sequentially, Copilot now has a behind the scenes orchestrator that plans and breaks your objective into independent work items and dispatches multiple agents to execute them simultaneously. On different files, in different parts of your codebase, all at once.
Want to learn more about how /fleet works, and more importantly, how to use it most effectively? Let’s jump in.
When you run /fleet with a prompt, the behind-the-scenes orchestrator:
Each sub-agent gets its own context window but shares the same filesystem. They can’t talk to each other directly; only the orchestrator coordinates.
Think of it as a project lead who assigns work to a team, checks in on progress, and assembles the final deliverable.
Start fleet mode by sending /fleet <YOUR OBJECTIVE PROMPT>. For example:
That’s it. The orchestrator takes your objective, figures out what can be parallelized, and starts dispatching.
You can also run it non-interactively in your terminal:
The --no-ask-user flag is required for non-interactive mode, since there’s no way to respond to prompts. Now let’s look at what makes a good prompt.
The quality of your /fleet prompt determines how effectively work gets distributed. The key is giving the orchestrator enough structure to cleanly break down your task.
A good way to do that is being specific about deliverables. Map every work item to a concrete artifact like a file, a test suite, or a section of documentation. Vague prompts lead to sequential execution because the orchestrator can’t identify independent pieces.
For example, instead of: /fleet Build the documentation, you could try:
The second prompt gives the orchestrator four distinct deliverables, three of which can run in parallel, and one that depends on them.
Sub-agents work best when they know exactly where their scope starts and ends. When writing your prompt include:
Here’s a prompt that showcases these boundaries:
If one piece of work depends on another, say so. The orchestrator will serialize those items and parallelize the rest. For example:
You can define specialized agents in .github/agents/ and reference them in your /fleet prompt. Each agent can specify its own model, tools, and instructions. Be aware that if you don’t specify which model to use, agents will use the current default model.
Then reference the custom agent in your prompt:
This is useful when different tracks need different strengths such as using a heavier model for complex logic and a lighter one for boilerplate documentation.
Watch how the orchestrator deploys subagents, it’s the fastest way to learn how to write prompts that parallelize well.
Use this quick checklist:
/tasks to open the tasks dialog and inspect running background tasks.If the fleet doesn’t seem to be parallelizing, try stopping Copilot’s work and asking for an explicit decomposition:
Fleet is powerful, but a few gotchas are worth knowing upfront.
Sub-agents share a filesystem with no file locking. If two agents write to the same file, the last one to finish wins—silently. No error, no merge, just an overwrite.
The fix is to assign each agent distinct files in your prompt. If multiple agents need to contribute to a single file, consider having each write to a temporary path and let the orchestrator merge them at the end. Or set an explicit order for the agents to follow.
Sub-agents can’t see the orchestrator’s conversation history. When the orchestrator dispatches a sub-agent, it passes along a prompt, but that prompt needs to include everything the sub-agent needs. If you’ve already gathered useful context earlier in the session, make sure your /fleet prompt includes it (or references files the sub-agents can read).
After dispatching, you can send follow-up prompts to guide the orchestrator:
Prioritize failing tests first, then complete remaining tasks.List active sub-agents and what each is currently doing.Mark done only when lint, type check, and all tests pass./fleet (and when not to)/fleet shines when your task has natural parallelism—multiple files, independent modules, or separable concerns. It’s particularly effective for:
For strictly linear, single-file work, regular Copilot CLI prompts are simpler and just as fast. Fleet adds coordination overhead, so it pays off when there’s real work to distribute.
/fleet is most useful when you treat it like a team, not a magic trick. Start small. Pick a task with clear outputs, clean file boundaries, and obvious parallelism. See how the orchestrator decomposes the work, where it helps, and where it gets in the way. As you get more comfortable, push it further with larger refactors, multi‑track features, or docs and tests in parallel. The fastest way to learn when /fleet pays off is to try it on real work and adjust your prompts based on what you see.