Getting Started with GitHub Copilot CLI

$ Getting Started

▸ Installation winget install GitHub.Copilot beginner

GitHub Copilot CLI is a terminal-native AI coding agent that lives where developers already work — the command line. Think of it as having a senior developer pair programming with you, right in your terminal.

What makes it special:

• It reads your entire project — file structure, git history, open issues

• It can edit files, run commands, and create PRs — all with your approval

• It works across any language, framework, or toolchain

• It respects your project conventions via instruction files

Installation options:

Windows:

winget install GitHub.Copilot

macOS / Linux:

brew install copilot-cli

Cross-platform via npm:

npm install -g @github/copilot

Quick install script:

curl -fsSL https://gh.io/copilot-install | bash

Requirements:

• GitHub account with Copilot subscription (Individual, Business, or Enterprise)

• Node.js 18+ (for npm install method)

• Git installed and configured

• Terminal that supports ANSI colours (most modern terminals)

After installation, verify with:

copilot --version

Then just type 'copilot' to launch your first session.

💡 Run 'copilot --banner' to see the startup animation again. Use 'copilot --help' for a complete flag reference. On Windows, use Windows Terminal for the best visual experience.

▸ Authentication /login beginner

Before you can use Copilot CLI, you need to authenticate with your GitHub account. The CLI supports multiple authentication methods depending on your environment.

Browser-based OAuth (recommended for local development):

1. Run 'copilot' — it will prompt you automatically on first launch

2. Alternatively, use the /login slash command inside a session

3. A browser window opens with a device code

4. Confirm the code and authorise the app

5. You're authenticated — the token is stored securely in your OS keychain

Personal Access Token (for CI/CD, servers, containers):

1. Visit github.com/settings/personal-access-tokens/new

2. Select "Fine-grained" token type

3. Add the "Copilot Requests" permission

4. Generate and copy the token

5. Set environment variable:

export GH_TOKEN=github_pat_xxxxx

(or GITHUB_TOKEN — both work)

GitHub CLI integration:

If you already use 'gh' and are logged in, Copilot CLI inherits that session automatically. No additional auth needed.

Enterprise considerations:

• SSO-enabled organisations may require token re-authorisation

• Copilot Business/Enterprise policies are enforced at the org level

• Your admin controls which models and features are available

• Content exclusion policies apply based on org settings

Troubleshooting auth:

• Run '/logout' then '/login' to force re-authentication

• Check 'gh auth status' if using GitHub CLI integration

• Verify your subscription at github.com/settings/copilot

💡 PAT auth is essential for CI/CD pipelines, Docker containers, and headless servers. For local development, browser OAuth is simpler and auto-refreshes. Your token is stored in the OS credential manager — never in plain text files.

▸ First Conversation copilot beginner

Your first Copilot CLI session sets the tone for everything that follows. Here's how to make it productive from minute one.

Launching:

cd ~/my-project # Navigate to your project

copilot # Start a session

What happens on launch:

1. The CLI scans your working directory for context

2. It reads any instruction files (.github/copilot-instructions.md, CLAUDE.md, etc.)

3. It loads configured MCP servers and skills

4. The model (default: Claude Sonnet 4.5) is ready for your first prompt

Your first prompts — try these:

• "Explain the architecture of this project"

• "What does the main entry point do?"

• "Find all TODO comments and summarise them"

• "Add error handling to the API routes"

Understanding the response:

• The agent shows its reasoning (toggle with ctrl+t)

• File reads appear as expandable sections

• Code changes show as diffs — you approve each one

• Commands are previewed before execution

Context awareness:

The agent automatically knows:

• Your current directory and file structure

• Git branch, recent commits, and uncommitted changes

• Package manifests (package.json, requirements.txt, etc.)

• CI/CD configuration files

• README and documentation

Session persistence:

Your conversation is saved automatically. Come back later with '/resume' to continue where you left off. Use '/session' to manage and name sessions.

💡 Always launch from the ROOT of your git repository for maximum context. The agent performs better when it can see the full project structure. Use 'copilot --model gpt-5' to start with a specific model.

▸ Interaction Modes shift+tab beginner

Copilot CLI offers different interaction modes that balance agent autonomy against your control. Understanding these modes is key to an effective workflow.

Switching modes:

Press Shift+Tab to cycle through available modes. The current mode is shown in the prompt indicator.

ASK MODE (default — safest):

• The agent answers questions and explains code

• It CANNOT modify files or run commands

• Perfect for: learning, exploring, understanding code

• Use when: you want answers without any side effects

• Prompt indicator: [ask]

EDIT MODE (recommended for development):

• The agent can propose file edits and command execution

• Each change requires YOUR explicit approval (y/n)

• You see a full diff before accepting

• Perfect for: daily development, refactoring, bug fixes

• Use when: you want AI assistance with a safety net

• Prompt indicator: [edit]

AGENT MODE (maximum productivity):

• The agent works autonomously — reading, writing, running

• It still asks before destructive operations

• Can chain multiple steps without interruption

• Perfect for: complex multi-file tasks, greenfield projects

• Use when: you trust the agent and want speed

• Prompt indicator: [agent]

Tips for choosing:

• Start with Ask mode when exploring unfamiliar codebases

• Use Edit mode for your daily workflow — best balance of speed and safety

• Reserve Agent mode for well-defined tasks where you're confident in the outcome

• You can switch modes mid-conversation as your confidence grows

Per-project defaults:

Set a default mode in your copilot-instructions.md:

Prefer edit mode for this repository.

💡 You can switch modes mid-conversation without losing context. Start in Ask to understand a problem, switch to Edit to implement the fix. The mode only affects what actions the agent CAN take — it always tries to help regardless of mode.

> Core Commands

▸ File Mentions @ — mention files beginner

The @ symbol is your precision tool for giving the agent exactly the context it needs, without relying on automatic file discovery.

File mentions:

• @src/auth.js — reference a specific file

• @package.json — reference config files

• @src/components/ — reference an entire directory

• @. — reference current directory listing

Why use @ mentions:

1. Faster responses — the agent doesn't need to search

2. Accurate context — you control what it sees

3. Large codebases — auto-discovery might miss key files

4. Cross-references — connect related files explicitly

Real-world examples:

"@src/api/routes.js add rate limiting to the POST /users endpoint"

? Agent reads routes.js and makes targeted changes

"@package.json @tsconfig.json upgrade to TypeScript 5.5"

? Agent sees both configs and updates consistently

"@src/models/ create a new User model following the existing patterns"

? Agent reads the directory to understand your conventions

"@README.md update the API documentation to match @src/api/"

? Agent cross-references code with docs

Advanced patterns:

• Mention test files alongside source: "@src/auth.js @tests/auth.test.js fix the failing test"

• Reference examples: "@examples/basic.js create a similar example for the new feature"

• Include schemas: "@db/schema.prisma add a comments table with relations"

💡 Always mention both the source file AND its test file when making changes — this helps the agent maintain test coverage. Use @. at the start of a session to orient the agent in unfamiliar projects.

▸ Issue References # — mention issues/PRs beginner

Reference GitHub issues and pull requests directly in your prompts to give the agent rich context about what needs to be done.

Basic usage:

• #42 — reference issue or PR by number

• #bug-report — search issues by title keywords

What the agent gets from issue references:

• Issue title and description

• All comments and discussion

• Labels, assignees, and milestones

• Linked PRs and cross-references

• Code snippets mentioned in the issue

Powerful patterns:

"Fix #42"

? Agent reads the issue, understands the bug, finds relevant code, implements the fix

"Implement the feature described in #128"

? Agent reads the full feature request and creates an implementation

"Address the review comments on #pr-85"

? Agent reads PR review comments and makes the requested changes

"Create a PR that closes #42 #43 #44"

? Agent implements fixes for multiple issues in one PR

Working with PRs:

• /pr — interact with the current branch's PR

• "Review the changes in #pr-92 and suggest improvements"

• "Update #pr-92 based on the latest review feedback"

Tips for best results:

• Write detailed issue descriptions — the agent uses them as specs

• Include reproduction steps in bug reports — the agent will follow them

• Reference related issues: "Fix #42 (related to #38)"

• Use issue templates for consistent context

💡 Write your GitHub issues as if they were specifications for an AI agent — clear acceptance criteria, reproduction steps, and expected behaviour. The better the issue, the better the fix Copilot generates.

▸ Shell Commands ! — execute shell beginner

The agent can execute shell commands as part of its workflow, and you can also run commands directly from the prompt with the ! prefix.

Manual command execution:

• !git status — check git state

• !npm test — run tests

• !ls -la — list files

• !docker ps — check containers

How the agent uses commands:

When working on a task, the agent will often need to:

1. Run tests to verify changes work

2. Check build output for errors

3. Install dependencies

4. Run linters or formatters

5. Check git state before committing

Safety model:

• In Ask mode: agent CANNOT run commands

• In Edit mode: agent shows each command and waits for approval

• In Agent mode: agent runs commands but still asks for destructive operations

• You always see the command before it executes

• Press ctrl+c to cancel any running command

Common workflows:

"Run the tests and fix any failures"

? Agent runs test suite, reads output, fixes failing tests, re-runs to verify

"Install React and set up a basic component structure"

? Agent runs npm install, creates files, runs build to verify

"Find and fix all linting errors"

? Agent runs linter, reads errors, fixes each one, re-runs to confirm clean

Background commands:

Long-running commands can be moved to the background with ctrl+x ? b. You'll be notified when they complete. This lets you continue working while tests run.

💡 The agent is smart about command output — it reads stderr/stdout and reacts to errors automatically. If a test fails after its change, it will try to fix it without you needing to ask.

▸ Keyboard Shortcuts ctrl+c, ctrl+d, ctrl+l beginner

Master these keyboard shortcuts to navigate Copilot CLI like a power user. They're designed to feel natural if you're familiar with terminal emulators or vim.

Session control:

• ctrl+c — cancel current operation (agent stops mid-response)

• ctrl+c ×2 — exit the CLI entirely

• ctrl+d — graceful shutdown (saves session)

• ctrl+l — clear screen (conversation preserved)

• ctrl+z — suspend to shell (fg to return)

Prompt editing:

• ctrl+a — jump to beginning of line

• ctrl+e — jump to end of line

• ctrl+w — delete previous word

• ctrl+u — delete to beginning of line

• ctrl+k — delete to end of line

• ctrl+h — delete previous character (backspace)

• meta+?/? — move cursor by word

• ctrl+g — open prompt in $EDITOR (vim, code, etc.)

Display & navigation:

• ctrl+t — toggle reasoning display (see the agent think)

• ctrl+o — expand all timeline nodes

• ctrl+e — collapse all timeline nodes

• ctrl+s — submit prompt and preserve input buffer

Task management:

• ctrl+x ? b — move current task to background

• ctrl+x ? t — switch to task list

• ctrl+x ? s — open session switcher

Advanced:

• shift+tab — cycle interaction mode (Ask ? Edit ? Agent)

• tab — accept suggestion / autocomplete

• ?/? — scroll through prompt history

Pro tip — key combinations:

ctrl+g opens your full $EDITOR for complex prompts. Write multi-paragraph instructions in vim or VS Code, save and close, and the text becomes your prompt. Essential for complex, multi-step instructions.

💡 ctrl+t (toggle reasoning) is your best debugging tool. When the agent does something unexpected, enable reasoning to see WHY it made that decision. ctrl+g is a game-changer for writing complex prompts — use your editor instead of the single-line input.

▸ Input Editing ctrl+a, ctrl+e, ctrl+w intermediate

Efficient prompt editing makes the difference between fighting the input and flowing with it. These shortcuts mirror readline/emacs bindings used across Unix tools.

Movement:

• ctrl+a — cursor to start of line

• ctrl+e — cursor to end of line

• meta+f (or meta+?) — forward one word

• meta+b (or meta+?) — back one word

• ctrl+f — forward one character

• ctrl+b — back one character

Deletion:

• ctrl+w — delete previous word (kill ring)

• ctrl+u — delete from cursor to start

• ctrl+k — delete from cursor to end

• ctrl+h — delete character before cursor

• ctrl+d — delete character at cursor

Clipboard (kill ring):

• ctrl+y — paste (yank) last killed text

• meta+y — cycle through kill ring

The $EDITOR escape hatch:

Press ctrl+g to open your prompt in your configured $EDITOR:

• Set EDITOR=code for VS Code (use code --wait)

• Set EDITOR=vim for Vim

• Set EDITOR=nano for Nano

This is incredibly powerful for:

• Multi-line prompts with code examples

• Carefully crafted instructions with formatting

• Pasting in requirements from other documents

• Editing a complex prompt you're iterating on

History:

• ?/? — scroll through previous prompts

• ctrl+r — reverse search through history

• ctrl+p/ctrl+n — previous/next (same as arrows)

💡 Set EDITOR="code --wait" in your shell profile for seamless VS Code integration with ctrl+g. The kill ring (ctrl+w, ctrl+u, ctrl+k) lets you cut text and paste it elsewhere in your prompt with ctrl+y — just like Emacs.

/ Slash Commands

▸ Model Selection /model beginner

Copilot CLI supports multiple AI models, and you can switch between them mid-conversation. Each model has different strengths.

Switching models:

/model — show available models and select

copilot --model gpt-5 — launch with a specific model

Available models (as of 2025):

• Claude Sonnet 4.5 — default, excellent at code generation and multi-step reasoning

• Claude Sonnet 4 — fast, great for quick tasks and explanations

• GPT-5 — strong at natural language tasks and creative generation

• GPT-4.1 — fast and cost-effective for simple queries

Model strengths:

Claude Sonnet 4.5 (default):

Best for: complex refactoring, architecture decisions, multi-file changes, debugging

Personality: thorough, precise, follows instructions carefully

Claude Sonnet 4:

Best for: quick code reviews, simple edits, Q&A

Personality: concise, fast, good balance of speed/quality

GPT-5:

Best for: creative tasks, documentation, natural language processing

Personality: verbose, creative, broad knowledge

Choosing the right model:

• "Help me design a microservices architecture" ? Claude Sonnet 4.5

• "What does this regex do?" ? Claude Sonnet 4 (fast answer)

• "Write creative user-facing copy for this feature" ? GPT-5

• "Fix this typo" ? Any model (trivial task)

Cost:

Each prompt uses one premium request regardless of model choice. There's no cost difference between models, so choose based on capability, not price.

💡 Stick with Claude Sonnet 4.5 as your default — it's the best all-rounder for coding tasks. Switch to GPT-5 when you need more creative or conversational output. You can switch mid-session without losing context.

▸ Code Review /diff and /review intermediate

Before you commit or create a PR, use Copilot's review capabilities to catch issues a human reviewer would flag.

Available commands:

• /diff — review uncommitted changes in your working directory

• /review — launch the full code review agent

• /pr — interact with pull requests for the current branch

/diff — Quick change review:

Shows your git diff and provides immediate feedback on:

• Potential bugs or logic errors

• Security concerns

• Missing error handling

• Inconsistencies with existing code patterns

/review — Deep analysis:

Launches a dedicated review agent that performs a thorough analysis:

• Reads all changed files and their surrounding context

• Identifies bugs, security vulnerabilities, and logic errors

• Only surfaces HIGH-SIGNAL issues (no style nitpicks)

• Provides specific fix suggestions with code

/pr — Pull Request workflow:

• "Create a PR with a good title and description"

• "Update the PR description based on latest changes"

• "Address review comment about error handling"

Real workflow example:

1. Make your changes

2. /diff — quick sanity check

3. Fix any issues found

4. /review — thorough analysis before PR

5. Address all findings

6. /pr — create the pull request with auto-generated description

What /review catches that linters miss:

• Race conditions in async code

• Incorrect error propagation

• Missing null checks in specific contexts

• Business logic errors

• SQL injection and XSS vulnerabilities

• Incorrect API usage patterns

💡 /review runs a high-signal code review that focuses exclusively on bugs, security issues, and logic errors. It deliberately ignores formatting, naming conventions, and style. Use it as your pre-PR checklist — it catches things humans often miss in review.

▸ Session Management /session, /resume, /compact intermediate

Effective session management keeps your context fresh and your workflow organised across multiple tasks and days.

Session commands:

• /session — view current and previous sessions

• /resume [id|name|task] — switch to a different session

• /rename [name] — give your current session a descriptive name

• /compact — summarise history to free context window

• /share — export session as markdown, HTML, or gist

• /clear — abandon session completely and start fresh

• /context — visualise token usage in current context

• /new — start a fresh session (previous one is saved)

Session lifecycle:

1. Start: 'copilot' begins a new session automatically

2. Work: your conversation is saved continuously

3. Leave: close terminal or ctrl+d — session persists

4. Resume: '/resume' to continue where you left off

5. Complete: '/clear' when the task is fully done

Managing context effectively:

The context window is finite (~100k-200k tokens depending on model). When it fills up:

• The agent starts forgetting earlier decisions

• Responses may contradict previous work

• You notice repeated questions

Fix with /compact:

• Summarises the entire conversation history

• Preserves key decisions and file changes

• Frees up 60-80% of context space

• Agent continues with full understanding

Naming sessions:

/rename auth-refactor

/rename bug-fix-login-flow

/rename feature-user-dashboard

Good names make /resume instant — you can jump to any named session by name.

💡 Name every session the moment you start meaningful work — /rename is instant and makes resuming trivial. Use /compact proactively when you're halfway through a large task, not when the agent starts losing context. Use /context to monitor usage.

▸ Research Mode /research intermediate

Need deep research on a topic? The /research command launches a specialised agent that searches across GitHub and the web to produce comprehensive reports.

Launching:

/research [your question]

What the research agent does:

1. Breaks your question into sub-queries

2. Searches across GitHub repositories (code, issues, discussions)

3. Fetches and analyses web sources

4. Cross-references findings for accuracy

5. Produces a structured report with citations

Example research prompts:

"Research best practices for rate limiting in Express.js APIs"

? Finds real implementations, compares approaches, recommends solutions

"Research how other projects handle database migrations in monorepos"

? Searches GitHub for real-world migration strategies

"Research the differences between Bun, Deno, and Node.js for production APIs"

? Compares across multiple dimensions with sources

"Research security best practices for Azure Container Apps"

? Finds Microsoft docs, community solutions, and real configs

What you get back:

• Executive summary (key findings in 2-3 sentences)

• Detailed analysis with sections

• Code examples from real repositories

• Links to sources (GitHub repos, docs, articles)

• Recommendations with trade-off analysis

Research vs regular prompts:

Regular: uses the model's training data (may be outdated)

Research: searches live sources (current and verified)

Use /research when:

• You need current information (post-training cutoff)

• You want verified sources and citations

• You're evaluating options and need comparison data

• You're learning a new technology or pattern

💡 Share research findings with /share to create team knowledge bases. Research results are kept in your session, so you can reference them in follow-up prompts: "Based on the research, implement option 2".

▸ Planning /plan intermediate

For complex tasks, planning before coding leads to dramatically better results. The /plan command creates a structured implementation roadmap.

Usage:

/plan [description of what you want to build]

What /plan produces:

• Problem statement (what you're solving)

• Proposed approach (how you'll solve it)

• Step-by-step tasks (ordered, with dependencies)

• Technical decisions (trade-offs documented)

• Edge cases and considerations

Example:

/plan Add authentication to our Express API using JWT with refresh tokens

The agent produces:

1. Problem: API currently has no auth

2. Approach: JWT with access + refresh token pattern

3. Tasks:

- Create User model with password hashing

- Build /auth/login and /auth/register endpoints

- Implement JWT signing and verification middleware

- Add refresh token rotation

- Protect existing routes with auth middleware

- Add tests for all auth flows

4. Decisions: bcrypt for hashing, 15min access token, 7d refresh

5. Edge cases: token expiry during request, concurrent refresh

Working with plans:

• The plan is saved in your session

• Reference it: "Implement step 3 from the plan"

• Update it: "Add rate limiting to the plan"

• Track progress: the agent remembers what's done

When to plan:

• Multi-file changes (3+ files)

• Architectural decisions

• New features with multiple components

• Refactoring that touches many modules

• Any task that would take more than 30 minutes manually

Plans make delegation better:

A good plan + /delegate = the agent creates a complete PR while you context-switch to other work.

💡 Always /plan before tackling multi-file changes. The investment of 2 minutes planning saves 20 minutes of rework. Plans also help the agent stay on track during complex tasks — it has a checklist to follow.

▸ Delegation /delegate advanced

The most powerful workflow in Copilot CLI: hand off work to run asynchronously while you continue other tasks.

Usage:

/delegate [optional description]

What happens:

1. Your current session context is packaged up

2. Copilot works on the task in the background on GitHub's infrastructure

3. When complete, a draft PR is created on your repository

4. You get a notification with a link to review

Real-world delegation patterns:

"Write comprehensive tests for the auth module"

? /delegate — come back to a PR with full test coverage

"Refactor the database layer to use the repository pattern"

? /delegate — complex refactoring done while you work on other things

"Update all dependencies and fix any breaking changes"

? /delegate — tedious work handled automatically

Parallel work streams:

1. Start task A ? /delegate

2. Start task B ? /delegate

3. Start task C ? /delegate

4. Review 3 PRs when they're ready

Best practices for delegation:

• Provide clear acceptance criteria before delegating

• Use /plan first, then delegate the execution

• Keep delegated tasks focused (one concern per delegation)

• Review the PR carefully — delegation isn't autopilot

What delegation excels at:

• Test writing (high volume, mechanical)

• Documentation updates

• Dependency upgrades

• Code style migrations

• Adding error handling across a codebase

• Implementing well-specified features

💡 Combine /plan + /delegate for maximum effectiveness. The plan gives the agent a clear roadmap, and delegation lets it execute without blocking you. Review the resulting PR as if another developer submitted it.

* Agentic Workflows

▸ Task Management /tasks intermediate

The agent can spawn sub-tasks to handle complex work in parallel. Understanding how tasks work unlocks serious productivity.

Viewing tasks:

/tasks — list all tasks (running, completed, failed)

How tasks work:

When the agent needs to do multiple independent things, it spawns sub-agents:

• Each sub-agent gets its own context window

• Sub-agents work in parallel

• Results are collected and synthesised

• The main agent coordinates the overall task

Task states:

• Running — actively working

• Completed — finished successfully

• Failed — encountered an error

• Background — moved to background with ctrl+x ? b

Example: "Analyse all API endpoints for security issues"

The agent might spawn:

• Task 1: Analyse /api/users routes

• Task 2: Analyse /api/orders routes

• Task 3: Analyse /api/auth routes

• Task 4: Check middleware chain

Each runs simultaneously, then results are merged.

Managing tasks:

• ctrl+x ? b — move current task to background

• ctrl+x ? t — view task list

• /tasks — see all tasks with status

• Click/select a task to see its output

Background task notifications:

When you background a task:

• You can continue working on other things

• A notification appears when the task completes

• Results are available in /tasks

Why this matters:

Traditional development: do A, wait, do B, wait, do C

With tasks: start A, B, C simultaneously, review all results

💡 Background tasks are perfect for test suites, builds, and linting that take minutes to run. Start the task, background it with ctrl+x ? b, and continue your conversation. You'll be notified when it finishes.

▸ Fleet Mode /fleet advanced

Fleet mode enables parallel sub-agent execution for maximum throughput on complex tasks.

Enabling:

/fleet — toggle fleet mode on/off

What fleet mode changes:

Without fleet: agent works sequentially on sub-tasks

With fleet: agent spawns multiple sub-agents working simultaneously

When fleet mode shines:

• Analysing a monorepo (each service gets its own agent)

• Processing batch operations (each item processed in parallel)

• Cross-cutting investigations (trace a concept across many files)

• Large refactoring (each module refactored independently)

Example workflows:

"Audit all 12 microservices for dependency vulnerabilities"

Fleet spawns 12 agents, each analyses one service ? results in minutes, not an hour

"Add TypeScript types to all JavaScript files in src/"

Fleet assigns different directories to different agents ? parallel migration

"Find all places where user input isn't sanitised"

Fleet searches different areas of the codebase simultaneously

Architecture:

• Main agent: coordinates, distributes work, synthesises results

• Sub-agents: stateless workers with focused context

• Each sub-agent gets complete context for its specific task

• Results are streamed back as they complete

Limitations:

• Sub-agents are stateless — they can't reference each other

• Work must be decomposable into independent units

• Very tightly coupled changes might conflict

• Each sub-agent uses premium requests

Best practices:

• Break work into truly independent chunks

• Provide each sub-agent with enough context to work alone

• Review parallel changes for consistency

• Use for read/analysis tasks before write tasks

💡 Fleet mode is a force multiplier in large codebases. A 10-service monorepo analysis that takes 30 minutes sequentially finishes in 3-4 minutes with fleet. Use it for investigation and analysis, then apply changes sequentially for safety.

▸ Background Tasks ctrl+x ? b intermediate

Long-running operations don't need to block your workflow. Background tasks let you continue working while the agent handles time-consuming operations.

Moving to background:

Press ctrl+x ? b during any operation to move it to the background.

Common background candidates:

• Test suites (especially integration tests)

• Build processes

• Linting entire codebases

• Dependency installation

• Docker image builds

• Database migrations

• Research tasks

Workflow example:

You: "Run the full test suite and fix any failures"

Agent: [starts running tests...]

You: ctrl+x ? b (move to background)

You: [continue working on something else]

[notification: Task completed — 3 tests fixed, all passing]

You: [review the changes when convenient]

Multiple background tasks:

You can have several tasks running simultaneously:

• Task 1: Running integration tests (background)

• Task 2: Researching auth patterns (background)

• Task 3: [current] Working on frontend feature

Checking status:

• /tasks — see all background task status

• Notifications appear automatically when tasks complete

• Click a completed task to see its results and any file changes

Pro workflow — the "background sandwich":

1. Start your main task

2. Realise you need something else done

3. Background the current task

4. Do the quick thing

5. Resume or wait for background task notification

Integration with /delegate:

• Background: runs locally, you see results in-session

• Delegate: runs on GitHub, creates a PR

• Use background for things you want to review immediately

• Use delegate for things that can become a PR

💡 Adopt the habit: start tests ? background ? continue working. This alone saves 15-20 minutes per day if your test suite takes more than 30 seconds. The agent will fix failures automatically if you asked it to.

▸ Custom Instructions /init intermediate

Custom instructions let you encode your team's standards, architectural decisions, and coding conventions so the agent follows them automatically.

Setting up:

/init — creates a starter .github/copilot-instructions.md

Instruction file hierarchy (loaded in order):

1. ~/.copilot/copilot-instructions.md — personal global preferences

2. .github/copilot-instructions.md — repository-level team standards

3. .github/instructions/**/*.instructions.md — topic-specific instructions

4. CLAUDE.md / AGENTS.md — root-level agent instructions

5. CLAUDE.md in current directory — directory-specific instructions

What to put in instructions:

Repository-level (.github/copilot-instructions.md):

• Coding style: "Use functional components, never class components"

• Architecture: "Follow hexagonal architecture with ports and adapters"

• Testing: "Every new function must have a unit test"

• Patterns: "Use Result<T> pattern for error handling, never throw"

• Dependencies: "Prefer built-in Node modules over npm packages"

Personal (~/.copilot/copilot-instructions.md):

• "Always add JSDoc comments to exported functions"

• "I prefer verbose variable names over abbreviations"

• "Explain your reasoning before making changes"

• "Always run tests after making changes"

Topic-specific (.github/instructions/testing.instructions.md):

• Testing patterns, mock preferences, coverage expectations

• Glob pattern to apply only to relevant files

Real example:

```

# Project Standards

- TypeScript strict mode, no 'any' types

- Use Zod for runtime validation

- All API endpoints return { data, error } shape

- Prefer composition over inheritance

- Database queries use parameterised statements only

```

The agent reads these EVERY session and follows them automatically.

💡 Layer your instructions: personal prefs in ~/.copilot, team standards in .github, and topic-specific rules in .github/instructions/. The agent combines all layers. Start small and add rules as you notice the agent deviating from your preferences.

# MCP & Extensibility

▸ MCP Servers /mcp advanced

Model Context Protocol (MCP) servers are the primary way to extend Copilot CLI with new capabilities. They give the agent tools to interact with external systems.

Managing MCP servers:

/mcp — view configured servers, add/remove/configure

Built-in MCP server (GitHub):

Copilot CLI ships with GitHub's MCP server providing:

• Repository search across all of GitHub

• Issue and PR read/write

• File content access

• User and org lookup

• Code search with advanced queries

Adding custom MCP servers:

Configuration in .github/copilot-mcp.json or ~/.copilot/mcp.json:

```

{

"servers": {

"azure": {

"command": "npx",

"args": ["@azure/mcp-server"],

"env": { "AZURE_SUBSCRIPTION_ID": "..." }

},

"postgres": {

"command": "npx",

"args": ["@modelcontextprotocol/server-postgres"],

"env": { "DATABASE_URL": "..." }

}

```

Popular MCP servers:

• @azure/mcp-server — Azure resource management

• @modelcontextprotocol/server-postgres — PostgreSQL queries

• @modelcontextprotocol/server-filesystem — Extended file ops

• @playwright/mcp-server — Browser automation

• @stripe/mcp-server — Stripe API integration

What MCP servers enable:

• Database queries: "Show me all orders from last week"

• Cloud management: "List my Azure container apps"

• API calls: "Create a Stripe subscription for this customer"

• Browser testing: "Navigate to localhost:3000 and check the form works"

Security:

• MCP servers run locally with YOUR permissions

• Each tool invocation is shown for approval

• Sensitive env vars are never sent to the AI model

• You control which servers load per-project

💡 MCP servers are the secret weapon for domain-specific workflows. Add a database MCP server and you can say "find all users who signed up last week but never completed onboarding" — the agent writes and executes the SQL for you.

▸ Skills & Plugins /skills and /plugin advanced

Skills and plugins extend the agent with specialised domain knowledge and workflows that go beyond basic tool usage.

Skills (/skills):

Skills are curated capability packages that give the agent deep expertise in specific domains:

• Azure skills — plan infrastructure, deploy apps, troubleshoot production

• Security skills — audit code, check compliance, manage RBAC

• Data skills — query databases, analyse data, build pipelines

Using skills:

/skills — list available skills

/skills enable azure-prepare — activate a specific skill

Skills are context-aware — they activate automatically when relevant. Ask "deploy my app to Azure" and the deployment skill engages.

Plugins (/plugin):

Plugins extend capabilities via marketplace:

/plugin — manage installed plugins

/plugin search [query] — find plugins

/plugin install [name] — add a plugin

What makes skills different from MCP servers:

• MCP servers: provide TOOLS (actions the agent can take)

• Skills: provide KNOWLEDGE + WORKFLOWS (how to approach problems)

Example skill workflow (azure-prepare):

You: "Deploy this Node.js app to Azure"

Skill activates and guides the agent through:

1. Analysing your application

2. Recommending Azure services

3. Generating infrastructure-as-code (Bicep/Terraform)

4. Creating deployment configurations

5. Setting up security (managed identity, private endpoints)

6. Deploying and verifying

Without the skill, the agent would know Azure exists but wouldn't follow best practices or produce production-ready configurations.

Environment inspection:

/env — shows ALL loaded extensions:

• Instruction files loaded

• MCP servers connected

• Skills activated

• Plugins installed

• LSP servers configured

💡 Check /env regularly to understand what's loaded in your session. Skills activate automatically based on context, but you can force-enable them with /skills enable. MCP servers provide tools; skills provide expertise.

▸ IDE Integration /ide advanced

Connect Copilot CLI to your IDE for enhanced code intelligence — go-to-definition, hover information, and diagnostics.

Setting up:

/ide — connect to an IDE workspace

What IDE integration provides:

• Go-to-definition — the agent can jump to symbol definitions

• Hover information — type info, documentation

• Diagnostics — real-time errors and warnings

• Symbol search — find by name across the project

• References — find all usages of a symbol

Why this matters:

Without IDE integration, the agent uses grep and file reading (still effective but slower). With IDE integration, it gets instant, accurate code navigation.

LSP Configuration:

Configure language servers in ~/.copilot/lsp-config.json:

```

{

"servers": {

"typescript": {

"command": "typescript-language-server",

"args": ["--stdio"],

"languages": ["typescript", "javascript"]

},

"python": {

"command": "pylsp",

"languages": ["python"]

},

"rust": {

"command": "rust-analyzer",

"languages": ["rust"]

}

```

Or per-project in .github/lsp.json.

Installing language servers:

• TypeScript: npm install -g typescript-language-server typescript

• Python: pip install python-lsp-server

• Rust: rustup component add rust-analyzer

• Go: go install golang.org/x/tools/gopls@latest

• C#: dotnet tool install -g csharp-ls

Real-world impact:

Without LSP: "Find where UserService is defined" ? grep, manual file reading

With LSP: "Find where UserService is defined" ? instant jump to definition

The agent uses LSP for:

• Understanding type hierarchies

• Finding all callers of a function

• Checking for type errors before running builds

• Navigating complex dependency chains

💡 TypeScript LSP is the highest-value setup: npm install -g typescript-language-server typescript. The agent gets full type awareness and can catch type errors without running tsc. Python-lsp-server is the second most impactful for Python projects.

! Tips & Tricks

▸ Effective Prompting beginner

The quality of your prompts directly determines the quality of the agent's output. Here's how to write prompts that get great results every time.

The prompt quality ladder:

Level 1 (poor): "fix the bug"

Level 2 (okay): "fix the login bug"

Level 3 (good): "fix the bug where login fails when email contains a plus sign"

Level 4 (great): "@src/auth/login.js fix the email validation that rejects plus signs — the regex on line 42 doesn't account for the + character in local-part"

Prompt engineering principles:

1. BE SPECIFIC

Bad: "add auth"

Good: "add JWT authentication to POST /api/orders with a 15-minute expiry"

2. REFERENCE FILES

Bad: "update the tests"

Good: "@tests/auth.test.js add a test for the token refresh endpoint"

3. SET CONSTRAINTS

Bad: "make it faster"

Good: "optimise the database query to use an index scan — no ORM changes, raw SQL only"

4. DESCRIBE INTENT (the WHY)

Bad: "add a try-catch"

Good: "add error handling to prevent the server from crashing when the payment API is unavailable"

5. ONE TASK PER PROMPT

Bad: "add auth, fix the tests, update docs, and deploy"

Good: "add JWT auth to the /api/orders endpoint" (then follow up)

6. USE ACTION VERBS

• "Refactor X to use Y pattern"

• "Add error handling for Z edge case"

• "Fix the failing test in @tests/api.test.js"

• "Explain why this function returns undefined"

• "Create a new endpoint that..."

7. PROVIDE EXAMPLES

"Format the output like this: { status: 'success', data: [...] }"

Anti-patterns to avoid:

• Vague: "make it better" (better how?)

• Compound: 5 tasks in one prompt (do them sequentially)

• Assumption: "you know what I mean" (be explicit)

• No context: not referencing files or code (use @ mentions)

💡 Start prompts with an action verb: Refactor, Add, Fix, Explain, Create, Remove, Update, Test. This immediately tells the agent what type of work you expect. When results aren't what you want, the fix is almost always: be more specific.

▸ Context Management /context intermediate

The context window is your most precious resource. Managing it well means the agent stays sharp and accurate throughout long sessions.

Understanding context:

• Each model has a finite context window (100k-200k tokens)

• Your conversation history ACCUMULATES in context

• File contents read by the agent count toward the limit

• Once context is full, the agent loses track of earlier work

Check your usage:

/context — visual breakdown of token usage

Context budget breakdown:

• System prompt + instructions: ~5-10%

• Conversation history: grows over time

• File contents (read): can be 30-50% in coding sessions

• Agent reasoning: varies by complexity

Signs of context exhaustion:

• Agent asks questions you already answered

• Contradicts earlier decisions

• "Forgets" file contents it already read

• Responses become less precise

Preventive strategies:

1. /compact regularly — summarises history, frees 60-80% of context

When: every 20-30 minutes in active sessions

2. /new for unrelated tasks — start fresh for different work

When: switching from "fix auth bug" to "update deployment config"

3. Targeted @ mentions — give specific context instead of letting the agent search

When: you know exactly which files are relevant

4. Keep prompts focused — one task at a time

When: always (compound prompts waste context on tangents)

5. Use /plan — externalises thinking so it doesn't fill context

When: complex multi-step tasks

The /compact workflow:

1. Working on a task, hit 50%+ context usage

2. Run /compact — agent summarises everything important

3. Context drops back to ~20% — history preserved as summary

4. Continue working with a fresh budget

You won't lose anything — /compact preserves:

• Key decisions made

• Files modified

• Current task state

• Important context from conversation

💡 Monitor /context like a fuel gauge. Run /compact before you hit 70% — the agent produces better summaries when it still has full context to draw from. Make it a habit: /compact after every major milestone.

▸ Side Questions /ask beginner

Need a quick answer without derailing your current conversation? /ask lets you ask one-off questions in a separate context.

Usage:

/ask [your question]

How it works:

• Opens a separate "side channel" for your question

• The answer does NOT get added to your conversation history

• Your main conversation context is preserved

• No tokens spent on conversation you don't need later

Perfect use cases:

Quick syntax lookup:

/ask what's the JavaScript syntax for optional chaining with function calls?

API reference:

/ask what parameters does the Node.js fs.createReadStream accept?

Concept check:

/ask what's the difference between Promise.all and Promise.allSettled?

Git help:

/ask how do I squash the last 3 commits?

Regex:

/ask write a regex that matches email addresses with plus signs

Why use /ask instead of a regular prompt:

• Regular prompt: adds to conversation ? consumes context ? agent remembers

• /ask: disposable ? no context cost ? agent won't reference later

The savings add up. If you ask 10 quick questions during a session, that could be 5-10% of context saved — enough for 2-3 more file reads later.

When NOT to use /ask:

• When the answer informs your current task (use regular prompt so agent remembers)

• When you need follow-up questions (each /ask is standalone)

• When the answer needs your project context (side channel is context-free)

💡 Build the habit: quick lookup ? /ask, important decision ? regular prompt. The context savings compound over long sessions. Think of /ask as your "Google search" that doesn't pollute your conversation.

▸ Streaming & Privacy /streamer-mode beginner

Streaming or screen sharing? Streamer mode hides sensitive information from your session display.

Activating:

/streamer-mode — toggle on/off

What gets hidden:

• Model names and versions (prevents NDA leaks for preview models)

• Quota and billing information

• Premium request counts

• Preview feature indicators

• Token usage details

• Personal identifiers in prompts

What stays visible:

• Code and file contents

• Your prompts and the agent's responses

• File names and paths

• Command output

• Everything needed for the demonstration

When to use:

• Live streaming on Twitch/YouTube

• Screen sharing in meetings

• Recording demo videos

• Conference talks and presentations

• Pair programming with external contractors

Also consider for demos:

• Clear your history first: /clear

• Use a demo-specific project (not your real codebase)

• Have a script: know what prompts you'll show

• Keep prompts focused and impressive

• Show the reasoning toggle (ctrl+t) — audiences love it

Privacy checklist before streaming:

1. /streamer-mode — hide metadata

2. Check your terminal title bar (may show project paths)

3. Check your shell prompt (may show username/host)

4. Close other terminal tabs with sensitive content

5. Disable desktop notifications

💡 Enable streamer mode BEFORE starting your stream — don't scramble to turn it on after revealing something. Consider creating a shell alias like alias copilot-demo="copilot --streamer-mode" for quick demo launches.

~ Advanced Patterns

▸ Recurring Tasks /every advanced

Schedule prompts to run at regular intervals within your session. Perfect for continuous monitoring during development.

Usage:

/every [interval] [command/prompt]

Examples:

/every 5m run the test suite

/every 2m check if the build passes

/every 10m summarise git log changes

/every 1m curl localhost:3000/health and report status

Real workflows:

Continuous TDD:

/every 3m run npm test and report failures

Then code freely — you get notified the instant something breaks

Build monitoring:

/every 5m run the build and alert me if it fails

Refactor with confidence — build issues surface immediately

Health checking:

/every 1m check localhost:3000/api/health

Monitor your local dev server while working on other things

Log watching:

/every 2m check docker logs app-container for errors

Keep an eye on containers while developing

Managing recurring tasks:

• /tasks — see all recurring tasks

• Cancel by referencing the task: "stop the test monitor"

• Tasks run within the session lifetime only

• Results appear in your notification area

Combining with background:

1. /every 5m run tests (starts recurring task)

2. ctrl+x ? b (background the monitor)

3. Continue working normally

4. Get notified when tests fail

Interval formats:

• 30s — 30 seconds

• 5m — 5 minutes

• 1h — 1 hour

Use cases by interval:

• 30s-1m: health checks, log watching

• 2-5m: test suites, build verification

• 10-30m: dependency checks, security scans

💡 The killer combo: /every 3m run tests + continuous coding. You get instant feedback when something breaks, without manually re-running tests. It's like having CI/CD running locally in real-time.

▸ Session Sharing /share intermediate

Turn your Copilot sessions into shareable documentation, team knowledge, and learning resources.

Usage:

/share — select export format

Export formats:

• Markdown (.md) — clean, readable, version-control friendly

• HTML (.html) — formatted with syntax highlighting

• GitHub Gist — shareable link, supports commenting

What gets exported:

• Full conversation (prompts and responses)

• Code changes as diffs

• Commands run and their output

• Agent reasoning (if reasoning display was enabled)

• File references and context

Use cases:

Team knowledge sharing:

"I figured out how to set up the auth system" ? /share to gist ? post in Slack

Code review context:

"Here's the reasoning behind my PR changes" ? /share as markdown ? attach to PR

Onboarding documentation:

Walk through setting up a project with the agent ? /share ? new hire resource

Architecture decisions:

Record why you chose approach A over B ? /share ? add to ADR folder

Bug investigation:

Document the debugging process ? /share ? attach to the bug report

Teaching:

Show students how to approach a problem ? /share ? course materials

Making shares useful:

• Name your session first (/rename) — becomes the title

• Use clear prompts — they become the narrative

• Enable reasoning (ctrl+t) — shows the thought process

• Work through problems step by step — makes a logical story

Team workflow:

1. Developer investigates a complex issue

2. Finds the root cause and fixes it

3. /share to gist

4. Links gist in the PR description

5. Reviewers understand the full context

💡 Sessions with good prompt hygiene make excellent documentation automatically. Write prompts as if someone else will read them — they will, when you /share. Consider /share as a habit after solving any non-trivial problem.

▸ Rewind & Undo /rewind and /undo intermediate

Made a mistake? Rewind the conversation and undo file changes in one atomic operation.

Commands:

/rewind — rewind the last turn and revert file changes

/undo — alias for /rewind

What /rewind does:

1. Removes the last conversation turn from history

2. Reverts any file changes made in that turn

3. Unexecutes any commands (if possible)

4. Returns you to the state before the last prompt

This is ATOMIC — conversation and files revert together. No inconsistency.

When to rewind:

• Agent misunderstood your intent

• The approach taken was wrong

• You want to re-phrase your prompt for better results

• A change broke something and you want a clean slate

• The agent went in an unexpected direction

/rewind vs git checkout:

• /rewind: reverts only agent-made changes from last turn

• git checkout: reverts ALL changes including your manual edits

• /rewind: also removes conversation context (important!)

• git checkout: conversation still references the reverted code

Multiple rewinds:

You can /rewind multiple times to go back several turns. Each rewind removes one turn. Useful when a series of changes all went wrong.

Rewind workflow:

1. Prompt: "Refactor auth to use middleware pattern"

2. Agent makes changes you don't like

3. /rewind — back to pre-refactor state

4. Prompt: "Refactor auth to use middleware pattern, keeping the existing route structure and only extracting the token verification logic"

5. Agent produces better result

Why rewind > "undo that":

• "Undo that" uses a NEW turn (consuming context)

• /rewind REMOVES the turn (saving context)

• Cleaner history, more context budget remaining

💡 Prefer /rewind over asking the agent to "undo that" — it's cleaner (removes bad context) and saves tokens. If you're about to attempt something risky, remember you can always /rewind if it goes sideways.

▸ Environment Info /env intermediate

When things aren't working as expected, /env is your first debugging tool. It shows everything loaded in the current session.

Usage:

/env — display complete environment information

What /env shows:

1. Instruction files loaded:

• ~/.copilot/copilot-instructions.md (global)

• .github/copilot-instructions.md (repo)

• .github/instructions/*.instructions.md (topic)

• CLAUDE.md, AGENTS.md (root)

• CLAUDE.md (cwd, if different from root)

2. MCP servers:

• Server name, command, status (connected/error)

• Available tools from each server

• Configuration source

3. Skills:

• Active skills and their status

• Available but inactive skills

4. Plugins:

• Installed plugins

• Plugin version and capabilities

5. LSP servers:

• Configured language servers

• Connection status

• Languages covered

6. Model & session:

• Current model

• Session ID and name

• Token usage summary

Debugging with /env:

"Why isn't the agent following my coding standards?"

? /env ? check if instruction files are loaded

? Maybe the file path is wrong or file has syntax issues

"Why can't the agent access my database?"

? /env ? check MCP server status

? Maybe the postgres MCP server failed to connect

"Why is code navigation slow?"

? /env ? check LSP server status

? Maybe typescript-language-server isn't installed

"Why isn't the agent using the new feature?"

? /env ? check model version

? Maybe you need to switch models

Common fixes:

• Instruction not loaded ? check file path and name exactly

• MCP server error ? check env vars and command path

• LSP disconnected ? reinstall language server

• Wrong model ? /model to switch

💡 Run /env at the START of every session in a new project. It takes 2 seconds and prevents 20 minutes of confusion later. If something's missing, you catch it immediately.

▸ Remote Control /remote advanced

Control your CLI session from anywhere — your phone, another computer, or the GitHub web UI.

Enabling:

/remote — toggle remote control on/off

What remote control enables:

• Send prompts to your CLI from the GitHub web interface

• Monitor session progress from any device

• Control long-running tasks from your phone

• Collaborate with team members on a session

Use cases:

Mobile monitoring:

1. Start a long task on your workstation

2. /remote to enable

3. Walk to a meeting

4. Check progress on your phone

5. Send follow-up instructions if needed

Multi-device workflow:

1. Working on laptop in a café

2. Get home, want to continue on desktop

3. /remote lets you send prompts from either device

4. Session state stays consistent

Deployment monitoring:

1. Start a deployment with the agent

2. /remote on

3. Step away from desk

4. Monitor from phone: "What's the deployment status?"

5. If issues arise: "Roll back the deployment"

Team collaboration:

1. Junior dev is stuck on a problem

2. They enable /remote

3. Senior dev sends guidance prompts from their machine

4. Pair programming without screen sharing

Security:

• Remote control requires GitHub authentication

• Only your GitHub account can send commands (unless you share)

• All commands are logged in the session

• Toggle off with /remote when done

• Sessions are end-to-end encrypted

Best practices:

• Enable for long-running tasks you need to monitor

• Disable when handling sensitive code

• Use named sessions (/rename) so you can find them on mobile

• Set up notifications on your phone for task completions

💡 Enable /remote before starting any task that takes longer than 5 minutes. The freedom to walk away from your desk while monitoring progress is a quality-of-life game changer. Disable when working on sensitive code.