Quick Answer
GitHub Copilot CLI /fleet is worth using when one task can be split into separate files or tracks such as API, UI, tests, or docs. It is not a speed button for every prompt. The safe way to use it is to define explicit file ownership, state dependencies in the prompt, and keep one human review step after the run. If two subagents need to edit the same file, /fleet is usually the wrong starting point.
GitHub's April 1, 2026 announcement turns parallel subagents into a first-party Copilot CLI workflow instead of a custom team setup. The practical question is when /fleet saves time without making your repository harder to trust.
Prerequisites: You need GitHub Copilot CLI installed and any Copilot plan (Free, Pro, Pro+, Business, or Enterprise). Run copilot --version to confirm your CLI is available. No additional setup is needed beyond a working Copilot subscription.
What Changed on 2026-04-01
On 2026-04-01, GitHub published an official guide to /fleet in Copilot CLI. The new signal is practical: GitHub is now telling users to structure prompts around parallel work items, dependencies, and file boundaries instead of treating multi-agent execution as a hidden implementation detail.
The practical gap is clear: many developers already use Copilot for single-threaded planning or editing, but they do not yet have a clean rule for when to parallelize. /fleet gives them one, as long as they treat it like task orchestration, not autopilot magic.
This article focuses on one narrow outcome: using /fleet to finish bounded repository work faster without creating silent overwrite risk or review blind spots.
What /fleet Actually Does
According to GitHub's official blog post from 2026-04-01, /fleet is a Copilot CLI slash command that lets an orchestrator break your objective into work items, dispatch multiple background subagents, wait for dependencies, and synthesize the final result.
The important detail is the execution model:
- each subagent has its own context window
- all subagents share the same filesystem
- subagents do not talk to each other directly
- the orchestrator decides which tracks can run in parallel and which must wait
The shared filesystem explains both the upside and the risk. The upside is obvious: independent files can move at the same time. The risk is also obvious: shared files become collision points.
Use /fleet Only for the Right Task Shape
Good fits:
- updating API handlers, tests, and docs in different files
- generating docs across multiple pages
- refactoring one feature split across clearly separated modules
- applying repetitive but independent edits across several directories
Bad fits:
- one-file bug fixes
- tasks where the real problem is still unclear
- risky migrations where each step changes the next decision
- any change where two or more agents must edit the same file at the same time
A simple rule works well here:
If you cannot assign clean file ownership before you start, do not use /fleet yet.
The Safe Workflow in One Screen
| Step | What to do | Why it matters |
|---|---|---|
| 1 | define outputs by file or directory | the orchestrator needs concrete work items |
| 2 | declare dependencies explicitly | otherwise Copilot may guess the order wrong |
| 3 | set boundaries and validation rules | this limits drift and hidden scope expansion |
| 4 | run /fleet only after the task is decomposable |
parallelism adds overhead when work is linear |
| 5 | review the final diff and run real checks | parallel output still needs one accountable reviewer |
Five steps. No more process than necessary to keep /fleet useful instead of noisy.
Step 1: Start With a Prompt That Maps to Deliverables
GitHub's own examples show why vague prompts underperform. "Build the documentation" is not a good /fleet prompt because the orchestrator cannot easily identify independent tracks. A better prompt maps each task to a concrete file, folder, or test target.
Copyable example:
/fleet Update the authentication docs in four tracks:
1. docs/authentication.md covering login flow and token refresh
2. docs/endpoints.md with request and response examples
3. docs/errors.md with auth-related error codes and fixes
4. docs/index.md linking the three pages above (depends on 1, 2, and 3)
Rules:
- no changes outside docs/
- preserve existing terminology from docs/styleguide.md
- mark done only when markdown lint passes
Why this works:
- each track has a visible output
- only one file depends on the others
- the orchestrator can parallelize the first three items cleanly
- the validation rule is explicit
Step 2: Declare File Boundaries Before You Care About Speed
GitHub's official /fleet post makes one warning unusually clear: subagents share a filesystem and there is no file locking. If two agents write to the same file, the last one to finish wins silently.
That means the real prompt design skill is not "ask for more agents." It is "reduce overlapping write targets."
Use wording like this:
/fleet Implement feature flags in three tracks:
1. API layer in src/api/middleware/ with unit tests
2. UI toggles in src/components/flags/
3. definitions in config/features.yaml
Constraints:
- no dependency changes
- no edits outside assigned directories
- report blockers before expanding scope
- run tests relevant to each track before marking done
Assigning ownership before execution starts makes the prompt more reliable than a broad request like "add feature flags across the app."
Step 3: Use Dependencies to Serialize Only the Parts That Need It
Parallel execution is useful only when the task graph is partially independent. If the whole task is linear, /fleet just adds orchestration overhead.
A good migration prompt looks like this:
/fleet Migrate the user profile flow:
1. add the schema in migrations/008_profiles.sql
2. update src/models/profile.ts (depends on 1)
3. update src/api/profile.ts (depends on 2)
4. update tests/profile.test.ts (depends on 2)
Rules:
- do not change unrelated endpoints
- stop if the schema change requires a rollback plan
In that example, items 3 and 4 can run together after item 2 finishes. That is the kind of partial parallelism /fleet handles well.
Step 4: Know the Two Command Paths That Matter
GitHub's official guidance gives two basic ways to start:
Interactive mode
/fleet Refactor the auth module, update tests, and fix docs in docs/auth/
This is the easier mode when you want to inspect decomposition and steer the orchestrator during the run.
Non-interactive mode
copilot -p "/fleet <YOUR TASK>" --no-ask-user
As of 2026-04-02, GitHub's official /fleet announcement says --no-ask-user is required in non-interactive mode because there is no prompt-response loop available.
Use non-interactive mode only when your constraints are already clear enough to encode in the prompt. If you still expect negotiation, stay interactive.
Step 5: Watch the Run Like a Reviewer, Not a Spectator
GitHub recommends checking whether decomposition actually happened and using /tasks to inspect background work. That matters because not every /fleet run truly parallelizes.
What to check:
- does Copilot break the work into multiple tracks before execution starts?
- are different tracks moving at the same time?
- do the tracks own separate files or directories?
- is one track blocked on a dependency you forgot to state?
If the run looks too linear, stop and retry with a more structured prompt:
Decompose this into independent tracks first, then execute tracks in parallel.
Report each track separately with status, changed files, and blockers.
That wording gives you a better audit trail than a generic "keep going."
Step 6: Add Specialized Agents Only When the Split Is Real
GitHub's April 1 example also shows that you can define agents under .github/agents/ and route specific tracks to them. That is useful when one lane is documentation-heavy and another is code-heavy.
Example agent file:
---
name: technical-writer
description: Documentation specialist
model: claude-sonnet-4
tools: ["bash", "create", "edit", "view"]
---
You write concise technical documentation.
Follow docs/styleguide.md.
Then you can prompt:
/fleet Use @technical-writer.md for docs tasks and the default agent for code changes.
This is worth doing only when the task split is stable. If you still have fuzzy boundaries, custom agents make the workflow more complex without solving the core problem.
The Biggest Failure Modes
Two agents edit one file
File collision is the clearest failure case. GitHub explicitly says there is no file locking. If the same file matters to multiple tracks, use one agent, or have subagents write to temporary files and merge afterward in a controlled step.
The prompt depends on chat history
Subagents do not see the whole orchestrator conversation history. If a key rule lives only in chat, one or more tracks may miss it.
Fix: put the real constraints in the /fleet prompt itself or in repository files the agents can read.
The task is actually linear
If every step depends on the last one, /fleet does not accelerate much. It just gives you more moving parts.
Fix: run a standard Copilot CLI task first, or ask Copilot to plan before you parallelize.
You skip the final review because "multiple agents checked it"
Parallel execution is not independent verification. It is still one orchestrated run.
Fix: review the diff, run the real checks, and keep one human approval gate before merge.
A Practical Prompt Template for Real Repositories
Use this when you want one starting point that already includes the guardrails:
/fleet Complete this task in parallel only where work is independent.
Objective:
[describe the outcome]
Tracks:
1. [file or directory owner + output]
2. [file or directory owner + output]
3. [file or directory owner + output]
Dependencies:
- [track 3 depends on track 1]
- [track 2 can run immediately]
Constraints:
- no edits outside assigned files unless blocked
- no dependency upgrades
- preserve public API names unless explicitly requested
- list blockers before expanding scope
Validation:
- run [tests/lint/typecheck]
- report changed files per track
- mark done only when all listed checks pass
The template does three useful things at once: it tells Copilot what to build, what not to touch, and what proof counts as finished.
FAQ
Is /fleet better than a normal Copilot CLI prompt?
Only when the task has real parallel structure. For one-file work or highly coupled refactors, normal Copilot CLI prompts are simpler. For a broader view of multi-agent workflows and when they make sense, see our practical guide to AI agents.
Do you need custom agents in .github/agents/ to use /fleet well?
No. Clean file boundaries matter more than custom agents. Add specialized agents only after the base workflow already works.
Which GitHub Copilot plans include Copilot CLI?
As of 2026-04-02, GitHub's official Copilot CLI and plans pages list Copilot CLI as available in Free, Pro, Pro+, Business, and Enterprise offerings. GitHub's current individual plan page lists Pro at $10 per user per month and Pro+ at $39 per user per month.
Bottom Line
GitHub Copilot CLI /fleet is useful when you already know how to split the work. The win does not come from "more agents." The win comes from cleaner decomposition.
If you define deliverables by file, declare dependencies, and keep one final review pass, /fleet can shorten bounded multi-file work. If your task still depends on guesswork, shared files, or hidden context, parallelism is the wrong optimization.
Verification Note
Verified on 2026-04-02 against official GitHub sources:
- Official /fleet guide: GitHub Blog, "Run multiple agents at once with /fleet in Copilot CLI" by Matt Nigh & Brian LaFlamme (published 2026-04-01), which confirms the orchestrator model, shared filesystem without file locking,
/tasksinspection,--no-ask-userfor non-interactive mode, and custom agents in.github/agents/. Source:https://github.blog/ai-and-ml/github-copilot/run-multiple-agents-at-once-with-fleet-in-copilot-cli/ - Copilot pricing: GitHub Copilot plans page lists Free ($0), Pro ($10/user/month), and Pro+ ($39/user/month). Copilot CLI is included in all plans including Free.
Source:
https://github.com/features/copilot/plans
Verified on 2026-04-02. Topic trigger checked through the shared news-pipeline database using the GitHub Blog article published on 2026-04-01: https://github.blog/ai-and-ml/github-copilot/run-multiple-agents-at-once-with-fleet-in-copilot-cli/. Verified the key /fleet behavior, prompt patterns, dependency examples, .github/agents/ usage, /tasks inspection, shared-filesystem warning, and non-interactive copilot -p "/fleet <YOUR TASK>" --no-ask-user usage against that official GitHub post. Verified Copilot CLI availability and current plan references against GitHub's official Copilot CLI and plans pages on 2026-04-02: https://github.com/features/copilot/cli and https://github.com/features/copilot/plans.