astradevlabsastradevlabs
← All posts
Dev Tips5 min

Cheat Sheet: 7 GitHub Copilot App Slash Commands Worth Using This Week

Dev Tips

GitHub published a practical guide to GitHub Copilot app slash commands on August 6, 2026, and the updated reference docs are the real takeaway for working engineers: if you still treat the Copilot app like a blank chat box, you are doing extra work.

Slash commands are not a novelty layer on top of prompting. They are the shortest path to switching modes, splitting work, stress-testing an idea, and pushing a pull request forward without rewriting a paragraph of context every time.

The useful move is not memorizing the whole command list. It is learning the few commands that line up with a normal build-ship loop.

1. /plan when the task is still fuzzy

Start here when the request is real but the implementation is not obvious yet.

/plan switches the session into Plan mode and lets the agent outline steps before it edits files. That matters because the cheapest mistake is the one you catch before the branch starts drifting.

A good use looks like this:

text
/plan Add audit logging to admin actions without slowing the request path

Use it for migrations, auth changes, caching work, or anything where hidden dependencies usually bite.

2. /spawn when one subproblem deserves its own lane

A common failure mode with AI coding tools is piling everything into one long thread. /spawn fixes that by creating a focused child session for delegated work.

If your main session is implementing a feature and one part turns into a separate investigation, split it out instead of polluting the parent context.

text
/spawn Isolate why the image upload test fails only on CI

That keeps the main branch moving while the side quest gets its own history, branch, and reasoning trail.

3. /fleet when you want parallel answers, not one guess

The Copilot app is built around parallel workstreams, and /fleet is the command that makes that model concrete.

Use it when there is more than one plausible implementation and you want multiple agents to explore in parallel instead of asking one agent to think harder in a single lane.

text
/fleet Compare three ways to cut this Next.js route latency below 200ms

This is especially useful for performance work, refactor options, and architectural tradeoffs where the right answer is usually comparative.

4. /rubber-duck when you need critique, not momentum

Sometimes the problem is not execution speed. It is that you are already leaning toward the wrong solution.

/rubber-duck asks another model to critique the current approach. Use it before a risky refactor, before merging a large change, or when your session feels too eager to agree with you.

text
/rubber-duck Are we solving the right problem, or just hiding a cache invalidation bug?

This is the fast way to get a second opinion without starting from zero.

5. /spar when you want the agent to challenge your plan

If /rubber-duck is gentle critique, /spar is adversarial reasoning.

It is useful for launch plans, migrations, security-sensitive flows, and anything where optimism is dangerous. Instead of asking the agent to help your idea succeed, you ask it to pressure-test the idea itself.

text
/spar Challenge this rollout plan for edge cases, rollback gaps, and data-loss risks

That is a better pre-merge habit than finding out in production that your "obvious" path had one ugly branch nobody modeled.

6. /create-canvas when the output should become a shared artifact

Some work should not stay trapped in chat. /create-canvas turns a prompt into something more collaborative and reviewable.

Use it for migration checklists, API rollout notes, launch runbooks, or a side-by-side decision summary for the team.

text
/create-canvas Draft a release checklist for the new billing webhook flow

If the work needs engineering, product, or QA eyes on it, a canvas is often more useful than another transcript.

7. /pr-fix-checks when CI is the blocker

This one is pure time recovery. If you already have an open pull request with failing checks, /pr-fix-checks runs a targeted prompt against that state instead of making you restate the failure manually.

That means less "please read the logs and guess" prompting and more direct action from the actual PR context.

Use it when the branch is functionally done but CI is blocking the merge.

text
/pr-fix-checks

It is a small command, but it maps to a very real bottleneck in most teams.

The practical stack to remember

If you want a default rhythm instead of seven separate tricks, use this:

  1. Start with /plan.
  2. Break side quests into /spawn sessions.
  3. Use /fleet when you need options, not certainty theater.
  4. Run /rubber-duck or /spar before you trust a risky direction.
  5. Move team-facing output into /create-canvas.
  6. Use /pr-fix-checks when the code is done and the pipeline is not.

One last detail from GitHub's docs is worth keeping in mind: the available command list can change by context and over time. The lazy move is the correct one here. Do not memorize everything. Type /, see what is available in your current session, and pick the shortest command that matches the job.

That is the real shift in the Copilot app. Better prompting still matters, but better command selection is often what makes the workflow feel fast.

References