How to Configure GitHub Copilot in 4 Steps

Copilot reads four kinds of files from your repo. Write one rule file, test it with two runs, and turn every repeated correction into a line.

Mar 20, 2026

To configure GitHub Copilot, write the four kinds of files it reads from your repo, which most developers skip. Start with one rule file and you stop retyping the same correction. The setup takes about 30 minutes, and every file name below comes from GitHub's and VS Code's own docs.

I used Copilot as autocomplete for weeks. I typed a function name, waited for the gray text, and pressed Tab. The files below turned it into a tool that already knows my repo's rules before I type a character.

TLDR

Copilot reads four file types from .github: repo instructions, path instructions, skills and custom agents.
Start with one rule that Copilot keeps breaking, written in .github/copilot-instructions.md.
A skill is a folder with a SKILL.md file, and Copilot loads it when your request matches its description.
In one run each, a rule that names the exact component got followed and a rule that described a habit did not. I could not confirm the CLI loaded the file in two of the three runs.
Every correction you type twice becomes one line in a file.

One Prompt Run Three Ways Shows How to Test a Rule

I ran one prompt three times in GitHub Copilot CLI 1.0.36 on my site's repo. The prompt was "Add an FAQ section with 3 questions about pricing to the Work page."

In three single runs, the rule that named FAQSection got followed and the habit rule did not.

Run 1. I deleted the instruction file. Copilot wrote the FAQ markup inline in the page.
Run 2. I kept my 9-line file, whose one rule says to inspect existing components before creating new ones. Copilot wrote the FAQ inline again.
Run 3. I replaced the rule with one line that names FAQSection and its path. Copilot read that component and imported it.

Each of these is one run, so treat them as a demonstration and not as a benchmark. I could not confirm that the CLI loaded the file in runs 2 and 3, because its log does not say, so I cannot prove the file caused the change in run 3. A first test, a new service card, gave the same result with and without the file.

Watch out. A rule in a file is a request, and Copilot weighs it against everything else it reads. Run the same prompt with and without the file before you trust a rule.

Step 1. Write One Rule Copilot Keeps Breaking

Create .github/copilot-instructions.md in your repo and write the one correction you gave Copilot most this week. Repo-wide instructions apply to every request made in the context of the repository.

Write the rule as a command that names the exact file, folder or function. "Reuse existing components" describes a habit. "Build every FAQ block with FAQSection from src/components/common/FAQSection.tsx" names a target.

My site's file is 9 lines with one rule, and the full text sits in the Appendix. Run your prompt twice, once with the file and once without, and compare the diffs.

Step 2. Turn a Repeated Task Into a Skill

A skill is a folder that holds a SKILL.md file, and it carries a workflow you would otherwise explain in every chat. Copilot reads the description in the file's header and loads the skill when your request matches it. You can also type / in chat and pick the skill by name.

Project skills live in .github/skills/, and VS Code also reads .claude/skills/ and .agents/skills/. The name must use lowercase letters, numbers and hyphens, and it must match the folder name. VS Code's docs warn that an invalid name makes the skill fail to load silently.

Tip. Write the description as the sentence you would say to ask for the job, such as "Generate Jest tests that follow our AAA pattern." Copilot matches your request against that sentence.

James Montemagno shows an extension that manages agents, instructions, prompts and skills.

Step 3. Pick the File by When Copilot Should Read It

Ask one question for every rule you write: when should this load? The answer picks the file.

Four file types load at four moments, from every request to only when you pick one.

Every request. .github/copilot-instructions.md holds the rules that apply everywhere in the repo.
Matching files only. Each *.instructions.md file under .github/instructions/ carries an applyTo glob, such as **/*.ts.
When the task matches. A skill loads when its description fits your request.
When you pick it. A custom agent is a role you choose from the Agent dropdown.

A custom agent is a .agent.md file in .github/agents/. Its header sets a description, the tools it can use and optional handoffs to the next agent. VS Code renamed these files from custom chat modes, so an old .chatmode.md file needs the new extension.

Keep one home for each rule. GitHub's docs say personal instructions take priority over repository instructions, then organization instructions, and all of them reach Copilot. The harness load order post explains why a duplicate rule drifts. The SEO prompts post shows a plan-first rule that fits in one instruction file.

The DevOps & AI Toolkit channel asks whether Copilot or Claude Action can replace a developer.

Step 4. Turn Each Repeated Correction Into a Rule

Watch for the second time you type the same correction. Stop, write it as one line, and put it in the file that matches how often it applies.

A correction typed twice becomes one committed line that the next session reads first.

Your chat history already holds those corrections. Code Chats to Content copies your VS Code Copilot Chat history and pulls out the coding problems you solved.

Code Chats to Content turns a quarter of Copilot Chat history into content outlines.

Rule of thumb. If a correction costs you a sentence twice, it costs the file one line. Name the exact file, function or command in that line.

Run the two-run test after each new line. If the output does not change, the line is too vague or sits in the wrong file.

Commit the Files so Your Team Inherits Them

Commit the .github folder to Git. A new teammate then gets the same instructions, skills and agents with the repo.

One committed .github folder carries instructions, path rules, skills and agents to a new teammate.

A shared setup pays most on a repo that moves fast. The KubeArmor AI CTF went from nothing to a live platform in one day, and the build journal shows the process.

The KubeArmor AI CTF project page lists the stack and the one-day build.

To carry your editor setup to a new machine, use the one-command VS Code export.

Five Questions Developers Ask About Copilot Setup

Do I need all four file types? No. Start with .github/copilot-instructions.md. Add path instructions, a skill or an agent when one rule keeps breaking after you named it exactly.

Which file wins when two disagree? GitHub's docs rank personal instructions above repository instructions, then organization instructions, and all of them reach Copilot. VS Code's docs call the sources additive and define no order. Remove the conflict at the source.

Are prompt files still worth writing? A prompt file is a .prompt.md file in .github/prompts/ that you run with /name. VS Code's docs say prompt files are deprecated for Agent Host sessions and recommend agent skills instead.

Does Copilot make me faster at all? GitHub's 2022 study gave 95 developers the same task, an HTTP server in JavaScript. The Copilot group finished in 1 hour 11 minutes against 2 hours 41 minutes, which GitHub reports as 55% faster (GitHub, 2022). That run used no custom files.

Where do I find ready-made files? The Awesome Copilot repository collects community agents, instructions and skills. The Awesome Copilot extension lets you browse and download them into your .github folders.

The Appendix Holds Every File and Command

A. Instruction files. My site's repo-wide file, which holds one rule:

# Copilot Instructions

## Component Reuse First

- Before creating any new component, always inspect `src/components/` and `src/components/common/` for an existing component that can be reused.
- Reuse and extend existing components by default.
- Only create a new component when existing components do not fit the task requirements, expected UX, or architectural goals.
- Keep common, cross-page components in `src/components/common/`.
- Keep page-specific components inside their page/domain folders (for example, `src/components/Service/`, `src/components/SkillPack/`, etc.).

The sharper line from run 3, written for your own component:

- Build every FAQ block with `FAQSection` from `src/components/common/FAQSection.tsx`. Never write FAQ markup inline in a page.

A path instruction file, .github/instructions/api.instructions.md:

---
applyTo: "src/api/**/*.ts"
---
- Validate every request body with Zod before any business logic.
- Return a 400 status with a short error message when validation fails.
- Log each request with the shared logger in `src/lib/logger.ts`.

A guard rail for code you do not want rewritten:

---
applyTo: "src/legacy/**"
---
This folder is legacy code. Do not refactor it unless I ask. Keep the existing patterns.

B. A skill. .github/skills/test-generator/SKILL.md:

---
name: test-generator
description: Generate Jest tests that follow our AAA pattern. Use when asked to write or extend tests.
---
When generating tests:
1. Use the Jest framework.
2. Follow the Arrange, Act, Assert pattern.
3. Cover edge cases.
4. Mock external dependencies.
5. Aim for 80% coverage.

C. Commands. Type / in chat to see every skill and prompt file, and /skills to open the skills menu. With Copilot selected, type /agents to open the Agents section of the Agent Customizations editor. In Copilot CLI, run a prompt without a session with copilot -p "<prompt>".

D. The folder tree.

your-repo/
└── .github/
    ├── copilot-instructions.md
    ├── instructions/
    │   ├── api.instructions.md
    │   └── legacy.instructions.md
    ├── skills/
    │   └── test-generator/
    │       └── SKILL.md
    └── agents/
        └── reviewer.agent.md

E. A custom agent. .github/agents/reviewer.agent.md:

---
description: Review a diff for missing tests and unvalidated input.
tools: ['search/codebase', 'search/usages']
---
Review the current diff. List every function with no test and every request body with no validation.

F. An MCP server. VS Code's docs recommend .mcp.json at the project root for a new server and use the key mcpServers. The older .vscode/mcp.json uses servers. Run MCP: Add Server from the Command Palette to create either file.

{
  "mcpServers": {
    "my-local-tool": {
      "command": "node",
      "args": ["./tools/server.js"]
    }
  }
}

G. Sources.

Discussion about this post

Ready for more?