Four Context Layers That Turn GitHub Copilot Into a Team-Aware Coding Assistant

Ask an assistant to add a custom page size to an application and the code is only half of the deliverable. The other half is whether that code matches the patterns your team already uses — component structure, runnable scripts, and the naming or validation habits tied to a framework or a file type.

Working with AI depends heavily on context, and each codebase carries its own house rules. GitHub Copilot can support changes across a project, yet its results improve when those rules are also available to it. Many of them can remain inside the repository, so Copilot gathers them automatically instead of requiring you to restate standards, scripts, and workflows whenever a new task begins.

The four approaches examined in the GitHub Copilot app for Beginners series each answer a different engineering problem: custom instructions convey the conventions Copilot should follow, agent skills bundle repeatable procedures, custom agents bring specialized guidance to larger tasks, and Model Context Protocol (MCP) servers link Copilot to external tools and data sources. What follows is organised for practitioners — what each layer does, where its file lives, a rollout order, the misconceptions that silently undo it, and a FAQ.

Layer 1 — Custom instructions: the conventions you stop repeating in chat

To define repository-wide guidance such as preferred architecture, naming conventions, or testing and validation expectations, add a .github/copilot-instructions.md file.

Guidance that matters only for particular paths can sit in files inside .github/instructions. Those files use an applyTo field to signal to Copilot when the guidance matters.

For a matching file, Copilot can combine repository-wide instructions with the more specific guidance. That keeps broad rules centralised without forcing every file type into the same mold.

Layer 2 — Agent skills: a procedure loaded only when it is relevant

Custom instructions work best when a standard should shape many tasks. Other guidance mainly matters during a particular procedure, such as running quality checks, preparing a release, or debugging a failed workflow.

Agent skills address that need. A skill is a folder holding instructions and, optionally, scripts or other resources that Copilot can load when relevant. Project-level skills can live in .github/skills, with each skill stored in its own subfolder.

A .github/skills/quality-checks folder, for instance, might contain a SKILL.md file that explains:

when Copilot should use the skill;
which scripts run the project's tests and linting;
what each script checks;
how to troubleshoot common failures.

Because the SKILL.md description indicates the situations in which to use it, Copilot can load the quality-checks skill after an interface update and follow the project's established testing and linting process instead of guessing which commands to run.

Layer 3 — Custom agents: specialists for work that crosses files

Some tasks exceed a single procedure. An accessibility review may require Copilot to inspect components, templates, styles, and interactions across multiple files.

Custom agents create specialised versions of Copilot for such work. A repository-level agent profile lives in .github/agents and can define purpose, instructions, tools, and relevant project context.

The selection rule is straightforward: a dedicated role or perspective benefits recurring work, so choose a custom agent when the task may span multiple files and draw on several tools or sources of context.

Layer 4 — MCP servers: reach beyond the repository boundary

Within the project, instructions, skills, and agents help Copilot understand how to work. Beyond the repository, MCP servers expand what it can access and do.

MCP servers connect Copilot to external tools, data sources, and services. Framework guidance can be made available through a documentation server, while Playwright can open and interact with your application in a browser.

The Copilot app can show the available MCP servers, and a custom one can be added. Once Playwright is configured, a request such as "Use the Playwright MCP server to test the functionality manually" lets Copilot open the application in a browser and interact with it much as you would. That gives it a way to verify not only that the code passes automated checks but also that the updated interface behaves as expected.

Which layer solves which problem

Customisation	Where it lives	What it decides in practice
Custom instructions	`.github/copilot-instructions.md`, plus path-scoped files in `.github/instructions` using `applyTo`	Sets the conventions that Copilot should follow across the repository or for particular files.
Agent skills	A subfolder per skill in `.github/skills`, described by `SKILL.md`	Bundles repeatable procedures that Copilot can load when relevant.
Custom agents	Agent profile in `.github/agents`	Provides focused expertise and guidance for broader tasks.
MCP servers	Listed in the Copilot app, where a custom server can be added	Connects Copilot to external tools, services, and data sources, expanding what Copilot can do.

A rollout order that respects the dependencies

Write down one convention you keep explaining and put it in .github/copilot-instructions.md; observe how Copilot applies it to your next task.
Add a path-scoped file under .github/instructions only where a file type needs its own rules, and mark it with applyTo so Copilot knows when the guidance matters.
Convert a procedure you repeat step by step — quality checks, release preparation, debugging a failed workflow — into a skill folder under .github/skills, whose SKILL.md states when to use it, which scripts run tests and linting, what each script checks, and how to troubleshoot common failures.
When a recurring task spans multiple files and draws on several tools or sources of context, an accessibility review being the example here, define a repository-level agent profile in .github/agents with purpose, instructions, tools, and relevant project context.
Only then look outward: check the MCP servers the Copilot app shows, add a custom one where needed, and use Playwright so browser-level behaviour can be verified rather than assumed.

The sequence mirrors the layering: instructions, skills, and agents describe how work should be done inside the repository, while Model Context Protocol connections extend what sits outside it.

Misconceptions that quietly break these setups

Every rule belongs in one instruction file. Conventions that shape many tasks fit custom instructions; guidance that matters during a particular procedure is better packaged as a skill.
The assistant will infer my scripts. Without repository instructions and skills, Copilot has to guess which commands run your tests and linting.
A skill applies all the time. The SKILL.md description indicates the situations to use it, so loading is conditional.
Long instructions can handle a multi-file review. Work that may span several files and pull from multiple tools or context sources is exactly when a custom agent is the right type of customisation.
Passing automated checks proves the interface works. Browser interaction through the Playwright MCP server is what shows the updated interface behaves as expected.
Community examples can be dropped in unchanged. Ready-made instructions, skills, and agents still need to be inspected and adapted to your repository's tools and standards.

FAQ

How do custom instructions differ from agent skills?

Custom instructions convey conventions that Copilot should follow across the repository or for particular files. An agent skill is a folder holding instructions and, optionally, scripts or other resources that Copilot loads when a relevant procedure comes up.

Where do rules that apply to only some files go?

Inside .github/instructions. Those files use an applyTo field to signal when the guidance matters, and for a matching file Copilot can combine them with repository-wide instructions.

Which customisation suits an accessibility review?

A custom agent, because such a review may require inspecting components, templates, styles, and interactions across multiple files. The profile in .github/agents can define purpose, instructions, tools, and relevant project context.

Can Copilot exercise the UI rather than only edit code?

Yes, once an MCP server such as Playwright is configured: the Copilot app can show available MCP servers and a custom one can be added. Copilot can then open the application in a browser and interact with it much as you would.

Where do I find starting points rather than writing everything from scratch?

Awesome Copilot offers ready-made instructions, skills, agents, and other community-shared resources. Pick one for a workflow you already repeat, inspect its contents, and adapt it to your repository's tools and standards.

Before you open the next task

A short diagnostic sorts any piece of guidance into the right layer. Ask yourself: which convention do I keep explaining? which multi-step procedure do I repeat? which complex task could benefit from a dedicated custom agent? which outside tool or source does Copilot need?

Then keep the first move small. Add a single convention to .github/copilot-instructions.md, run your next task through it, and let the result tell you whether the repository is now carrying context on your behalf.