Customizing Copilot

A generic AI gives generic answers. This is how you feed Copilot the context, conventions, and procedures that make it yours — the bridge from “using Copilot” to “building with Copilot.”

There are four mechanisms here, from simplest to most powerful. (The fifth — connecting real tools via MCP — is big enough to get its own topic.)

1 · Custom instructions

☺ Like you’re 10: Imagine taping a house-rules note to the fridge — “wipe your feet, put toys away” — so everyone follows it without being told. Copilot reads that note before it starts helping, every single time.

The simplest steering: a copilot-instructions.md file (commonly in .github/) or an AGENTS.md file in your repo. These are short, natural-language statements about how you want Copilot to behave in this project — coding standards, preferred libraries, architectural rules, “always write tests,” “prefer composition over inheritance.” Copilot loads them automatically as context for completions, chat, agent mode, the cloud agent, and code review.

Organization owners can define instructions org-wide, so every repo inherits a shared source of truth. This is how teams keep many developers — and many agents — consistent.

Instructions in action. Same request, with and without one convention in copilot-instructions.md:

copilot-instructions.md:  "Use the repo's Result<T> type for fallible calls; never throw."

WITHOUT it   ask "add a function to fetch a user"
             -> function fetchUser(id) { ...; throw new Error('not found') }

WITH it      ask "add a function to fetch a user"
             -> function fetchUser(id): Result<User> { ...; return Err('not found') }

Nobody re-typed the rule — the file is silently in context for every completion, chat, and agent run in the repo.

2 · Prompt files

☺ Like you’re 10: It’s like saving your favorite pizza order so you can reorder it with one tap instead of listing every topping again. You write the tricky request once, then just tell Copilot “do that saved one.”

A prompt file is a reusable, shareable prompt stored as a Markdown file in your workspace. Instead of retyping the same complex instruction (“scaffold a new React component following our design-system conventions, with a test and a story”), you save it once and invoke it. Think of prompt files as parameterized, version-controlled prompts your whole team can reuse. They live in the repo, so they’re reviewed and improved like any other code.

3 · Agent Skills (the important one)

☺ Like you’re 10: A skill is like handing Copilot a recipe card for one special dish — it keeps the card tucked away and only pulls it out when that exact dish is ordered. That way it always cooks it the way you like.

This is where customization gets powerful, and it’s the same concept whether you use Copilot’s agents or build your own.

An Agent Skill is a folder containing a SKILL.md file (plus optional supporting Markdown, scripts, and resources) that Copilot loads when relevant to perform specialized tasks better. Skills work with the cloud agent, code review, the CLI, the Copilot app, and agent mode in VS Code.

Anatomy of a SKILL.md

☺ Like you’re 10: The top of the recipe card has a label saying what the dish is and when to make it, and the rest is the actual step-by-step cooking instructions. The label is how Copilot knows which card to grab.

It’s Markdown with YAML frontmatter:

---
name: github-actions-failure-debugging
description: Guide for debugging failing GitHub Actions workflows. Use this
  when asked to debug failing GitHub Actions workflows.
license: MIT
---

To debug failing GitHub Actions workflows in a pull request, follow this
process, using tools provided from the GitHub MCP Server:

1. Use the `list_workflow_runs` tool to find recent runs for the PR.
2. For a failed run, fetch the logs and identify the failing step.
3. ... (step-by-step instructions, examples, guidelines for Copilot)

The two required fields are name (lowercase, hyphenated) and description (what it does and when Copilot should use it — this is the trigger). The Markdown body is the actual instructions.

Where skills live

• Project skills (specific to one repo): .github/skills/<skill-name>/SKILL.md
• Personal skills (shared across your projects): ~/.copilot/skills/<skill-name>/SKILL.md

Skills can run scripts. You can include a script (say, an SVG-to-PNG converter) and tell Copilot in the SKILL.md when and how to run it.

4 · Copilot Spaces

☺ Like you’re 10: A Space is like a small shelf where you put only the books about one topic, so when you ask a question the answer comes from those trusted books instead of the whole messy library.

A Copilot Space is a curated, project-specific knowledge base you attach to conversations — docs, code, and instructions bundled as context. When a question should be grounded in a particular body of knowledge (a product area, a service’s runbook, a set of design docs), you point Copilot at the Space and its answers are grounded in that curated material rather than the whole sprawling repo. Think of it as a focused, reusable context bundle.