Parallel work, one command

GitHub Copilot CLI's /fleet slash command lets Copilot tackle multiple files or codebase areas simultaneously. Instead of stepping through a single task, an orchestrator decomposes your objective, dispatches background subagents to independent pieces of work, and reassembles the results.

Each subagent receives its own context window but shares the same filesystem. Subagents do not communicate directly; the orchestrator coordinates all activity, polls for completion, and dispatches successive waves of work before verifying outputs and synthesizing final artifacts.

Starting a fleet

Enter fleet mode with /fleet <YOUR OBJECTIVE PROMPT>:

/fleet Refactor the auth module, update tests, and fix the related docs in the folder docs/auth/

For non-interactive terminal use, add the --no-ask-user flag—it is required because there is no way to answer prompts otherwise:

copilot -p "/fleet <YOUR TASK>" --no-ask-user

Prompting for parallelism

Fleet's effectiveness depends on prompt structure. The orchestrator needs enough detail to separate work into cleanly independent tracks. Map each work item to a concrete artifact—a file, test suite, or documentation section. Vague objectives force the orchestrator into sequential execution because it cannot identify independent pieces.

Compare a generic /fleet Build the documentation prompt with one that enumerates deliverables:

/fleet Create docs for the API module: 

- docs/authentication.md covering token flow and examples 

- docs/endpoints.md with request/response schemas for all REST endpoints 

- docs/errors.md with error codes and troubleshooting steps 

- docs/index.md linking to all three pages (depends on the others finishing first)

The second prompt defines four distinct outputs, three of which can proceed in parallel, with one dependent on the others' completion.

Draw explicit boundaries

Subagents perform best when scope is unambiguous. Effective prompts include:

  • File or module ownership: which directories or files each track handles
  • Constraints: what to leave untouched (no test changes, no dependency upgrades)
  • Validation criteria: lint, type checks, and tests that must pass
/fleet Implement feature flags in three tracks: 

1. API layer: add flag evaluation to src/api/middleware/ and include unit tests that look for successful flag evaluation and tests API endpoints  

2. UI: wire toggle components in src/components/flags/ and introduce no new dependencies 

3. Config: add flag definitions to config/features.yaml  and validate against schema 

Run independent tracks in parallel. No changes outside assigned directories.

Declare dependencies

State any ordering explicitly so the orchestrator serializes dependent items while parallelizing everything else:

/fleet Migrate the database layer: 

1. Write new schema in migrations/005_users.sql 

2. Update the ORM models in src/models/user.ts (depends on 1) 

3. Update API handlers in src/api/users.ts (depends on 2) 

4. Write integration tests in tests/users.test.ts (depends on 2) 

 Items 3 and 4 can run in parallel after item 2 completes.

Mix custom agents

Define specialized agents in .github/agents/ and reference them in the fleet prompt. Each agent can specify its own model, tools, and instructions; without a model specification, agents fall back to the current default.

# .github/agents/technical-writer.md 

--- 

name: technical-writer 

description: Documentation specialist 

model: claude-sonnet-4 

tools: ["bash", "create", "edit", "view"] 

--- 

You write clear, concise technical documentation. Follow the project style guide in /docs/styleguide.md.

Then reference the agent in the prompt:

/fleet Use @technical-writer.md as the agent for all docs tasks and the default agent for code changes.

This arrangement suits workloads where tracks demand different strengths—a heavier model for intricate logic, a lighter one for boilerplate documentation. Note that agents share a filesystem with no file locking. Two agents writing the same file silently overwrite it; the last writer wins. Assign each agent distinct files, or have contributors write to temporary paths for a final orchestrator merge, or impose an explicit ordering.

Confirming parallel activity

Watch the orchestrator's deployments to learn which prompt patterns parallelize best:

  • Decomposition appears: review the plan Copilot shares before starting—it should show multiple tracks, not one long linear sequence.
  • Background task UI confirms activity: run /tasks to open the task dialog and inspect running background jobs.
  • Parallel progress references separate tracks moving concurrently.

If work stays serialized, stop Copilot and request an explicit decomposition:

Decompose this into independent tracks first, then execute tracks in parallel. Report each track separately with status and blockers.

Keeping prompts self-contained

Subagents cannot see the orchestrator's conversation history. When dispatching, the orchestrator passes a prompt that must contain everything the subagent needs. Context gathered earlier in the session won't carry over—include it in the fleet prompt or reference files subagents can read themselves.

After dispatch, follow-up prompts guide the orchestrator mid-flight:

  • 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.

Where fleet pays off

/fleet suits objectives with real parallelism—refactoring across multiple files, generating documentation for several components, implementing a feature spanning API, UI, and tests, or running independent changes that don't share state. For strictly linear, single-file work, standard Copilot CLI prompts are simpler and just as fast because fleet adds coordination overhead.

Start with a modest task that has clear outputs, clean file boundaries, and obvious parallelism. Observe how the orchestrator decomposes the work and adjust prompts based on what you see. As you build familiarity, scale up to larger refactors and concurrent tracks for features, docs, and tests.