Copilot Cheatsheet

This cheat sheet is for the Engineer — keep it next to your screen. Bookmark it. Reference it constantly until it’s second nature.

Roles: “Engineer” = you, the person being trained. “Mentor” = the trainer/teacher guiding your learning.

Table of Contents

• The Golden Rule
• 1. Mode Selection Guide
• 2. Keyboard Shortcuts
• 3. Chat Participants & Variables
• 4. Custom Instructions Hierarchy
• 5. Planning Mode
• 6. Prompt Engineering
• 7. Agent Mode Best Practices
• 8. MCP Configuration
• 9. Anti-Patterns — Don’t Do These
• Quick Reference

The Golden Rule

Ask Copilot how to approach the problem before asking it to solve it. Maybe you’re solving the wrong one.

BAD:  "Build a user authentication system"
GOOD: "I need to add user authentication to my web app. What are the different
       approaches — session-based vs JWT vs OAuth? What are the tradeoffs
       for my stack? Which would you recommend and why?"

1. Mode Selection Guide

Mode progression during training:

• Day 1: Inline + NES + Ask + Inline Chat + Edit mode
• Day 2: All above + Agent mode
• Day 3 (Capstone): Agent mode as primary, others as support

2. Keyboard Shortcuts

Inline Completions

Next Edit Suggestions (NES)

Chat & Modes

General

3. Chat Participants & Variables

Participants (type @ in Chat)

Variables (type # in Chat)

Slash Commands (type / in Chat)

4. Custom Instructions Hierarchy

Copilot uses a layered instruction system. More specific instructions override more general ones.

.github/copilot-instructions.md          ← Project-wide: architecture, conventions, patterns
                                            Applied to ALL Copilot interactions in this repo

.instructions.md (with applyTo glob)      ← Scoped: rules for specific files/folders
                                            e.g., applyTo: "src/api/**" for API-specific rules

.github/copilot-instructions.md           ← Combined: project-wide + scoped = full context
   + matching .instructions.md files

AGENTS.md (project root or subdirs)       ← Agent mode only: extra rules for autonomous behavior
                                            e.g., "always run tests after changes"

.prompt.md files                          ← Reusable prompt templates for common tasks
                                            Invoked explicitly: #prompt:my-template

What to put in each:

Setup order:

1. Run Copilot’s /init command — it generates a starter copilot-instructions.md
2. Edit it to match your actual stack and conventions
3. Create .instructions.md files for specialized directories (tests, API routes, etc.)
4. Create AGENTS.md when you start using Agent mode (Day 2)
5. Create .prompt.md files for recurring tasks

5. Planning Mode

Use the /plan command in Agent mode for anything bigger than a single function.

/plan I need to add a user notification system. Users should receive
notifications when events they're interested in are updated. Design
the data model, API endpoints, and implementation plan.

Copilot will outline:

• What files to create/modify
• Step-by-step implementation plan
• Dependencies and order of operations

Review the plan. Challenge it. Then tell it to proceed.

When to use /plan

How to review a plan

1. Does it match your architecture? (right layers, right patterns)
2. Does it handle errors and edge cases?
3. Is the order logical? (data model before API, API before UI)
4. Is anything missing? (tests, validation, error handling)
5. Is it trying to do too much? (scope creep)

If the plan is wrong, tell it why: “This plan puts validation in the handler. Move it to the service layer. Also, add a step for writing tests.”

6. Prompt Engineering

The specificity spectrum

Level 1 (vague):    "Add authentication"
Level 2 (better):   "Add JWT authentication to the API"
Level 3 (good):     "Add JWT authentication with access tokens (15min expiry)
                     and refresh tokens (7d expiry). Store refresh tokens in
                     the database. Add middleware that validates the access
                     token on protected routes."
Level 4 (expert):   "Add JWT authentication following our existing middleware
                     pattern in src/middleware/. Use the jsonwebtoken library.
                     Access tokens: 15min, RS256. Refresh tokens: 7d, stored in
                     the refresh_tokens table. Add POST /auth/login,
                     POST /auth/refresh, POST /auth/logout endpoints.
                     Protect all /api/* routes. Include unit tests for the
                     auth service using our existing test patterns in __tests__/."

BAD vs GOOD prompts

BAD:  "Write tests"
GOOD: "Write unit tests for the UserService.createUser method. Test:
       - successful creation with valid input
       - validation error for missing email
       - duplicate email returns conflict error
       - database error is propagated correctly
       Use the same testing pattern as in order.service.test.ts"

BAD:  "Fix this bug"
GOOD: "This endpoint returns 500 when the user doesn't exist. It should
       return 404 with an error message. The bug is in src/handlers/user.ts.
       The service throws a NotFoundError but the handler doesn't catch it."

BAD:  "Refactor this"
GOOD: "Refactor this function to separate the HTTP concerns (request parsing,
       response formatting) from the business logic (validation, data
       transformation). The business logic should move to a service class
       that can be tested independently."

Give context, get better results

"Look at how we handle errors in src/services/order.service.ts.
 Apply the same pattern to this new user service."

"Our API follows REST conventions: POST returns 201, GET returns 200,
 not-found returns 404 with {error: message}. Follow these conventions."

"Check the existing tests in __tests__/services/ to match our testing style."

7. Agent Mode Best Practices

Scope your tasks

BAD:  "Build my entire application"
GOOD: "Add the user registration endpoint with validation, database storage,
       and unit tests. Follow the patterns in the existing order endpoint."

Agent mode works best with tasks that are:

• Specific: clear outcome, defined scope
• Bounded: one feature, one fix, one module
• Verifiable: you can tell if it worked (tests pass, endpoint works)

The autonomy trap

Agent mode can run, modify files, execute commands, and iterate on errors. This is powerful but dangerous if you give it too much scope.

Signs you’ve given too broad a prompt:

• Agent creates files you didn’t expect
• Agent modifies code outside the scope you intended
• Agent runs in circles fixing one error and creating another
• Agent’s changes don’t match your architecture

How to recover:

1. Stop the agent (click Stop)
2. Undo changes: git checkout . or review the diff carefully
3. Break the task into smaller pieces
4. Re-prompt with tighter scope

Review diffs, always

Agent mode generates diffs for you to review before accepting. Read them. Every time.

• Does the change match what you asked for?
• Does it follow your project’s patterns?
• Are there any changes outside the scope you requested?
• Does the test coverage make sense?

Use Git as your safety net

Before starting an Agent mode session:

1. Commit your current work
2. Let the agent work
3. Review the diff (git diff)
4. If it’s good, commit
5. If it’s bad, git checkout . and re-prompt

8. MCP Configuration

MCP (Model Context Protocol) extends Copilot with external tools and data sources.

Configuration file: .vscode/mcp.json

{
  "servers": {
    "my-server-name": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/dir"]
    }
  }
}

Useful MCP servers

When MCP helps

• Agent mode needs to access external APIs or databases
• You want Copilot to read documentation from a URL
• You need to interact with tools outside VS Code

9. Anti-Patterns — Don’t Do These

Quick Reference