The five files you can write to shape how Copilot behaves on your project. One you already know. Four more to go.
The onboarding module taught you Layer 1: the always-on instructions file. That single file already makes Copilot noticeably better. The next four layers let you scope, package, restrict, and enforce behavior without bloating that file.
You do not need all five on day one. Add a layer when you feel a real friction point. Each one is opt-in.
A plain Markdown file at the root of your project. Whatever you write inside it becomes Copilot's permanent context. Project identity, tech stack, code standards, communication style. If a rule should apply to every file in the project, it lives here.
Same shape as Layer 1, except it has an applyTo line at the top that names a file pattern. The rules in the file load only when Copilot touches a file matching that pattern. Python rules for Python files. SQL rules for SQL files.
A folder under .github/skills/ with a SKILL.md inside. The first lines describe when the skill should run. Copilot loads the rest of the file only when the description matches what you are asking for, or when you invoke the skill by name.
A Markdown file that defines a focused role. The header lists what tools the agent can use. The body is the agent's personality and instructions. You pick this agent explicitly when you want narrow, predictable help, not the full-range Copilot.
A small JSON file that lists scripts to run at lifecycle events. Stop fires when Copilot finishes a reply. PreToolUse fires before Copilot edits a file. The script runs every single time. The model cannot skip it, forget it, or work around it.
The whole architecture lives in one column of this table. If you remember the loading rule, you remember when to reach for which layer.
| # | Layer | Loads | Pick this when |
|---|---|---|---|
| 01 | Always-on | Every time, on every request. | The rule applies to the whole project. |
| 02 | Path-scoped | Only when you touch matching files. | The rule applies to one folder or file type. |
| 03 | Skills | When you (or Copilot) invoke it by description match. | You repeat the same multi-step procedure often. |
| 04 | Custom agents | Only when you explicitly pick one. | You want a specialist that cannot wander outside its tools. |
| 05 | Hooks | Deterministically at lifecycle events. | The check must happen every time, no exceptions. |
The most useful thing you can do today is build Layer 1. The other four layers can wait until you feel a real need.
File > Open Folder..github at the root of your project, then create a file inside it named copilot-instructions.md.Ctrl+Shift+I. The instructions file is read on the next request.Every primitive on this page is documented by GitHub or Microsoft. The five-layer organizing concept is adapted from a public principal-engineer reference. Each source below backs a specific section.
Backs Layers 1 and 2. Documents .github/copilot-instructions.md, the path-scoped *.instructions.md pattern, and the applyTo frontmatter glob.
Backs Layer 3. Documents the .github/skills/<name>/SKILL.md structure, the description-match invocation pattern, and the progressive-disclosure loading model.
Establishes when Copilot officially gained skills support. Useful for the historical context behind Layer 3.
github.blog/changelog/2025-12-18-github-copilot-now-supports-agent-skills/Backs Layer 4. Documents the custom agent file format, the tool-restriction model, and how an agent is selected at invocation time.
docs.github.com/en/copilot/concepts/agents/cloud-agent/about-custom-agentsBacks Layer 5. Documents the hooks.json file, lifecycle event names (Stop, PreToolUse, etc.), the deterministic-execution guarantee, and exit-code behavior.
Umbrella reference. The VS Code-side index of every customization surface this page covers.
code.visualstudio.com/docs/copilot/customization/overviewOrigin of the layered framing used on this page. The five-layer ordering and "always-on / conditional / on-match / opt-in / deterministic" loading model is adapted from this principal-engineer reference. Cited because it is the conceptual ancestor, not the technical documentation.
gist.github.com/LawrenceHwang/6194421c3bb4208fff84452b403e191a