GitHub Copilot — the 2026 Method

00Start here

Most Copilot tutorials — including GitHub's own older ones — teach the 2024 product: grey-text completions, a chat pane on the right, @workspace for questions, and a copilot-instructions.md if you are diligent.

That Copilot still exists, and it is still the one most people use. But it is now the smallest part of the product. Between the coding agent going GA in 2025 and the desktop app going GA in June 2026, Copilot became an agent runtime with five front ends — an editor, a terminal, a cloud worker, a desktop control room and an SDK — that all read the same configuration files. The people who built it changed how they talk about it accordingly.

Three statements from GitHub anchor the shift:

On why a desktop app was needed: "the agentic shift has made development faster, [but] it's also led to disjointed workflows, more context switching, and too much time spent reviewing agent-generated code."

GitHub Copilot app announcement, June 2026

On what supervising a fleet actually buys you: "The speed gain is not that each task finishes faster; it's that you unblock more work in the same timeframe."

GitHub blog, orchestrating agents with mission control

On where the human belongs: "Chat is where you instruct, discuss, and reason through ambiguity. Canvases are where that intent becomes visible work you can inspect, steer, and verify."

GitHub Copilot app announcement

Everything below follows from those three sentences: the unit of work is no longer a suggestion, the bottleneck is review, and your job is to make the work verifiable.

01Audit your own setup first

Before any technique, check what you have. Most people who feel Copilot is "handy but not transformative" have never written a file it reads. Every session starts from zero, every correction dies with the chat, and the tool cannot compound.

From a repository root, in pwsh:

copilot version                        # current? it updates weekly
copilot plugins list                   # every plugin, MCP server, skill — non-interactive
gci .github\agents, .github\skills, .github\instructions, .github\hooks
gci AGENTS.md, .github\copilot-instructions.md
gci ~\.copilot\agents, ~\.copilot\skills, ~\.copilot\hooks
gci .github\workflows\copilot-setup-steps.yml   # can the cloud agent run your tests?

Then inside a session: /env (what loaded — instructions, MCP servers, skills, agents) and /instructions (each instruction file, separately, with a toggle). In VS Code: Chat → Diagnostics shows the same thing.

02The four shifts

Completions → delegation

The old loop: type, accept grey text, type. The new loop: write one complete brief, the agent works, you review the result. Completions and next-edit suggestions are still the right tool while you are typing — a rename that ripples, a signature change needing its call sites — but they are a typing aid, not the product. The product is the agent, and it is sized for tasks, not lines.

The corollary: if you find yourself steering the agent every few minutes, your brief was incomplete, not the model weak.

Prompting → instruction files

A good prompt helps once. A line in AGENTS.md helps every agent, on every surface, forever — and it is read by Claude Code, Cursor and Gemini CLI as well, so it outlives your choice of vendor. Re-explaining a convention weekly is a bug in your repository, not in the model.

One surface → the right surface

Copilot is five products sharing a brain. Each has a different latency, a different amount of autonomy and a different correct use, and reaching for the wrong one is the most common way to have a bad time. That is section 03.

Watching one agent → supervising several

Once a task takes twenty minutes unattended, the question stops being "how do I prompt" and becomes "how many can I run, and how do I know when one drifts". The Copilot app, /fleet, /delegate and mission control are all answers to that question. That is section 07.

03Five surfaces, one configuration layer

The leverage is the last column of the table you don't see: all five read the same files. AGENTS.md, path-scoped instructions, skills, custom agents, hooks and MCP configuration are the single place you invest, and every surface — including Copilot code review on your colleagues' pull requests — gets better at once.

Rules of thumb

• One agent you are watching → the IDE or the CLI. Prefer the CLI when the work is shell-heavy or you want autopilot, subagents, or scheduling; prefer the IDE for the debugger, the browser and visual diffs.
• A task you could write as a good issue → the cloud agent. If you cannot write it as an issue, it is not ready for the cloud agent.
• More than two things running → the app, or the worktree discipline it automates.
• Something you want to happen without you → automations (cloud, on a schedule or a GitHub event) or the CLI's /every.

04Verification — the primary lever

The logic is simple. An agent stops when the work looks done. Without a check it can run, "looks done" is the only signal available — and you become the verification loop, at review time, which is the most expensive moment to find out.

Give it something that returns pass or fail and the loop closes on its own: the agent does the work, runs the check, reads the result, iterates.

The ladder

Rung 4 deserves its own note. The agent that did the work is the worst judge of the work — models prefer their own output. A reviewer with no editing tools and a fresh context sees the diff and your criteria but not the reasoning that produced them, so it evaluates on the merits. The kit's reviewer.agent.md is exactly that: tools: ['search', 'fetch'] means it cannot change code, which is a stronger guarantee than telling it not to.

Rewrite your prompts

✗  add validation to the signup form
✓  add server-side validation to SignupRequest: email must be RFC-5322
   valid, password ≥ 12 chars. add tests for both failure cases and the
   happy path. run `dotnet test --filter Signup` and paste the summary.

✗  the build is broken
✓  `dotnet build` fails with: [paste]. fix the root cause — do not
   suppress the warning or pin the package. verify the build succeeds.

✗  make the report page faster
✓  /reports/monthly takes 4.2 s (trace attached). target < 1 s.
   profile first, then change the query, not the caching. show me
   before/after timings from the same trace harness.

And always: ask for evidence, not assertions. "Paste the test output" beats "confirm it works." Evidence is faster to review than a re-run, and it is the only thing you have for a session you were not watching — which is every cloud-agent run.

05Context is the budget

Performance degrades as the context window fills. Everything the agent reads, every command's output, every failed attempt lives there. Copilot auto-compacts near 95% of the limit, and VS Code spills large tool output to disk — but by the time those fire, the session has usually already dulled.

Two rules of thumb

• After two failed corrections on the same issue, /clear and start over with a better brief that incorporates what you learned. A clean session with a good prompt beats a long session full of failed approaches.
• Prefer /rewind to correcting in chat. Correcting leaves the wrong approach in context, where it keeps influencing the model. Rewinding deletes it. VS Code's fork from checkpoint is the same move when you want to keep the original branch of the conversation.

AGENTS.md discipline

AGENTS.md loads on every request, on every surface. That makes it precious real estate, and the most common failure is bloat: GitHub's own best-practice page says it in one line — "lengthy instructions can dilute effectiveness." If Copilot keeps violating a rule you definitely wrote, the file is too long.

The test for every line: "would removing this cause the agent to make a mistake?" If not, cut it.

06How to write a brief now

Delegation means full task context in turn one: goal, constraints, acceptance criteria. Think hard once rather than iterating fast. A cloud-agent task in particular is not a chat message — it is closer to a well-written issue, because nobody is watching.

GOAL        what "done" looks like, in one sentence
CONTEXT     which files; what pattern to follow; #issue or @file
            ("look at OrdersController — follow that pattern")
CONSTRAINTS what must not change; what is out of scope;
            libraries you will and will not accept
VERIFY      the exact command that proves it — and "paste the output"

Plan mode — still earns its place here

GitHub's guidance is explicit: "models achieve higher success rates when given a concrete plan to follow." Use plan mode (Shift+Tab in the CLI; the Plan agent in the IDE) for multi-file changes, refactors with many touch points and new features; skip it for single-file fixes. The modern form is plan, then hand the plan to autopilot:

copilot --plan --mode autopilot -p "…"    # headless: produce a plan, then implement it
Shift+Tab                                  # interactive: standard → plan → autopilot

The plan persists across turns and compaction, so it is also your cheapest defence against goal drift in a long session.

Let the agent interview you

For anything large, start minimal and make Copilot extract the spec:

I want to build [one line]. Interview me before writing anything.
Ask about the data model, the failure cases, the UI, what must not
change, and the tradeoffs I haven't considered. Don't ask obvious
questions. When we've covered everything, write SPEC.md and stop.

Then /clear and execute the spec in a fresh session — or hand SPEC.md to the cloud agent. Clean context, written reference.

Three more techniques

• Challenge the output. "Prove this works — show me the diff and the test output." The built-in Rubber duck agent exists to push back; use it before you ship, not after.
• Ask codebase questions like you would ask a senior engineer. The Explore and Research agents are the onboarding tool for unfamiliar code: "how does auth handle token refresh, and do we already have OAuth utilities?"
• Use voice. Ctrl+Space in the CLI toggles dictation; VS Code has on-device multilingual dictation. Roughly three times faster than typing for long briefs — and briefs should be long now.

07The parallelism ladder

This is where the leverage lives, and where most tutorials stop. Six rungs, each a different answer to "who holds the plan, and where does the work run?"

Worktrees

An isolated checkout per task, so edits never collide. The CLI's /worktree (experimental) makes one for a separate conversation; the app does it for every session — "no manual setup, no cleanup, no branch juggling". If you are not in the app, do it by hand:

git worktree add ..\repo-oauth feature/oauth
cd ..\repo-oauth; copilot              # its own session, its own files
copilot app                            # open the app in this directory instead

Name them by outcome ("oauth-tests-green"), and use the CLI's session sidebar (n new, x close) to keep them straight.

Subagents — the cheapest, most underused

Six built-in agents ship with the CLI — Explore, Task, General purpose, Code review, Research, Rubber duck — plus any .agent.md you write, and the main agent can hand work to them. /tasks shows what is running; Enter teleports into a subagent's session, B pushes a blocking one to the background. Two canonical uses: research ("use the Explore agent to find how we handle retries before you change anything") and adversarial verification ("when you are done, have @reviewer check the diff in a fresh context"). They read forty files in their context and hand back a paragraph.

Queue while it works. Ctrl+Enter queues a prompt, a shell command or a slash command during a turn; VS Code does the same and lets you reorder what is pending. Steering mid-run beats interrupting.

/fleet — the big one on your machine

Give /fleet a plan and the main agent breaks it into independent subtasks, runs them in parallel subagents — each with its own context window — and manages the dependencies between them. It is the right tool when the work is genuinely parallel and the wrong tool for anything sequential.

/fleet write unit tests for every public method in src/Billing/,
  one test class per source file, following tests.instructions.md.
  use @reviewer on each file when it is done.

Three things to know. Subagents default to a low-cost model — name a stronger one in the prompt, or reference a custom agent with @name that pins its own. It costs more requests than one agent would; save it for work wide enough to justify the fan-out. And there is no filesystem isolation between subagents — if two steps touch the same file, they are not independent, and you should say so.

/delegate and the cloud agent

/delegate hands the task to the cloud coding agent, which works in an ephemeral GitHub Actions environment and opens a pull request. The constraints are the design: 59 minutes, hard; one branch, one PR; one repository; and only what copilot-setup-steps.yml installed. Write the task to fit — scoped to something finishable, as one coherent change, with the verification step in the brief and the environment able to run it.

GitHub's own advice on which work to send where: delegate tangential tasks, documentation and separate-module refactors; keep core feature work, debugging and exploration local.

The app and mission control

Once three things are running you need a control plane, and "four terminal tabs" is not one. The app gives you My Work (every session, issue, PR and automation), a worktree per session, canvases (a plan, a PR, a browser, a terminal, that both you and the agent edit) and agent merge, which watches CI, fixes failing checks and merges under rules you set. Mission control at github.com/copilot/agents is the same idea for cloud runs — assign across repos, watch the session log, pause or restart, jump to the PR — and it works from your phone.

The signals that mean intervene now, from GitHub's own guide: failing tests, unexpected files, scope creep, circular behaviour. Batch similar reviews so inconsistencies across related PRs are visible.

08Making it permanent

User-level copies of each live under ~/.copilot/ (%USERPROFILE%\.copilot; relocate with COPILOT_HOME). Repository-level wins for anything a colleague should also get — an instructions file only on your machine helps exactly one person.

Skills

The rule of thumb: if you do something more than once a week, make it a skill. A skill is a folder, not a file — the instructions plus any scripts and references it needs — and its description is the matcher: it must say what the skill does and when to use it, or it never fires.

.github/skills/release-notes/SKILL.md
---
name: release-notes
description: Draft release notes from merged PRs since the last tag.
  Use when asked for release notes or a changelog entry.
allowed-tools: shell
---
1. `git describe --tags --abbrev=0` for the last tag
2. `gh pr list --state merged --search "merged:>$TAG_DATE" --json ...`
3. Group by label; one line per PR; link each
4. Write to CHANGELOG.md under a new heading; do not commit

Keep SKILL.md under 500 lines; detail goes in references/, read only if the skill runs. That is progressive disclosure — the short file is loaded to judge relevance, and a skill that inlines everything defeats its own mechanism. /create-skill in VS Code, or "write me a skill that…" anywhere, drafts one from a description.

Custom agents

.github/agents/reviewer.agent.md
---
name: reviewer
description: Reviews a diff for correctness and security. Read-only.
tools: ['search', 'fetch']
model: claude-opus-4.8
handoffs:
  - label: Fix the findings
    agent: implementation
---
You are a senior engineer reviewing a diff. Report only findings that
affect correctness, security, or a stated requirement…

Two things make this worth copying. The tool list has no editor, so the reviewer cannot modify code. And the model is pinned, so the expensive model is spent here and nowhere else. handoffs turn agents into a workflow; user-invocable: false hides one from the picker so only other agents can call it; agents: lists who it may delegate to.

When not to write one: when instructions or a skill would do. An agent is a persona with a tool boundary. A checklist is a skill. A convention is a line in AGENTS.md. Having all three say the same thing in slightly different words is the most common way a setup becomes unexplainable.

Hooks

Hooks are deterministic; everything above is advisory. Anything you truly cannot tolerate being skipped belongs in a hook. They are JSON, live in .github/hooks/ (or ~/.copilot/hooks/), and carry both a bash and a powershell body so the same file works for the Windows and the Mac colleague:

{ "version": 1,
  "hooks": {
    "agentStop": [{
      "type": "command",
      "bash":       "dotnet test --nologo -v q",
      "powershell": "dotnet test --nologo -v q",
      "timeoutSec": 300 }] } }

You do not have to hand-write these: /create-hook in VS Code, or "write a hook that runs the formatter after every edit". GitHub's framing for when to reach for each layer: add hooks when prompting is not enough; add plugins when distribution becomes the problem.

Plugins — Agent Plugins 1.0

An open standard (GitHub, AWS, Anysphere, Microsoft, OpenAI, Vercel, Google) that packages skills and MCP servers into one installable unit, GA across VS Code, the CLI, the app and the SDK since August 2026. skills/ and mcp.json are portable to any compliant client; Copilot-specific pieces — agents, commands, hooks, canvases — are quarantined in com.github.copilot/. Install from the Awesome Copilot marketplace built into each client; copilot plugins list shows what is live. The moment a second team wants your skills, this is how they travel.

Memory and sessions

Copilot memory is shared across the CLI, the cloud agent and code review — knowledge accumulates instead of being re-supplied. It is also where a wrong fact becomes durable, so correct mistakes deliberately ("forget that we use Moq; we use NSubstitute") rather than working around them. Sessions persist too: copilot --continue, /resume, and /chronicle standup for "what did I do this week", /chronicle tips for what the CLI noticed you could be doing better.

09Models and credits — where to spend

Copilot is a model marketplace. The picker in mid-2026 spans OpenAI's GPT-5.5 generation and GPT-5.3-Codex, Anthropic's Claude Sonnet 5 and Opus 4.8, Google's Gemini 3.1 Pro and 3.7 Flash, and cheaper tiers alongside — and they are not priced alike. Premium requests are consumed by a multiplier: an included model costs nothing, a frontier model up to 10× per request, against a monthly quota.

The single most expensive habit of advanced users is leaving the picker on a frontier model for everything, including renames. Spend judgement on judgement; spend nothing on reading.

/model                       # switch the session (VS Code: per turn)
/usage                       # consumption and remaining premium requests
/limits set 2                # cap AI credits per turn — a budget, not a hope
/autopilot <objective>       # with an optional credit cap for the run
copilot --usage-output-file  # per-agent metrics as JSON, for the scripted runs

Pin the model per agent, not per moment. model: in an .agent.md decides once, correctly, then never again: a reviewer on a strong model, a scaffolder on a cheap one. A fleet with cheap finders and one strong judge costs a fraction of the all-frontier version and finds the same bugs.

10In the terminal

The CLI is the surface GitHub is shipping fastest — weekly releases, with plan mode, autopilot, subagents, fleet, scheduling and headless mode all arriving there first. It needs PowerShell 7 (winget install Microsoft.PowerShell; Windows 11 ships 5.1) and runs best in Windows Terminal.

copilot                       # interactive; trusts the directory first
copilot --agent reviewer      # start on a named agent
copilot --cloud               # the whole session in a cloud sandbox
copilot --continue            # pick up the last session
!dotnet build                 # run a command yourself, bypassing the model
$                             # hand the terminal to a real shell; Enter to come back
/diff                         # review the change; C comments a line, Enter submits
/pr                           # view, create or fix pull requests from here

Autopilot, safely

Autopilot keeps working through steps without waiting for you, and stops when the task is done, when it is blocked, when you press Ctrl+C, or when --max-autopilot-continues runs out. It consumes credits on its own, and it cannot do anything you have not permitted — so the two settings to make deliberately are permissions and sandboxing, in that order:

/sandbox enable               # confine file access first…
/allow-all auto               # …then stop approving (alias /yolo)
/allow-all show               # the default: display actions, approve each

Review, the new bottleneck

Output doubled; review did not. The CLI's Code review agent and the /diff viewer are for your own changes before they leave the machine. Copilot code review on the PR is the first pass for everyone else's — it reads the same instruction files, so its quality is downstream of your AGENTS.md. Set it to run automatically on open or on new commits; use Balanced effort for security-sensitive or cross-service changes and the default Lite for the rest. GitHub's own wording: it is "not guaranteed to spot all problems" — a first pass that clears the boring findings so human review can spend itself on design.

Copilot as a component

copilot -p "summarise the failing tests" < test.log
copilot --plan --mode autopilot --max-autopilot-continues 10 -p "…"
git diff main | copilot -p "list any change that alters a public API"

Programmatic mode (-p) turns Copilot into a filter — scriptable from a git hook, a build script, a CI step. The Copilot SDK (GA June 2026; TypeScript, Python, Go, .NET, Rust, Java) is the same runtime as a library — planning, tool calls, file edits, streaming, MCP — for when you want your own tools in front of it, and it is the harness Microsoft Agent Framework builds on. The test for reaching for either: is this a thing I want to happen without me?

MCP — tools beyond the shell

The GitHub MCP server is preconfigured. The high-value additions are systems that hold answers your repo cannot give: the issue tracker, the observability stack, the design system, Copilot Spaces. copilot mcp add --transport http NAME URL registers one. Two disciplines: every server costs context (its tool schemas load each session — /context shows the bill), and tool output is data, not instructions — a ticket comment or a web page can carry text that reads like a command. Use read-only credentials wherever the work is read-only; that is more reliable than asking an agent not to delete things.

11Beyond the repo — ops, documents, data

Step one — give it something to read

An agent is only as useful as the context it can reach, and neither of the two things that supply it is Copilot configuration. A plain-markdown wiki in git — hosts, decisions and why, runbooks for anything done less than monthly, where the dashboards and tickets live, traps and the incident that proves them — wired in with one line in AGENTS.md or /add-dir. And CLI access to live data, because pasting is the worst option available: stale, truncated, unrepeatable. Both are the subject of the work-wiki lesson; this page assumes they exist.

Step two — find the verification loop

PowerShell's edge over bash is the one people miss: cmdlets emit objects, so | ConvertTo-Json turns any system state into something the model reasons about precisely. "Use ourtool --help to learn it, then…" teaches it a bespoke CLI in one line.

Step three — write the domain knowledge down

Every team has conventions an agent cannot guess: the naming of environments, which tenant is which, the release calendar, the ticket that explains why the weird thing is weird. Each becomes an instruction line, a skill or a wiki page — written once. The most quietly valuable is a runbook skill: "deploy the service" as a SKILL.md with the exact commands, the check at each step, and the rollback. The next incident at 2 a.m., the agent runs it and you watch.

12Away from the keyboard

The longest runs happen when you are not at the terminal, and Copilot has more ways to work unattended than any other surface of the product.

The pattern that ties them together is the one from section 04: give the unattended run a way to know it is done. A cloud task without a verification step is an hour spent on a plausible wrong PR. An /every without a condition is noise; one with "report only if the deploy status is not Succeeded" is an instrument.

13Tools on the PATH

An agent is exactly as capable as the command-line tools it can call. Copilot cannot make a PDF, query a database or lint a template by wanting to — it needs a binary on the PATH that does it and returns an exit code. Installing the right fifteen is the cheapest upgrade on this page, and on Windows winget makes it one line each.

Three selection rules. Prefer tools with a non-interactive mode — an agent cannot answer a prompt. Prefer machine-readable output (--json, ConvertTo-Json, exit codes) over pretty output — it is the difference between a check and a report. Prefer one tool that does a thing well over a GUI app with a CLI bolted on.

14The starter kit

Four files that turn the ideas above into configuration. Copy them into a repository's .github/ and adapt. Nothing here is specific to one machine, and every one of them carries both a Windows and a Unix form where that matters.

Two more ship with the work-wiki lesson and are worth taking together: an AGENTS.md template and the read-only reviewer.agent.md.

15What to do, in order

This week — thirty minutes

• Write AGENTS.md — commands, conventions that differ from the default, traps — and commit it. Nothing else on this page pays off faster.
• winget install Microsoft.PowerShell GitHub.Copilot GitHub.cli; run copilot from pwsh in Windows Terminal; press Shift+Tab into plan mode on a real task.
• Next time you correct Copilot, stop and ask: should this be a rule instead? Then write it.
• Add "run the tests and paste the summary" to the end of every brief.
• Run /usage at the end of the week and see where the premium requests went.

Next week

• Add copilot-setup-steps.yml, then /delegate one well-specified task with a verification step. Read the session log.
• One applyTo instructions file for your tests. One skill for the thing you do every Friday.
• Install the kit's hooks.json; break a test and watch agentStop catch it.
• On the next multi-module task, put it through /fleet and watch /tasks.
• Turn on Copilot code review for your repo, Lite effort, on PR open.

The month after

• Copy in the read-only reviewer agent, pin it to a strong model, and make "have @reviewer check it" the last line of every brief.
• /sandbox enable, watch a few runs, then /allow-all auto. Try /autopilot on something substantial and walk away.
• Install the Copilot app and run three sessions in parallel on three worktrees it made for you.
• Put one automation on a schedule — dependency bumps, or the weekly report — and see whether you read it.
• Write the runbook skill for the thing that pages you.

16Anti-patterns

The one-paragraph version

Give the agent a way to check its own work — in the brief, in the environment, in a hook, and in a reviewer that cannot edit — because that is the difference between a mergeable pull request and a plausible one. Write one complete brief up front instead of steering turn by turn. Guard your context like a budget: clear often, rewind past failures, delegate reading to subagents. When Copilot gets something wrong, write a rule in a committed file rather than a correction in chat, so every surface — editor, terminal, cloud and reviewer — improves at once and your setup compounds. Pick the surface by how much you intend to watch. And when the work is bigger than one agent, don't hold it in one conversation: worktrees for independent work, /fleet for parallel steps, /delegate for anything you can write as an issue, and the app when you are supervising rather than typing.