GitHub Copilot works best when it knows the specific rules of the codebase it is working with, rather than relying only on general instructions. GitHub explains that much of this context can be stored inside the repository, allowing Copilot to automatically recognize component organization patterns, the commands being used, and naming and testing standards.
General and Path-Specific Instructions
Configuration begins by creating the .github/copilot-instructions.md file to store rules that apply to the entire repository, such as the preferred architecture, naming conventions, and testing and validation requirements.
GitHub also allows you to create instruction files associated with specific paths inside .github/instructions. These files use the applyTo field to specify the files or cases to which the instructions apply. This makes it possible to combine general guidance with more specialized rules without imposing a single style on all file types.
Turning Repetitive Procedures into Skills
General instructions are not suitable for every procedure. Tasks such as running quality checks, preparing a release, or diagnosing workflow failures require repeatable steps. For this purpose, GitHub suggests using agent skills, which are folders that can contain instructions, scripts, and additional resources.
Project-specific skills can be placed in .github/skills, with a separate folder for each skill. A folder such as quality-checks might contain a SKILL.md file specifying when to use the skill, the commands for testing and checking code style, what each command checks, and how to handle common failure cases.
When Do You Need a Custom Agent?
Some tasks go beyond a single procedure and span multiple files and tools. GitHub gives accessibility review as an example, which may require checking components, templates, styles, and interactions. In these cases, you can create a custom agent inside .github/agents, specifying its purpose, instructions, tools, and context relevant to the project.
This option becomes suitable when a particular type of work is repeated and benefits from a specialized role or a specific perspective, especially if it requires handling multiple files and sources of context.
Expanding Copilot’s Capabilities Through MCP Servers
Instructions, skills, and agents help Copilot understand how to work within the project, while Model Context Protocol (MCP) servers connect it to tools, data sources, and services outside the repository. A documentation server can provide framework guidance, while a server such as Playwright allows the application to be opened and interacted with through a browser.
After setting up Playwright, you can request that functionality be tested manually using an MCP server. This means validation is not limited to the success of automated tests; Copilot can also examine the interface’s behavior after a change and interact with it in the browser.
What Changes in Practice?
The primary benefit is moving recurring knowledge from the conversation into reviewable files inside the repository. Instructions define the standards, skills document procedures, agents focus on complex tasks, and MCP servers add the ability to use external tools. GitHub recommends starting gradually: choose one rule that you repeatedly explain, place it in .github/copilot-instructions.md, and then observe how Copilot applies it.
The article also points to the Awesome Copilot repository, which includes ready-to-share instructions, skills, and agents. However, adapting these resources to the project’s tools and standards remains necessary before adopting them.