50 GitHub Copilot Commands, Actions, and Developer Workflows

GitHub Copilot FundamentalsLesson 11 of 13Beginner → Intermediate8 min readVersion-sensitive
Published
Updated
Last technically verified
50 GitHub Copilot Commands, Actions, and Developer WorkflowsGitHub Copilot Fundamentals11Beginner → Intermediate/github-copilot/getting-started/commands/

Most “50 Copilot commands” articles are padded with natural-language prompts presented as if they were syntax. That is not a stylistic complaint — it actively misleads people, who then type a sentence expecting a command and conclude the feature is broken.

Every entry below carries a label saying exactly what it is:

  • Official command — documented syntax you type literally in chat.
  • CLI command — documented Copilot CLI syntax you type literally.
  • Prompt — natural language. Nothing in it is a reserved word.
  • Workflow — a sequence of steps, not a single instruction.

Why the distinction matters

It is worth being concrete about what goes wrong when the four categories get blurred, because the failure is not theoretical.

A command is syntax. /explain is a reserved token the client recognises before your text reaches a model. It behaves consistently, it is documented, and it either exists in your environment or it does not.

A prompt is text. “Explain this function and identify edge cases” has no reserved words. It works because it is specific about what it wants, not because any part of it is special. Change the wording and it still works; type it in a terminal and nothing happens.

The confusion runs in both directions. People type a prompt expecting command behaviour and conclude Copilot is broken when it does not fire. And people transcribe a “command” from an article, get nothing, and assume their installation is wrong — when the string was never a command in the first place.

There is a third failure worth naming: assuming a command exists everywhere. /optimize is real, but only in Visual Studio. /simplify is real, but only in Xcode. An article listing them together without saying where they work will send you looking for a feature your editor does not have.

Availability at a glance

SurfaceWhat you get
VS Code chatThe widest slash command set, plus chat variables (#) and participants (@)
Visual Studio chatA different slash command set, and file references instead of chat variables
JetBrains chatCore commands, plus CLI-specific commands during a CLI session
Xcode chatA small, focused set centred on the current selection
GitHub.com chatConversation management commands, plus @ mentions and MCP skills
Copilot CLIBy far the largest surface: shell commands, slash commands and options

Notice that the concept is consistent everywhere — commands for common operations, a syntax for supplying context — while the specific tokens are not. Learning the concepts transfers; memorising a token list does not.

Chat slash commands in IDEs

Type / in a chat prompt box, followed by the command name.

Chat commands on GitHub.com

Chat context syntax

Slash commands tell Copilot what to do. Context syntax tells it what to look at, and it is the more consequential of the two.

The reason is straightforward: a slash command with the wrong context produces a confident answer about the wrong code. /explain on a file you did not mean to have focused is not a malfunction — it is a correct explanation of something irrelevant. Being explicit about context removes an entire category of confusing results.

Chat variables include specific context in a prompt. Type # in the prompt box. These are documented for VS Code.

Copilot CLI — command line

Copilot CLI has a considerably larger command surface than any chat interface, for a structural reason: it is an agent with a permission model, session management and its own configuration, so it needs commands for all three.

The commands below split into three groups. Shell commands (copilot login, copilot init) are typed at your prompt. Slash commands (/plan, /review) are typed inside a running session. Options (--model, --allow-all-tools) modify how a session starts. Mixing them up is the most common CLI mistake — /plan at a shell prompt does nothing, and --model inside a session is just text.

Run these from your shell.

Copilot CLI — slash commands

Type these inside an interactive session.

Prompts, not commands

These are natural language. Nothing in them is reserved syntax, and nothing is guaranteed — they work because they are specific, not because they are special.

Workflows

Sequences rather than single instructions.

Building a command habit

Fifty entries is a reference, not a curriculum. In practice most developers settle on a small working set and reach for the rest occasionally. Here is a reasonable progression.

Week one — comprehension. Use /explain and the context syntax, nothing else. The goal is to build the reflex of supplying context deliberately rather than hoping the right thing is focused. #file, #selection and #function cover almost everything at this stage.

Week two — the feedback loop. Add /tests and /fix, and start reading what they produce rather than applying it. This is where you calibrate: you learn what Copilot gets right in your codebase and what it consistently gets wrong, which is knowledge no article can give you.

Week three — the CLI. Install it, run copilot init in a repository you know well, and use /plan before /review. Planning before implementing is the single habit that most improves agent output, and the CLI makes it explicit.

Ongoing — permissions and cost. /permissions show and /usage are the two you should check periodically rather than daily. The first tells you what an agent may do without asking; the second tells you what your sessions are costing. Both are easy to leave unexamined until something surprises you.

Common mistakes

Typing a prompt as a command. /refactor this to be faster is not a command in any documented environment. /fix is; the rest of that string is just text following it.

Assuming cross-editor parity. Checked above, worth repeating: the sets genuinely differ, and the differences are not obvious from the names.

Using allow-all to move faster. It works, and it removes the boundary that makes an agent with shell access safe. Reserve it for disposable environments.

Ignoring /plan because it feels like overhead. Reviewing a plan takes a minute. Reviewing a wrong implementation takes considerably longer, and unwinding one takes longer still.

Treating /review or /security-review as sufficient. Both are useful first passes that clear obvious findings before a human looks. Neither is a review, and neither can tell you that a change is wrong given something happening elsewhere in the system.

What is not on this list

Copilot CLI alone documents considerably more slash commands and options than appear here — /fleet, /research, /rubber-duck, /autopilot, /worktree, /skills, /agent, /share, /session, /limits and many more, plus a large set of command-line options.

They are omitted because this is Cluster 1, and the entries above are the ones worth knowing in your first weeks. Copilot CLI gets a full cluster later in the Academy roadmap; for the complete surface, GitHub’s CLI command reference is authoritative and is linked in the sources below.

How to find what is actually available

The single most useful habit on this page:

  • In chat, type / and read the list. It reflects your editor, version and context.
  • In Copilot CLI, run /help in a session, or copilot help from the shell.
  • For options, run copilot help and the topic — billing, config, commands, environment, logging, monitoring, permissions, providers or sandbox.

Any article, including this one, is a snapshot. Your own environment is the authority.

Sources

Every version-sensitive claim on this page was checked against first-party documentation. Only sources actually used are listed.

Primary sources