Most of the productivity advice I read about AI coding tools misses the part that actually matters. Nobody wakes up excited about a feature list. What moves the needle for me is friction, specifically the small repeated moments where a tool saves me ten clicks or forces me through three menus I do not care about. Slash commands in the GitHub Copilot desktop app fall in the first category, and I think they are the most under-used feature in the whole product.
If you have opened the chat composer and typed a forward slash, you have seen the autocomplete menu. Most people close it and keep typing full sentences, which is the same reflex everyone had with terminal history completion circa 2010. The thing that took me a while to internalize is that the slash menu is not a list of shortcuts for the lazy. It is a way of declaring intent to the model before you start talking. Once you start using it that way, your chats get noticeably shorter and your edits get noticeably fewer.
I have spent a few weeks rebuilding my desktop workflow around three specific commands. None of them are fancy. All of them are now load-bearing for how I work in the app. Here is what they are, what they replace, and where each one is honestly not the right tool.
The slash menu is a workflow contract, not a typing shortcut
The mental model that finally clicked for me is that slash commands tell Copilot what kind of conversation you are about to have. The chat interface is open-ended by default, which sounds flexible until you realize it leaves the model guessing about scope, mode, and persistence on every single turn. A slash command collapses that guessing into one keystroke.
The menu adapts to context. In a chat tied to a project, the project-management commands show up. In a chat tied to a single file, the file-scoped commands show up. In an empty chat, you get the universal ones. This is the part that gets confused with the CLI slash-command story, and the two are not the same product at all. The CLI version of Copilot leans on slash commands because there is no visual interface to lean on. The desktop app has the visual interface, so the slash commands lean on context instead.
If you bounced from the CLI into the desktop app and felt like slash commands were vestigial, that is probably why. You were comparing them to a tool that needed them more. The desktop commands are quieter and more contextual, and the value is in the discipline of choosing one before each chat starts.
Things to know about how the menu behaves:
- The list changes based on what file or project you have open, so there is no point memorizing a static reference.
- CLI-only commands (such as file-system flags) do not show up in the app, and that is by design.
- The commands the app adds focus on session management, not on plumbing, because the app already knows your plumbing.
/plan is the one I wish I had started using in month one
/plan is the command that earned its place at the top of my list, and it is also the one I avoided the longest. The reason I avoided it is that I thought it was ceremony. You have a question, you ask the question, you get an answer. Why would you ask the model to plan first?
The reason is that without /plan, the model does not just answer your question. It also starts writing code, which you cannot easily roll back once it has touched a few files. With /plan, the model commits to a written breakdown before it touches anything. You can push back. You can ask it to drop a step. You can fold two bullet points into one. None of that is possible once the model has started editing.
My current pattern is simple. I open a chat, type /plan, then describe the goal in the same language I would use with a junior engineer. I tell Copilot which files I think are in scope, what the user-visible behavior should be, and what I am not sure about. Then I read the plan. If the plan looks right, I switch out of plan mode and let it write code. If the plan looks wrong, I push back until it does not.
The amount of work this has saved me is not subtle. I used to discard entire chat sessions because the agent went off in the wrong direction for fifteen minutes. Now I redirect before any code is written, and the cost of being wrong is one paragraph of pushback instead of a full revert.
When /plan earns its slot:
- The task touches more than one file, especially files that depend on each other.
- The requirements feel fuzzy in your own head, which is the honest signal that the model will not guess right either.
- You have been burned before by the agent going off in the wrong direction on a similar task.
- You want a paper trail of why a change was made, which
/plangives you for free.
/clear and /model are the cleanup crew, and they pay back faster than you think
Two more commands deserve to be in your permanent rotation, and they are the ones I think most people treat as cosmetic. Neither one is cosmetic. Both of them change how the next message in a chat performs.
/clear ends the current session. That is it. There is no archive, no summary, no graceful handoff. The chat is gone, the context is gone, and the next message goes to a model with no memory of anything you said before. The reason this matters is that long chat sessions accumulate noise. After twenty turns, the model is carrying every tangent, every failed attempt, every clarification that turned out to be wrong. That history is helpful inside the chat it belongs to and actively harmful when you start something new in the same session.
/model lets you swap which underlying model Copilot is using for the conversation. The reason this matters is that different models are good at different things. A faster, cheaper model is fine for renaming variables, fixing typos, and writing tests. A heavier reasoning model is the right call for architecture decisions and weird bugs. You can switch mid-chat, the switch takes effect on the next message, and the cost of switching is roughly the time it takes to type the command.
How I use both together in a normal day:
- Start each task in a fresh chat with
/clear, especially after finishing something unrelated. - Pick the model in the same step: heavy model for design and debugging, lighter for edits and tests.
- Switch models mid-task if I notice the current model is flailing or producing bloated output.
- Re-clear before pivoting to a different part of the codebase, even within the same project.
The combined effect is that my chats are short, on-topic, and noticeably cheaper than they used to be when I let everything pile up in one giant conversation.
The app-specific commands are where things get interesting
Once you have the three commands above wired in, the rest of the slash menu becomes worth exploring. The desktop app has commands that simply do not exist in the CLI because the CLI has no concept of sessions in the same way. Things like switching between conversations, pinning a project, or controlling how aggressively the agent touches files all live behind slash commands in the app.
I am not going to list every command, partly because the list changes and partly because the menu in your app already tells you what is available right now. What I will say is that the highest-value discovery I made in the last month was clicking through the autocomplete menu while I was bored, reading the names out loud, and trying the ones that sounded obvious. Most of the commands that save me the most time were not the ones I went looking for. They were the ones I stumbled into.
If you are installing the app for the first time, give yourself fifteen minutes to do this. Open the composer. Type a slash. Read the menu. Try three commands you have never used. The return on this is going to be better than reading the release notes.
Trade-offs
Nothing about slash commands is free, and pretending otherwise would make this less useful than it should be. The honest list is short and worth knowing up front.
Memory is the first cost. Slash commands only autocomplete if you remember the syntax, and the first week you try them, you will forget. The second week it starts to click. By the third week it is muscle memory. The awkward first week is the real price.
Portability is the second cost. If you bounce between the CLI and the desktop app, you will sometimes type a CLI-only command into the app and feel dumb for a second. That is a small annoyance, not a real problem, but it is the kind of thing that erodes confidence in the first few days.
Coverage is the third cost. The slash menu does not surface every feature, and there are places in the app where you would expect a slash command to exist and it does not. The app does not always put the shortcut where you would naturally look for it. That is a documentation gap as much as it is a feature gap.
The upside is also real. Once you build a small habit around two or three commands that match how you actually work, the day gets a little faster and a little calmer. You stop hunting through menus. You stop repeating yourself. You stop losing context between tasks. That is the win, and it is worth the awkward first week.
What I would tell past me starting over
If I were sitting down with the desktop app for the first time tomorrow, here is what I would do in order. I would open the app, open the chat composer, and type a slash to see the menu. I would not try to learn every command. I would pick /plan and use it for everything that touched more than one file for a week. I would add /clear once I noticed my chats were getting long. I would add /model once I had a task where the lighter model was clearly flailing.
After that, I would stop adding commands and just use the menu when I did not know what I wanted. The whole point of slash commands is that they are cheap to try, and you do not need to be an expert to get the value out of them. Pick three. Use them. Add more when the menu shows you one that fits a real friction point in your day. That is the whole curriculum.