Applied AI: How to Make GitHub Copilot Follow Your Project Rules with Instructions, Skills, Agents, and MCP

Most teams judge an assistant by the code it returns. In day-to-day use, the decisive variable is quieter: what the tool already knows before it writes anything. For readers whose job is to get work out the door rather than to study model internals, the practical question is how project knowledge reaches the assistant, and how that handoff can be made automatic.

Every repository carries house rules: component structure, the scripts that actually run, naming patterns attached to a framework, conventions tied to particular file types. GitHub Copilot can support changes across a project, but the output improves when those rules are visible to it at the start of a task. Store the rules inside the repository and Copilot can gather them on its own, with no need to restate standards, scripts, and workflows each time a new task begins.

GitHub's Copilot app for Beginners series sorts the ways to do this into four: custom instructions that carry conventions, agent skills that bundle repeatable procedures, custom agents that bring specialized guidance to larger work, and Model Context Protocol (MCP) servers that link the assistant to external tools and data sources. Below, each is treated as an application layer: where it sits in a workflow, how to set it up, what it is worth, and where teams usually go wrong.

Where the four layers sit in your workflow

A quick mapping from symptom to mechanism:

• You keep repeating the same review comments about architecture, naming, or testing expectations: custom instructions.
• You keep walking someone through a runbook such as quality checks, release preparation, or debugging a failed workflow: agent skills.
• You keep assigning the same recurring role that touches components, templates, styles, and interactions in many files: custom agents.
• You keep pasting in material the assistant cannot reach, such as framework documentation, a live browser session, or an outside service: MCP servers.

Within the project, the first three layers tell Copilot how to work. Beyond the repository, MCP servers expand what it can access, and therefore what it can do.

Layer 1: custom instructions, or saying the house rules once

Consider a request to add a custom page size to an application. Producing the change is only half the job; the new code also has to match patterns the team already uses. That fit is what instructions supply.

Repository-wide guidance, such as preferred architecture, naming conventions, or testing and validation expectations, goes into a .github/copilot-instructions.md file.

Guidance that only matters for certain paths can sit in files under .github/instructions. Those files carry an applyTo field that signals to Copilot when the narrower guidance is relevant.

When a file matches, Copilot can combine repository-wide instructions with the more specific guidance. Broad rules stay centralized, and no single file type is forced into the same mold as the rest.

Layer 2: agent skills, or packaging a procedure you repeat

Instructions pay off when one standard should shape many tasks. Other guidance only matters while a particular procedure is running. Agent skills serve that second case.

A skill is a folder holding instructions and, optionally, scripts or other resources that Copilot can load when the situation calls for them. Project-level skills live under .github/skills, with one subfolder per skill.

Take .github/skills/quality-checks. Its SKILL.md can explain:

• the situations in which the skill should be used,
• which scripts run the project's tests and linting,
• what each script actually checks,
• how to troubleshoot the failures that come up most often.

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

Layer 3: custom agents, or giving a broad job its own profile

Some tasks exceed a single procedure. An accessibility review, for example, may require Copilot to inspect components, templates, styles, and interactions across many files at once.

Custom agents create a specialized version of Copilot for exactly that kind of work. The profile lives at repository level in .github/agents and can define purpose, instructions, tools, and the relevant project context.

The selection rule is simple: a dedicated role or perspective earns its keep on 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, or reaching past the repository

Model Context Protocol servers connect Copilot to external tools, data sources, and services. Two typical uses: a documentation server that makes framework guidance available, and Playwright, which can open your application in a browser and interact with it.

The Copilot app can show the MCP servers already available, and a custom one can be added from there. Once Playwright is configured, the request can be as plain as: use the Playwright MCP server to test the functionality manually.

After that request, Copilot can drive Playwright to open the application and interact with it much as you would, giving it a way to confirm not only that the code passes automated checks but also that the updated interface behaves as expected.

Choosing among the four: a role-by-role comparison

Each mechanism answers a different problem, and the combination is where the value appears:

Customization	Role in the workflow
Custom instructions	Carry the conventions to follow across the whole repository or for defined file paths.
Agent skills	Package a repeatable procedure, with its scripts and resources, so it loads only when relevant.
Custom agents	Supply a focused role, its instructions and tools, for tasks that cross files and context sources.
MCP servers	Attach external tools, services, and data sources, widening what Copilot can reach and verify.

Step-by-step: wiring the layers into one real task

1. Inventory the friction: note the conventions you re-explain, the runbooks you re-walk, the tasks that touch many files, and the material outside the repository you paste in by hand.
2. Open .github/copilot-instructions.md and write the repository-wide rules first: architecture preference, naming, testing and validation expectations.
3. Where a rule belongs only to certain files, add a scoped file under .github/instructions and set its applyTo field so Copilot knows when it matters.
4. Create .github/skills/<procedure-name> for a runbook you repeat, and write a SKILL.md covering when the skill applies, which scripts run tests and linting, what each checks, and how to troubleshoot common failures.
5. When a recurring job spans several files and needs its own tools and context, define an agent profile under .github/agents with purpose, instructions, tools, and project context.
6. Review the MCP servers listed in the Copilot app, add a custom one where an external capability is missing, and configure Playwright when browser-level behaviour must be verified; then ask for the manual test run explicitly.
7. Browse Awesome Copilot for ready-made instructions, skills, and agents; inspect the contents before adapting them to your repository's tools and standards.

Common mistakes to avoid

• Restating standards, scripts, and workflows inside every new task prompt instead of leaving them in the repository where Copilot can pick them up automatically.
• Loading path-specific rules into repository-wide instructions, so every file type ends up judged by the same mold.
• Letting Copilot guess which commands run the tests and the linter, rather than recording them in a skill's SKILL.md.
• Keeping a procedure that matters in only one situation as a general convention, or handing a multi-file, multi-tool task to a single instruction file when a dedicated custom agent fits better.
• Treating automated checks as proof that an interface works, when the behaviour that matters can only be confirmed by opening the application in a browser through Playwright.
• Adopting a community resource from Awesome Copilot without inspecting it and adapting it to the tools and standards of your own repository.

Action checklist: four questions before your next task

1. Which project convention do you keep explaining?
2. Which multi-step procedure do you keep repeating?
3. Which complex task would benefit from a dedicated custom agent?
4. Which outside tool or source does Copilot still need?

None of this requires a large setup. Pick the mechanism the answers point to most often and ship that single change: one convention written into .github/copilot-instructions.md, or one runbook captured as a skill folder. Then watch how the next task is handled before adding the following layer. Community-shared instructions, skills, agents, and other resources collected through Awesome Copilot give you a starting point for each layer; choose one for a workflow you already repeat, read what is inside, and adapt it to the tools and standards your repository actually uses.