GitHub Copilot App Slash Commands: What Each One Does
A practical breakdown of GitHub Copilot app slash commands including /plan, /spar, and /autopilot, what they do and when to use them.
GitHub has published a guide to slash commands in the Copilot desktop app, explaining how typing a single / in the chat composer opens a context-aware menu of workflow shortcuts. The commands go beyond what the CLI offers: rather than managing terminal access or working directories, app commands like /plan, /spar, and /autopilot are built around multi-session, visual workflows. Here is what each command actually does and when it earns its place in a development routine.
What happened
GitHub published a guide to slash commands in the Copilot desktop app. The commands are typed directly into the chat composer. Typing / triggers an autocomplete menu that shows which commands are available in the current context.
| Command | What it does |
|---|---|
| /plan | Switches the session to Plan mode; breaks down a task before coding starts |
| /spar | Has Copilot challenge your approach and surface risks or tradeoffs |
| /autopilot | Switches to Autopilot mode; Copilot works through implementation steps toward a stated goal |
| /clear | Clears the current session (also available in the CLI) |
| /model | Changes the active model (also available in the CLI) |
How app commands differ from CLI commands
If you already use slash commands in the Copilot CLI, the names will look familiar. Commands like /clear and /model work in both places. The difference is in scope.
CLI commands are built for a terminal-first workflow where there is no visual interface. That is why the CLI has commands like /add-dir and /cwd to manage file access manually. The desktop app handles project context automatically, so those commands are not needed there. App commands focus instead on session management, planning, and agent behavior.
What each major command does
/plan: think before you type
/plan switches the session into Plan mode (the same mode you can select from the Mode dropdown in the chat composer). It is designed to be used before you write any code. You give it a task description, and Copilot identifies relevant files, components, and dependencies, outlines an implementation approach, and flags potential risks.
The GitHub guide suggests three practical uses:
- Breaking down a new feature, such as adding two-factor authentication, to map the files that need to change.
- Preparing a large refactor, for example restructuring a notification system to support new delivery channels.
- Triaging a bug when you know something is wrong but are not sure where to start.
/spar: pressure-test your approach
/spar positions Copilot as a critic. You pitch an approach and Copilot argues against it, raising questions about assumptions, edge cases, and tradeoffs you may have missed. According to the GitHub guide, good use cases include:
- Validating an architecture choice, such as using Redis as a caching layer, by having Copilot question the invalidation strategy and scalability.
- Comparing REST versus GraphQL for a specific application context.
- Reviewing a database migration plan for hidden risks before the work starts.
- Challenging a performance optimization, like lazy loading, by asking Copilot to identify where it could hurt user experience.
/autopilot: hand off the implementation
Once you have a plan, /autopilot switches the session to Autopilot mode. You give Copilot a goal rather than managing each individual step. Copilot works through the implementation, makes changes, and iterates. The guide positions it as the natural follow-on to /plan: plan first, then hand off execution.
Why it matters
The practical value here is keeping developers in flow. Switching between planning tools, documentation, and a chat interface breaks focus. Having /plan, /spar, and /autopilot inside the same composer means you can move from idea to review to implementation without leaving the app or context-switching to a separate tool.
For teams already using GitHub Copilot, this is also a gentle push toward a more structured workflow: plan before you code, challenge the plan before you commit, then execute. That sequence reduces the cost of late-stage rework, which tends to be where projects lose the most time.
Businesses exploring how to get more consistent output from AI-assisted development should look at how AI integration into existing workflows can reduce that rework cost at the team level, not just for individual developers.
Our take
The /spar command is the most underrated of the three. Most developers are pretty good at using AI to generate code. Fewer use it to stress-test the plan before a single line is written. A five-minute /spar session before a complex architectural decision is a cheap way to catch the kind of problem that otherwise shows up three sprints later.
/plan and /autopilot are useful, but they depend on the quality of your prompt. Vague inputs still produce vague outputs. The mode-switching framing is a sensible UX choice: it signals to both the user and the model that the goal has shifted from generating to planning or executing.
One thing worth noting: the guide does not cover how well these commands perform across different project sizes or model choices. The /model command lets you switch models, which suggests the behavior of /spar or /plan may vary depending on which model is active. That is worth testing on your own codebase before committing to a workflow built around any one of these commands. For context on how AI agents perform at scale, our coverage of Meta’s Muse Code agent for large codebases is a useful reference point.
What to do about it
- Open the GitHub Copilot desktop app and type / in the chat composer to see which commands are currently available in your context.
- Use /plan on your next feature ticket before opening any files. Compare the output to how you would have approached it manually.
- Run /spar on one architectural decision this week, particularly one your team has already agreed on. The pushback may surface something useful.
- Use /model to check which model is active, then test /plan and /spar with different models to see if output quality varies for your specific project type.
The simplest starting point: use /plan once before your next feature branch and see whether it changes what you build first.
Frequently asked questions
What are slash commands in the GitHub Copilot app?
Slash commands are text shortcuts typed directly into the Copilot app's chat composer. Typing / opens an autocomplete menu showing commands available in the current context, such as /plan, /spar, and /autopilot.
What does /plan do in GitHub Copilot?
/plan switches the session into Plan mode. It helps you break down a task before writing code, identify relevant files and dependencies, and outline an implementation approach including potential risks.
What is the difference between GitHub Copilot CLI slash commands and app slash commands?
CLI slash commands are designed for terminal-first workflows and include commands for managing directories and file access. App slash commands focus on session management, planning, and agent behavior, since the app handles file context automatically.
What does the /spar command do in GitHub Copilot?
/spar has Copilot challenge your approach by questioning assumptions, pointing out tradeoffs, and identifying edge cases or risks before you commit to a solution. It is useful for pressure-testing architecture choices, API design decisions, and migration plans.
