Delegating Work with /delegate

The unlock that separates power users from everyone else is realizing Copilot CLI can work for you while you work — not sequentially, but in parallel.

/delegate and /fleet are how you get there — and they are two different architectures. /delegate hands a task to the Copilot coding agent in the cloud: it runs on GitHub's infrastructure, works in its own isolated environment, and delivers a draft pull request. It keeps working even if you close your laptop. /fleet parallelizes locally: it splits a task across multiple subagents running inside your session, and their results land in your working tree. In both cases your current session stays active and you keep working.

This is not a magic multiplier with no downsides. The quality of what a delegated agent produces is directly proportional to how well you specified the task. Vague delegation produces vague PRs. But well-scoped delegation — "write tests for the auth module using Jest, match the existing test style, no new dependencies" — produces work that often only needs a read-through, not a rewrite.

When to delegate vs work locally

The mental test: "Could I hand this task to a competent junior developer with a one-paragraph brief and trust the output enough to review it?" If yes, it is a delegate candidate. If it requires back-and-forth, access to your current mental model, or iterative exploration — stay local.

Using /delegate

The syntax is:

/delegate "Write unit tests for src/services/auth.ts using Jest.
Match the style in src/services/user.test.ts.
No new dependencies. PR title: 'test: add auth service unit tests'."

Copilot CLI hands the task to the Copilot coding agent on GitHub and returns to your session. The coding agent works in its own isolated cloud environment — it clones the repo, makes the changes, and opens a draft pull request on a new branch. Because it runs on GitHub's infrastructure, it keeps working even after you close your terminal.

A few practices that improve delegate output:

Reference existing files as style guides. "Match the style in tests/user.test.ts" is more precise than "write good tests." The agent will read that file and follow its patterns.

Specify the output format. "PR title should be..." and "use conventional commits" gives the agent formatting constraints that make the PR easier to review.

Remember the boundary. The cloud coding agent does not inherit your local session's --allow-tool/--deny-tool flags — it runs in GitHub's isolated environment with its own controls, and its only write path back to you is the draft PR. That isolation is the safety property: nothing merges without your review.

Using /fleet for parallel subtasks

/fleet stays local where /delegate goes to the cloud: it takes a higher-level task, decomposes it into parts, and runs multiple subagents in parallel inside your session to handle them.

Example:

/fleet "Complete the auth module refactor:
- write unit tests for src/services/auth.ts
- update the API docs for /auth endpoints
- generate a changelog entry for this feature"

Copilot CLI runs the subagents simultaneously. Each works on its part independently, and the combined changes land in your working tree for one review — no PRs are created. Total elapsed time is approximately the duration of the longest subtask, not the sum.

The power of /fleet is real. The constraint is coordination: the parts must be genuinely independent. If one subagent is writing tests while another is editing the same source file those tests cover, they will trip over each other's changes in your working tree. Decompose fleet tasks so each subagent's file territory is separate.

Collecting and integrating delegate output

When the cloud coding agent finishes, it opens a draft PR (for /fleet, the equivalent review surface is /diff on your working tree). Your job is:

1. Read the diff. Not skim — read. The agent was autonomous. There will be edge cases and assumptions you need to verify.
2. Run the tests locally (if the PR adds code). The agent ran tests in its own context; run them in yours.
3. Merge or request changes. Treat it like any other PR. If the work is 80% right but needs adjustments, make the changes yourself or comment and re-delegate.

The merge should not happen automatically. Human review is the control point, and that control point is what makes delegation safe rather than reckless.

Lesson Drill

1. Identify a task in your current project that is a clear /delegate candidate. Write the one-paragraph brief you would use. Does it pass the "junior developer" test?
2. Run an actual /delegate with that task. When the PR is ready, review it critically. What did the agent get right? What did it miss?
3. Try a /fleet decomposition on a larger task. Identify at least three independent subtasks that can run in parallel.

Bottom Line

/delegate offloads well-defined, isolated subtasks to the Copilot coding agent in the cloud, which produces a draft pull request. /fleet parallelizes the parts of a task across local subagents whose results land in your working tree. Both require you to review the output — autonomous execution does not mean unreviewed output. The quality of delegation scales directly with the quality of your task brief.

The next lesson covers team setup: how to configure a repo so every team member's Copilot CLI sessions start with the right baseline.