11 Hidden GitHub Copilot Tricks Every Developer Should Know
Table of Contents
Modern AI tools like GitHub Copilot have evolved rapidly, unlocking dozens of powerful features most developers haven’t discovered yet. This report distills the best-kept secrets and tips gleaned from two in-depth transcripts and authoritative sources. We cover advanced Copilot chat commands, context management, custom instructions, agent and CLI modes, cost-saving techniques under usage-based billing, and more. Each tip includes a catchy title, concise explanation, real-world example or code snippet, plus the why it matters and when to use considerations, all backed by official docs or research. We assume an audience of experienced developers using Copilot (and similar AI coding assistants) in typical environments (mostly VS Code/IDE or GitHub) but unfamiliar with these advanced tips. The final section groups all tips in a comparison table by category, difficulty, impact, and use-case.
Trick 1 : Slash Commands: Instant AI Actions
What it is:
Copilot Chat supports slash commands – single-word directives (prefixed with /) that tell Copilot exactly what to do without typing a long prompt. For example, typing /fix with some code selected tells Copilot to propose fixes; /tests generates unit tests for the active code; /explain asks Copilot to explain the current function. These built‑in commands bypass the need for verbose prompting and work in IDE chat panels and Copilot CLI.
How it works (examples):
Command:
/new - Generate a new project, class, component, or feature
Example:
/new ASP.NET Core Web API with JWT Authentication
Command:
/fix - Detect and fix bugs or code issues
Example:
Best For Null Reference Exceptions, SonarQube issues, Security vulnerabilities, Code smells
Command:
/tests - Generate unit tests
Example:
/tests using xUnit
Command:
/doc - Create documentation and comments
Example: Generate XML comments, Method documentation, README content, API descriptions
Command:
/explain - Explain selected code
Example: Copilot explains: What method does, Input/output, Business logic, Best for Legacy applications, Knowledge transfer, New developers
The commands adapt to context (selected code or active file). Official docs list many such commands: e.g., /new (create project boilerplate), /explain, /help, /fix, /tests etc.
Why it matters:
Slash commands dramatically speed up common tasks (testing, refactoring, documentation) by automating them with one keystroke. Instead of writing “write tests for this function” you simply invoke /tests. This saves time and ensures you’re using the most up-to-date Copilot functionality. Since these commands are built-in, they often generate more accurate results than a manual prompt.
When to use:
Whenever you need a common action. For example, if you see a compiler error, select the offending code and type /fix; Copilot will suggest corrections. If you want quick test coverage, use /tests. When starting a new codebase or module, /new can scaffold files. Use /explain to understand unfamiliar code. Slash commands fit naturally into coding flow and are especially useful when you want a precise AI action with minimal typing
Trick 2 : File References: Fine-Grained Context
What it is:
Copilot Chat allows referencing specific files or code blocks in your project using chat variables like #file:. By typing #file:<filename>, you tell Copilot to include that file’s contents in its context. This is far cheaper and more precise than pasting large code snippets manually.
How it works (example):
// In Copilot Chat:
#file:auth.ts // Copilot loads auth.ts into context
Generate a function that validates the user password using the utilities in this file.
Copilot will “read” auth.ts and use its contents to answer. Official docs note using #file to target specific files for context.
For example, you could write:
#file:gameReducer.js how are these files related? and Copilot will analyze those files accordingly
Why it matters:
Copilot always tries to include open files or entire workspace context in its prompts by default, which can be wasteful. Using explicit file references gives the AI exactly what it needs, reducing irrelevant input tokens and improving accuracy. You avoid sending dozens of unneeded open files and get focused results on just the files you care about. This not only cuts costs (under usage-based billing) but also prevents hallucination from unrelated code.
When to use:
When asking Copilot about or operating on a file that isn’t already active or selected. For example, if you want to modify a file that’s not open, prefix your chat with #file:OtherFile.js. Or attach multiple files: #file:utils.ts #file:main.ts refactor these for null-safety. It’s essential in large codebases – instead of saying “look at my auth module,” just reference it directly
Trick 3 : Custom Instructions File: Enforce Coding Standards
What it is:
You can create a repository-level instructions file (.github/copilot-instructions.md) containing guidelines for Copilot. This tells Copilot your project’s conventions (e.g. “use TypeScript strict mode, avoid any, follow our naming style”, or “we log with ILogger`). The AI injects these instructions automatically in every chat or code-review request.
How it works (example):
# .github/copilot-instructions.md
- Always use **TypeScript** in strict mode; avoid `any`.
- For errors, return an `ErrorResult` object instead of throwing.
- Follow our company’s GoogleJS styleguide for naming.
GitHub docs explain how to add this file in the repo root. Once present, Copilot automatically appends these rules to its prompts. You only set this up once, and it applies across all Copilot interactions on that repo.
Why it matters:
If your project has special requirements (security checks, architecture patterns, company style), custom instructions ensure Copilot follows them consistently. It prevents Copilot from suggesting code that violates your rules (e.g. injecting console logs when you forbid them). It’s especially powerful for code review and agent actions – the AI will trust and apply your instructions, reducing faulty code and CI failures. This boosts productivity (no need to rewrite Copilot’s suggestions) and reduces the risk of errors
When to use:
Add this immediately on any active project. Even if you just want to say “code only, no explanation” (important for cost-saving, see below), put it here once and Copilot remembers. Update it for team standards or for different tasks. With path-specific instructions (see next tip), you can apply rules only to certain folders or file types.
Trick 4 : Scoped Instructions (applyTo): Only When Relevant
What it is:
Besides the global instructions file, you can create path-specific instructions that only apply to certain files or languages. In a .github/instructions/ folder, add files named *.instructions.md with a YAML frontmatter applyTo: “<glob>” to target files. This prevents irrelevant instructions from cluttering contexts for unrelated files.
How it works (example):
# .github/instructions/sql.instructions.md
---
applyTo: "**/*.sql"
---
- Always terminate SQL statements with a semicolon.
- Use parameterized queries to prevent SQL injection.
This file tells Copilot that these rules apply only to .sql files. Copilot will ignore them when working in .js or .py files. Official docs illustrate using applyTo in frontmatter to scope instructions
Why it matters:
Without scoping, Copilot will send all global instructions on every request, even if irrelevant, wasting tokens. By scoping, you keep prompts short and context-specific. For example, keep SQL rules out of your TypeScript sessions. This improves performance (fewer tokens) and accuracy (only relevant guidance). It lets you fine-tune Copilot’s behaviour in multi-language repos or when different modules have different needs.
When to use:
Whenever you have different domains in one repo. Typical uses: one instruction file for backend (e.g. .Net Core), another for frontend (e.g. TypeScript) with respective style rules. It’s especially helpful in large monorepos. If a set of instructions never needs to be used for certain files, put them in a scoped file to avoid being injected unnecessarily.
Trick 5 : Next Edit Suggestions: Smart Multi-File Refactoring
What it is:
Copilot’s Next Edit Suggestions (NES) feature anticipates your next change after you make an edit. For instance, if you rename a class or make a pattern change, NES will proactively suggest applying that change throughout your codebase. This goes beyond simple autocomplete; it can suggest multi-line edits across files to keep your code consistent.
How it works (example):
In Visual Studio or VS Code, as soon as you rename a variable or refactor a function name, an arrow appears in the gutter. Pressing Tab accepts the suggestion. Under the hood, Copilot sees your local edits and suggests wherever a similar change should be made. For example, renaming class Point to class Point3D once will prompt:
Rename `Point` to `Point3D` in all relevant references in this file
Official docs explain that NES looks at your edit context and “suggests changes to the rest of your code that match a change in intent”. It can handle syntax updates (e.g. migrating from old APIs to new ones) and repetitive refactorings
Why it matters:
This saves a huge amount of manual work and prevents mistakes. Instead of searching and replacing, Copilot does the heavy lifting. It even catches complex cases (typo fixes, logical operator fixes, API deprecations) as it learns your recent edit’s intention. As an AI pair-programmer, it keeps your refactorings coherent across files and reduces human error.
When to use:
Always keep Next Edit Suggestions enabled during development (it’s on by default in recent IDE versions). Use it whenever you refactor or make repetitive changes.
Examples: renaming a variable, updating syntax (e.g. migrating to modern library calls), fixing a conditional in multiple places. NES is especially handy for sweeping updates across large codebases.
How it works (example):
1. IDE Agent Mode: In VS Code, you can click on the Copilot assistant and say “Create user authentication with JWT”. Agent Mode will outline steps (e.g. add login endpoint, hash password, generate token) and implement them.
2. Cloud Agent: On GitHub, assign an issue to @copilot or use the Agents panel. Copilot Cloud Agent will spin up its own development environment, run tests/linters, and push code commits. It can even iterate on your feedback. The docs confirm: it can “research a repository, create implementation plans, fix bugs, implement features” etc.
Why it matters:
This is a paradigm shift. Instead of jumping from code to chat to code manually, you delegate. The agent can handle routine or defined tasks while you focus on higher-level design or novel problems. It also logs every step as real commits, so there’s auditability. Ultimately, it speeds development (especially for boilerplate or backlog tasks) and enables asynchronous collaboration via GitHub instead of in-IDE chat.
When to use:
Use Agent Mode or Cloud Agent for multi-step, well-defined tasks. For example, generating an entire CRUD feature, fixing widespread bugs, or writing a large test suite. (Avoid it for vague or exploratory tasks.) If you just have a quick question, use normal chat. But for anything that requires planning, refactoring lots of code, or full module generation, let the agent run and handle the details. Remember to review its work, but you’ll often find it has done most of the heavy lifting.
Trick 6 : Terse, “Caveman” Prompts: Say Less, Save Tokens
What it is:
When prompting Copilot, brevity is your friend. The shorter the prompt, the fewer input tokens and typically the shorter (and cheaper) the output. AI experts have coined this “caveman speak” – strip polite fluff from your requests. Instead of “Could you please refactor this code to improve performance?“, say “Refactor for speed.”
How it works (example):
Instead of writing
Hello Copilot, can you help me optimize this database query? I want it to run faster, ideally by using an index.
Try the concise version:
Optimize this DB query using an index.
This communicates the same goal with far fewer words. Research and experience show that concise prompts still yield quality answers but dramatically reduce token count. Every extra word costs both input tokens and usually more output tokens (since the AI often mirrors verbosity).
Why it matters:
Under token billing, a chatty prompt can substantially bump up costs (and context length). By being brief, you cut overhead. A token-efficiency guide recommends always “be specific, not verbose” to get the needed answer in one shot. Plus, less back-and-forth means faster response. In practice, teams see 30–50% fewer input tokens simply by shortening prompts.
When to use:
In all Copilot chats or CLI prompts. Edit your prompts to remove filler (e.g. “please”, “could you”, paragraphs of background). Focus on commands and key details only. This is especially important for routine tasks (like asking for an example or a simple refactor). For complex design questions you might be more descriptive, but even then trim unnecessary words.
Trick 7 : Close Unused Files: Minimize Chat Context
What it is:
Every open file and editor tab can leak into Copilot’s context. Under the hood, Copilot Chat may include open code in its prompt (some clients do). More open files = more input tokens. So close or hide files not relevant to the task to keep context lean.
How it works (example):
Imagine you have 20 files open, including large test data dumps or logs. If you ask Copilot a question, it might internally load parts of these into context (especially if using the Workspace participant). Each KB of code is tokens. The token-cost blog warns against uploading irrelevant docs (e.g. “A dense PDF page can cost 3,000 tokens”). Similarly, a few extra open files can cost hundreds of tokens each request.
Why it matters:
Less open code means smaller prompts, faster replies, and lower billing. It also reduces confusion (Copilot isn’t distracted by unrelated code). In practice, teams say closing irrelevant tabs before chatting cut their token usage noticeably. In a usage scenario, every extraneous file is “wasted context” that the model still has to process.
When to use:
Before starting a Copilot session, close large or irrelevant files. For example, if working on auth.js, close your completely different admin_panel.py. Only keep the current file and maybe closely related ones open. The same goes for chat: if you have file attachments in Copilot Chat, remove ones you don’t need. This tip is simple hygiene and pays off if your IDE or environment leaks context.
Trick 8 : Model Routing: Match Task to Model
What it is:
Different AI models (GPT-3.5, GPT-4, GPT-5.3+, Claude, etc.) have different costs per token. Under usage billing, choose the lighter model for trivial tasks and save the “big guns” for hard problems.
For example, refactoring a simple function doesn’t need GPT-5.5; GPT-3.5 Turbo (much cheaper) will suffice.
How it works (example):
GitHub’s pricing chart shows GPT-5 outputs costing ~$30 per million tokens vs GPT-5 nano output ~$1.25. That’s ~25× difference! Similarly, various models have multipliers. The AI tokens guide explicitly advises: “if you need a two-minute answer, don’t send someone on a week-long project… use the lighter model”. Many Copilot clients (CLI or Chat) allow selecting GPT-3.5 or GPT-4.
Why it matters:
Using a high-end model for every query is like always using a supercomputer for simple calculations – wildly expensive. By routing, you keep costs predictable. Also, lighter models often respond faster. Reserving GPT-5 or Claude Opus for nuanced, creative tasks means you still get their power when it truly matters.
When to use:
For straightforward tasks (simple code generation, refactors, formatting, test writing), switch Copilot to a cheaper model (GPT-3.5 Turbo or equivalent). In Copilot CLI, use –model gpt-3.5-turbo or similar. In chat interfaces, check settings to pick a lower-tier model. Save the “mega” models for complex architecture, multi-file planning, or when you specifically need the higher context window. Essentially: never assume the default is always best; pick based on task.
Trick 9 : Use References, Don’t Paste Whole Files
What it is:
In Copilot Chat, instead of copying and pasting an entire source file into the prompt, use file references or selections. Many devs might paste large code blocks and ask Copilot to work on them, but it’s wasteful. Reference what’s already loaded (as above) or attach files as context.
How it works (example):
/* (pasted entire AuthService.ts here) */
Refactor this class to use async/await.
do:
#file:AuthService.ts refactor class to use async/await
Or simply open AuthService.ts in the IDE and highlight the method, then ask: “refactor this method for async/await.” The official docs and cheat sheets emphasize attaching files with #file: or using IDE context tools. This ensures you don’t pay to re-send every line of code (input tokens).
Why it matters:
Sending a whole file as text could be tens or hundreds of lines, each line dozens of tokens. That’s a huge cost compared to maybe a handful of tokens referencing it. It also avoids cluttering your prompt. Copy-pasting risks truncation or model forgetting earlier lines if context overflows. Using references or selections is cleaner and more reliable.
When to use:
Whenever you need Copilot to operate on existing code. Open the relevant file and ask questions about it, or prepend #file: in chat to include it. Only paste code when absolutely necessary (e.g., an external snippet not in the project). This tip ties in with closing files: keep your code in the IDE and let Copilot ingest it directly.
Trick 10 : Fresh Conversations: Reset Context Often
What it is:
Continuing a very long chat session can dramatically raise costs. Each time you send a message, Copilot re-reads the entire conversation history (often up to thousands of tokens). Instead of letting a chat run for 50 messages, start a new chat when your topic changes or after an answer resolves.
How it works (example):
AI-token guides warn that reopening old threads can eat 15% of your token budget instantly. The solution: after solving one problem, close or clear the chat. If you need context from a previous conversation, ask Copilot to summarize or just copy the brief answer. For example:
Assistant: [finishes task].
User: Summarize what we did.
Then start a new chat with that summary. This avoids resending all earlier dialog.
Why it matters:
It’s surprising but true: if you ask multiple follow-ups in one thread, every follow-up includes all prior messages as input tokens. Fresh chats focus only on what’s needed. This saves AI credits and keeps the model responsive. It also circumvents stuck contexts where the model might “hallucinate” off past turns.
When to use:
After completing a subtask (like finishing a feature or fully resolving a bug), or anytime your prompt diverges significantly. In Copilot Chat, hit /clear or start new session. In CLI, just exit and re-run with a new prompt. If you need the context (e.g. design decisions), ask for a concise summary and use that. Essentially, treat conversations as ephemeral; don’t piggyback endless edits on one thread
Trick 11 : Use the Usage Dashboard: Monitor and Optimize
What it is:
GitHub provides a Copilot usage dashboard (for Business/Enterprise plans) and metrics APIs. Use these tools to track token consumption by user, repo, or project. It shows which models and features consume the most credits.
How it works (example):
In your GitHub organization’s Copilot billing settings, you can view a breakdown of AI credit usage. If one developer or team is blowing through credits, investigate. The metrics include number of queries, tokens, and breakdown by model. With this data, you can spot waste (like too much GPT-4 usage) or confirm that optimizations (e.g. “code-only” rule) are working.
Why it matters:
Without visibility, costs spiral in token-based billing. The usage dashboard is your feedback loop. By regularly reviewing it, you identify top spenders and patterns. For example, if you see a spike after enabling agent hooks, you might decide to cache more or trim prompts. It also helps forecast budgets and justify optimizations to management.
When to use:
Set a recurring audit (e.g. monthly) to check Copilot usage. Use GitHub’s Optimize budget configuration and Usage Metrics API to enforce caps and alerts. Whenever you apply a cost-saving tip (like terse prompts or model routing), measure the effect here. This dashboard keeps your Copilot usage from becoming a surprise expense.
Summary Table
| Tip | Category | Difficulty | Impact | When to use |
|---|---|---|---|---|
| Slash Commands (e.g. /fix, /tests) | Tooling/Productivity | ★☆☆ | High – instant action | When needing fixes, tests, docs quickly |
| File References (#file:) | Context Management | ★☆☆ | High – accuracy/cost | When asking Copilot about a specific file |
| Custom Instructions File | Configuration/Standards | ★★☆ | High – code quality | At project setup; enforce team rules |
| Scoped Instructions (applyTo) | Configuration/Context | ★★☆ | Medium – cost saving | When instructions should only apply to some files |
| Next Edit Suggestions (NES) | Productivity/Refactoring | ★★☆ | High – speed/accuracy | During refactoring or repetitive edits |
| Agent Mode / Cloud Agent | Automation/AI Workflow | ★★★ | High – automation | For multi-step tasks or backlog issues |
| Agentic Code Review (Implement PRs) | Code Review/Automation | ★★☆ | Medium – convenience | When accepting Copilot review suggestions |
| Agent Hooks (pre/post checks) | DevOps/Quality | ★★☆ | High – code quality | Always: to run linters/tests during AI runs |
| MCP Integration | Integration/Data Access | ★★★ | High – context | When needing Copilot to use external data |
| GitHub Spark (App generation) | Tooling/Prototyping | ★★☆ | High – rapid prototyping | When you need a quick full-stack prototype |
| Copilot CLI (Plan & Autopilot) | Tooling/Automation | ★★★ | High – automation | For scripting complex, multi-step tasks |
| “Code-Only” Directive (trim output) | Cost Optimization | ★☆☆ | High – cost reduction | On every coding prompt (except when explanation needed) |
| Terse Prompts (concise requests) | Cost Optimization | ★☆☆ | High – cost reduction | Always – make prompts as brief as possible |
| Trim Instructions File (short text) | Cost Optimization | ★★☆ | Medium – cost reduction | Keep repo instructions minimal at all times |
| Close Unused Files (limit context) | Cost Optimization | ★☆☆ | Medium – cost reduction | Before starting Copilot sessions |
| Model Routing (pick cheaper model) | Cost/Performance | ★☆☆ | High – cost/perf | Use cheapest sufficient model for task |
| No Full File Pasting (attach or open) | Cost/Usability | ★☆☆ | Medium – cost/clarity | Reference files; avoid copy-paste large code |
| Fresh Conversations (reset chat) | Cost/Workflow | ★☆☆ | Medium – cost | Start a new chat when switching topics |
| Usage Dashboard (monitor costs) | Budget/Management | ★☆☆ | Medium – control | Regularly (weekly/monthly) check usage |