Context for GitHub Copilot: a checklist for instructions, agent mode and MCP · Resource

Work through this checklist on one specific repository, with its files open alongside. The five blocks follow the order in which it pays to build context for Copilot: repository instructions first, then their content and a check that they work, then agent mode in the editor, and MCP servers last. Each block has boxes to tick and one sentence to remember.

Two terms first. Custom instructions are text that Copilot receives automatically with every request made in the context of a repository. MCP (Model Context Protocol) is an open standard for connecting tools and data to a model. Instructions say how to work. MCP gives access to what the agent needs.

1. The right file at the right level

[ ] You know which kinds of instruction your environment supports (GitHub, VS Code, Visual Studio, JetBrains, Xcode, Eclipse) and for which task (chat, cloud agent, code review).
[ ] Personal preferences (response language, level of detail) are in personal instructions, not in the repository.
[ ] Knowledge about the project is in .github/copilot-instructions.md.
[ ] Rules for only some files are in .github/instructions/**/*.instructions.md files, with an applyTo block and a path pattern.
[ ] Where a file should work in only one place, it has an excludeAgent key set to "code-review" or "cloud-agent".
[ ] If you use AGENTS.md, you know the nearest file in the directory tree wins. Instead, you can keep one CLAUDE.md or GEMINI.md at the root.
[ ] You don't confuse agent instructions with custom agent definitions in .github/agents.
[ ] Organization-wide guidance (language, security, compliance) is in organization instructions, if you are on a Business or Enterprise plan.

Every rule has one home. The same rule written at three levels is three chances for a contradiction.

2. What the instructions say

[ ] The file opens with a short overview of the project: purpose, context, main assumptions.
[ ] It states the coding standards: naming, formatting, agreed practices.
[ ] It lists the tools, libraries and frameworks, with versions where they matter.
[ ] It describes how to build, test and lint, with commands that actually work.
[ ] Every rule is a short, self-contained statement that applies to most requests in the repository.
[ ] It doesn't point at external resources, dictate a response style or set hard length limits.
[ ] No rule contradicts personal or organization instructions.
[ ] The file isn't written for one specific task.

Instructions travel with every message. A rule that applies to one task belongs in the issue, not in the file.

3. Checking that the instructions work

[ ] If you have no file yet, ask Copilot's cloud agent to generate one and review its draft pull request like any other.
[ ] Once saved, ask chat a few questions about the project and expand the references above the answer: .github/copilot-instructions.md should be listed there.
[ ] You test changes to instructions in the same pull request, because Copilot code review reads instructions from the branch you are merging.
[ ] The "Use custom instructions when reviewing pull requests" option in the repository settings is set the way you expect.
[ ] If answers got worse, switch repository instructions off for a moment and compare.
[ ] You remember that the model doesn't always apply instructions identically, so they don't replace repository rules or review.

If .github/copilot-instructions.md isn't listed in the chat answer's references, chat didn't use it. Check that before you edit the content.

4. Agent mode in the editor

[ ] You can see the Agent option in Copilot Chat's mode selector. If it is missing, you ask your administrator whether the mode is disabled.
[ ] You choose agent mode for multi-step tasks that need iteration and error handling, or that involve an external tool.
[ ] For a large or ambiguous task, you ask for a plan first and the code second.
[ ] Before sending a task, you pick the model or a custom agent that fits the work.
[ ] You confirm or reject every terminal command. You know which commands (if any) may run automatically, and who decided that.
[ ] You review edits as they stream in and undo the ones you don't want.
[ ] When the agent heads the wrong way, you send a follow-up and change direction instead of waiting for it to finish.
[ ] You remember that every prompt you send (a message to the agent) consumes GitHub AI credits.

In the editor, you approve the agent's steps. Use that to see what the instructions are missing, and add it to the file.

5. MCP servers

[ ] You know where MCP is configured for the way you work: the GitHub Copilot app, Copilot CLI, editors and the cloud agent each have separate settings.
[ ] For the cloud agent, you know the default servers: GitHub (read-only credentials, current repository only) and Playwright (only localhost inside the agent's environment).
[ ] You remember that the cloud agent calls MCP tools without asking for approval.
[ ] Every third-party server has been reviewed: its tools, its authentication, the data it reaches.
[ ] In the repository settings, the tools field holds an allowlist of tools, read-only where possible, rather than all of them.
[ ] The agent's default credentials have not been widened unless a task requires it.
[ ] A server only one custom agent needs is defined in that agent's profile, not for the whole repository.
[ ] You don't connect remote servers that authenticate with OAuth to the cloud agent, and you don't expect MCP resources or prompts, because only tools are supported.
[ ] Tools that code review should use carry readOnlyHint: true.
[ ] In the GitHub MCP server, you enable only the toolsets you need.
[ ] In a company, you know whether the MCP policy for Business and Enterprise plans is on (it is off by default).
[ ] In an agent session, you check which servers and tools are actually available before you rely on them.

In the cloud, the tool allowlist replaces approving each call. Every tool on that list is a decision you make once for every future session.

After the checklist

If blocks 1 to 3 are ticked, the repository has context that every team member and every way of working can draw on. Run blocks 4 and 5 again whenever you add a new tool or a new way of working with the agent: first in the editor, where you see every step, then in the cloud, where you only see the result.