A Chef's Guide to Customizing GitHub Copilot

GitHub Copilot has grown well beyond code completions. If you’re new to Copilot – or you’ve been using just the basics – the sheer number of customization options can feel overwhelming. This guide cuts through the complexity. By the end, you’ll know exactly which feature to reach for and why. To keep things grounded, every feature maps to a part of a single metaphor: think of Copilot as a talented chef you’ve just hired, and your job is to set up the kitchen so they can do their best work.

Custom instructions: the house style guide

Every professional kitchen has a style guide posted on the wall. “We always wipe the edge of the plate before serving. Garnish goes on the left.” Every dish always follows these rules.

Custom instructions provide always-on context that silently shapes every interaction with Copilot, without you having to repeat yourself. There’s an important constraint: these instructions get appended to every request behind the scenes. If they’re too long, the important parts get lost. Keep custom instructions concise – focus on rules that apply to nearly every task.

Custom instructions can be configured with different scopes to control when they get added to the context:

• Personal and organization: Your individual preferences or company-wide guidelines set through settings on GitHub
• Repository-wide (.github/copilot-instructions.md): Project standards that apply everywhere – frameworks, coding conventions, folder structure
• Path-specific (.github/instructions/*.instructions.md): Rules scoped to matching files using applyTo and wildcard patterns – great for repositories containing multiple projects or programming languages.

More specific instructions take priority, with your personal preferences winning overall.

Prompt files: order tickets

When a specific dish comes in, the kitchen works from an order ticket. It tells the chef exactly what to make and any modifications – “Table 4, the risotto, substitute mushrooms for truffles.”

Prompt files are reusable templates stored as .prompt.md files in .github/prompts/, each defining a focused task with input variables you fill in when you run them. For example, a simple prompt file might say:

 1   Write unit tests for ${file} using Jest, covering edge cases for null inputs.

You’d use prompt files for repeatable, focused tasks: generating unit tests, running a code review checklist, or scaffolding a new component. Each time, you fill in the blanks and let Copilot execute. Prompts can also specify a model, agent, and MCP tools to use, allowing you to define not just what you want but how you want it done.

Custom agents: station chefs

A professional kitchen runs on a brigade system. The saucier specializes in sauces and garnishes. The pastry chef handles desserts. Each has focused training and access to specific equipment. You assign work to the right station based on what needs cooking.

Custom agents are markdown files stored in .github/agents/ that define a name, description, set of instructions, and optional restrictions on which tools the agent can access. For example, a security-reviewer agent might be limited to read and search tools, preventing it from modifying code.

Agents can also hand off to each other. A planning agent might research and outline a task, then hand off to a coding agent for implementation. They can also specify which AI model to use, so a documentation agent might use a model strong at natural language while a coding agent uses a reasoning-optimized one.

Agent skills: recipe cards in a drawer

Instead of memorizing every potential recipe, a chef will have recipe cards that can be used when a dish calls for something special.

Agent skills are folders containing a SKILL.md file (and optionally scripts, examples, and other resources) stored in .github/skills/ for project skills or ~/.copilot/skills/ for personal skills that work across projects. Skills are based on the open Agent Skills specification, so they work across different AI systems.

The key concept here is progressive disclosure. Copilot loads only the skill descriptions at session start – like reading the titles of the recipe cards – and pulls in the full content only when it’s relevant. This keeps your context window (AI’s working memory) clean and means skills use far less of that working memory than custom instructions.

Some recipe cards are just ingredient lists and plating notes – reference knowledge like API conventions or naming standards. Others are step-by-step procedures: “blanch for 90 seconds, shock in ice water, then sear.” Skills like this include scripts or references to MCP tools the AI should use. For example, a deployment skill might include a bash script that runs your release process, with the SKILL.md telling Copilot when and how to execute it.

MCP servers: phone lines to suppliers

Need fresh fish? Call the fish market. Today’s delivery schedule? Call the distributor. Phone lines connect your kitchen to services outside its walls – live, external services you don’t control or can’t replicate locally.

MCP servers are standardized connections to external systems using the Model Context Protocol – an open standard that lets Copilot communicate with databases, APIs, browsers, and other services. Every external system speaks the same protocol, so Copilot doesn’t need custom integration logic for each one. MCP servers primarily expose tools (actions the AI can take), but the protocol also supports sharing data (resources) and prompt templates.

MCP also allows those systems to send messages back to Copilot. For example, a developer might ask for a summary of open issues. The MCP server could query a database, ask Copilot to summarize the results, then return that summary to the user.

My earlier posts cover additional practical details.

Skills vs. MCP: when to use which

Use a skill when the task can run with local tools, the logic is project-specific, and you want versioning support. Skills are operationally simpler (no running server process), and they can include step-by-step guidance that makes results more reliable. They are the preferred choice for desccribing your process or telling the AI how and when to do something.

Use MCP when you need a live connection to an external service, the tool should be reusable across projects which may lack support for skills, the integration requires a running process, or you need some part of the logic to live outside the repository. MCP tools provide details about the expected parameters to ensure proper invocation. They are typically well-suited to performing an action that requires authentication and connectivity to external systems.

In many cases, you’ll use both. Copilot just gets a description of the available tools from the MCP server, along with details about the parameters and their data type. A skill can explain how and when to use those tools properly, providing those details only when they will be needed.

Subagents: research chefs sent to investigate

Sometimes, before planning the menu, you send a research chef to the farmers market to investigate what’s fresh. They work independently and return with a concise report so that the executive chef can make an informed decision.

Subagents are separate agent sessions that run in their own isolated context window. When Copilot needs to research something complex – investigating how authentication works across a codebase or evaluating different implementation options – it can dispatch a subagent. The subagent reads files, runs searches, and processes information in its own space, then returns a summary to the main session. You can even dispatch multiple subagents in parallel – one for edge cases, one for maintainability, one for security – and have the main agent synthesize the results.

Hooks: safety interlocks

The deep fryer won’t heat past 375°F. The ventilation kicks on whenever the burners light. The hand-washing station logs every use. These are mechanical systems – no one decides whether they run. The chef can’t override the fryer’s temperature limit no matter how rushed they are.

Hooks bring this same determinism to Copilot. They’re scripts that execute automatically at specific points in the agent’s workflow – after a file edit, before a commit, when a session starts. You’d use hooks for actions that must happen every time with zero exceptions: looking for errors and style issues after every file edit, blocking writes to sensitive directories, or logging behaviors.

The distinction from instructions is critical: instructions, skills, and MCP server tools are advisory – the AI can choose to interpret or even skip them, like a busy chef skipping the house rule about wiping plate rims. Hooks are deterministic – they execute outside the AI’s decision-making process with no discretion involved, just like the fryer’s temperature limit. If you need a guarantee, use a hook.

Plugins: the franchise starter kit

When you open a new restaurant location, instead of explaining each piece individually, you hand over a single package: the house style guide, the recipe drawer, the supplier contacts, and the safety equipment specs. You get everything the new kitchen needs to operate like the original.

Agent plugins do the same for Copilot customizations. They’re distributable packages that bundle skills, hooks, agents, and MCP server configurations into a single installable unit, distributed through a marketplace (a Git repository). You’d reach for plugins when your customizations have matured and you want to share them across multiple projects or teams. My earlier post walks through building one from scratch.

Unfortunately, plugins aren’t fully supported in all ecosystems. As a result, many teams use MCP servers as a way to reliably share prompts and tools. As adoption improves, I expect this to become the standard way to version and distribute customizations.

Setting up your kitchen

Here’s a quick reference for deciding which feature to reach for:

You don’t need to use every feature on day one. Start with custom instructions for your project’s conventions. Add prompt files when you find yourself repeating the same requests. Bring in custom agents for specialized workflows, then add skills and MCP servers as you need more deterministic results and access to outside systems. Add hooks when you need guarantees, and package it all up as plugins when you’re ready to share.