I’ve watched teams struggle with the same problem: they get Copilot working, but it keeps suggesting code that doesn’t match their project’s conventions. The AI suggests a function signature that violates their naming patterns. It recommends test structures nobody on the team uses. It imports from libraries they’ve standardized against.
The real issue isn’t that Copilot is bad. It’s that Copilot doesn’t know the unwritten rules living in your codebase. Every project has them. How you structure components. Which linting rules matter most. Whether you prefer functional or object-oriented patterns. The conventions that make your code feel like it belongs to your team, not just any team.
The good news: you can teach Copilot those rules. And doing so changes how it works with your project.
Custom Instructions as Your Team’s Baseline
Start with repository-wide guidance. Add a .github/copilot-instructions.md file that explains your team’s core standards. Your preferred architecture. Naming conventions. Testing expectations. This becomes the baseline context every Copilot task starts with.
But codebases aren’t monolithic. The rules for a React component differ from the rules for a backend service. That’s where path-specific instructions come in. You can create files in .github/instructions with an applyTo field that tells Copilot when that guidance applies. A .github/instructions/react-components.md file applies only to React files. A .github/instructions/api-handlers.md file applies only to backend code.
Copilot then combines both: the repository-wide rules plus the specific guidance for whatever file type it’s working on. You keep broad standards in one place without forcing every file into the same mold.
Skills and Agents for Recurring Workflows
Custom instructions work for standards that shape many tasks. But some guidance only matters for specific procedures. Quality checks. Release preparation. Debugging workflows. That’s where agent skills enter the picture.
A skill is a folder in .github/skills containing instructions and optionally scripts. When Copilot handles that specific task, it loads the skill and follows your established process instead of guessing which commands to run. A quality-checks skill can define exactly how your team lints, tests, and validates. An accessibility-review skill can guide Copilot through inspecting components across multiple files for accessibility issues.
For larger recurring work, custom agents take it further. An agent in .github/agents can specialize in a particular type of work. It has its own purpose, instructions, tools, and project context. Use a custom agent when a task type happens repeatedly and benefits from a dedicated perspective, especially when it spans multiple files and draws on several tools.
Connecting External Tools Through MCP Servers
Instructions, skills, and agents help Copilot understand your project’s internal world. MCP servers expand what it can access and do beyond your repository. Think of them as bridges to external tools, data sources, and services.
A documentation server gives Copilot access to framework guidance. A Playwright server lets it open your application in a browser and interact with it like a human would. Once configured, you can ask Copilot to use Playwright to test your updated interface manually. Copilot opens the browser, clicks buttons, fills forms, and verifies the functionality works as expected. That’s verification that goes beyond automated checks.
The Compounding Effect of Customization
Each of these customization layers solves a different problem. But they become most powerful when combined. Repository instructions set the baseline. Path-specific guidance adapts for different file types. Skills handle recurring procedures. Agents specialize in larger tasks. MCP servers extend what’s possible.
Together, they create a version of Copilot that understands not just the syntax of your code, but the culture of your team. The conventions you’ve evolved. The standards you’ve learned matter. The tools you’ve chosen to standardize on.
Getting Started Small
You don’t need to implement all of this at once. Start with one convention you find yourself explaining repeatedly. Add it to .github/copilot-instructions.md. See how Copilot applies it to your next task. If you’re not sure where to begin, check out Awesome Copilot for community-shared instructions and skills you can adapt.
The implication here matters: as AI tools become more capable, the teams that win won’t be those that passively use them. They’ll be the ones that teach their tools how their teams actually work, embedding their standards and knowledge into the systems they build with every day.
When Copilot understands your codebase’s rules, it stops feeling like a generic tool and starts feeling like a team member who finally gets how you work. The question is: how intentional are you being about teaching it?