GitHub Copilot: Intermediate

Intermediate

You can install Copilot and accept suggestions. Now make it reliable on real work. The difference between an occasional autocomplete and a tool you trust is context: what Copilot can see when it answers. This is context engineering, the craft machtsinn cares most about.

Give Copilot the right context

By default Copilot sees your open file and a slice of the workspace. You steer it by adding context explicitly.

How	What it adds
Attach a file or folder	The exact code you want Copilot to read
#codebase	A semantic search across your indexed project, so Copilot finds the relevant code itself
Attach an image	Screenshots, mockups, error dialogs
Add a URL	Reference docs or an issue
Terminal output	A command and its result
Problems	Errors and warnings from the Problems panel

Type # in chat to pull these in. The more precisely you scope context, the better the answer, and the less of the context window you waste. See The context window.

Multi-file edits with Copilot Edits

For changes that span more than one file, describe the change in chat and let Copilot Edits propose a set of diffs across files. Nothing lands until you approve it.

1. Open the Chat view and describe the change across the files involved.

2. Add the relevant files (or #codebase) as context.

3. Read the proposed diffs one file at a time.

4. Accept the good ones, discard the rest, and re-run with a sharper prompt if needed.

Tip

Smaller, well-scoped edits beat one sprawling request. If Copilot is guessing across too many files, narrow the task or the context.

Set repo-wide rules: copilot-instructions.md

Repeating “we use X, follow Y convention” in every chat is wasted effort. Put it once in a file Copilot reads automatically.

Create .github/copilot-instructions.md at the root of your repo. Everything in it is applied to chat in that workspace: your stack, naming conventions, the commands to build and test, and anything Copilot keeps getting wrong.

Worked example: the repo that keeps getting things wrong

Symptoms first. In a repo without an instructions file, the same corrections come up in every single chat:

You:     Add a test for the discount calculation.
Copilot: I'll create __tests__/discount.spec.js using Jest...
You:     We use Vitest, not Jest. Tests live next to the source file.
Copilot: Understood, switching to Vitest...
You:     And it's TypeScript. And run it with pnpm, not npm.

Every session starts from zero, and you pay the same correction tax each time. Now write the corrections down once:

.github/copilot-instructions.md

# Project rules
- TypeScript, strict mode. No `any`.
- Package manager: pnpm. Never suggest npm or yarn commands.
- Tests: Vitest, colocated as `*.test.ts` next to the source file. No `__tests__` folders.
- Follow the existing folder structure in `src/`; don't invent new top-level dirs.
- Run `pnpm check` (lint + typecheck + tests) before claiming a change is done.

The same request now produces a colocated discount.test.ts in Vitest on the first attempt, in every future session. The rule of thumb: the second time you correct Copilot for the same thing, that correction belongs in the instructions file.

Caution

Keep it short and load-bearing. Over-stuffed instruction files dilute steering: Copilot weighs everything at once, so a long file makes each rule count for less.

Path-scoped rules

For rules that only apply to certain files, add path-scoped *.instructions.md files (default location .github/instructions) with an applyTo glob in the frontmatter:

.github/instructions/tests.instructions.md

---
applyTo: "**/*.test.ts"
description: "Conventions for test files"
---
- Use the existing test helpers in `test/utils`.
- One behavior per test; name it after the behavior, not the method.

These load only when Copilot works on matching files, so they cost nothing in every other chat.

You can generate a starter file with /init (workspace-wide and always on) or /create-instruction for a targeted one.

Note

Copilot can also read cross-tool files like AGENTS.md and CLAUDE.md when those settings are enabled, so a repo that already documents its conventions doesn’t have to repeat them.

Work clean

• One task per chat. Start a fresh session when you switch tasks. A focused thread gives better answers.
• Watch the context meter. VS Code shows how full the window is; when it climbs, you’re diluting the signal.

This is the day-to-day of a reliable workflow.

You’re done when…

• ✅ You’ve scoped a chat with attachments and #codebase
• ✅ You’ve made a multi-file change with Copilot Edits and reviewed each diff
• ✅ Your repo has a concise .github/copilot-instructions.md

Next step

Ready to run agent mode, plan before you build, and add your own tools over MCP?

GitHub Copilot: Advanced Agent mode, planning, MCP servers, Copilot Code Review, and the CLI.