Instructions Files & applyTo, Explained From Zero

Custom instructions are great until your project grows and one rulebook stops fitting all of it. This guide shows how to give a large codebase layered, scoped guidance — the right rules in the right place — without overwhelming the assistant.

1 · One rulebook is not enough

Custom instructions apply to everything, all the time. But real projects aren't uniform: your frontend has different conventions than your backend, your tests follow different patterns than production code, your database layer has rules that would be nonsense applied to a stylesheet. Cram all that into one always-on file and two bad things happen: it gets huge and unfocused, and the assistant gets rules that don't fit what it's touching — backend rules while writing a button. Instructions files with scoping let you apply different guidance to different parts of the codebase, so the assistant always gets rules that fit the file in front of it.

2 · Scoped by file path

An instructions file — in Copilot, a file ending in .instructions.md — can carry a small setting at the top called applyTo, a path pattern that decides which files the instructions apply to. If applyTo matches test files, those instructions switch on only when working on a test. The pattern uses simple wildcards: something like **/*.test.ts means “any file ending in .test.ts, anywhere.” So you can write “in tests, use Vitest and one assertion per test,” scope it to test files, and it only ever guides test-writing. It's a rule that knows when it's relevant and only speaks up then.

3 · A folder of focused rulebooks

This lets you build a tidy set of small, focused rulebooks instead of one bloated file. A frontend instructions file scoped to your UI folder, with your React and accessibility conventions. A separate api file scoped to your backend folder, with validation and error-handling rules. A tests file scoped to test files. Each is short and specific, and each activates only where it belongs. When the assistant edits a UI component, it gets your frontend rules and nothing irrelevant; when it touches an endpoint, your api rules. This is cleaner and more scalable than one giant file, and it mirrors how you'd organise the knowledge in your head.

4 · Why scoping makes it better

Scoping isn't just tidiness — it makes the assistant genuinely better, for two reasons from the fundamentals. Relevance: the model only receives rules that fit what it's touching, so it's never confused by inapplicable guidance, and its suggestions land more precisely. Context economy: remember the limited desk. If every rule for every part of your project loaded on every request, you'd waste that precious space on irrelevant instructions and pay for it too. Scoping means only the applicable rulebook takes up room. So you get sharper help and more efficient use of the context window — the one manual page you need, not the entire handbook.

5 · The layered picture

Now the pieces click into a clean, layered picture that echoes the system-developer-user layering from prompt engineering. At the broadest layer: your custom instructions, always on, describing the whole project. In the middle: scoped instructions files, each activating for a particular area. At the most specific: prompt files, invoked on demand for individual tasks. Each layer only adds what the layer below doesn't cover, so nothing repeats and everything stays focused. This is how you give an assistant deep, well-organised knowledge of a large codebase without overwhelming it — the right context, at the right scope, at the right moment.

6 · Start global, split when needed

Don't over-engineer this. You don't need a dozen scoped files on day one. Start simple: one custom-instructions file for the whole project. Reach for scoped files only when you feel the strain — when your single file gets long, or when rules that only make sense for one part collide with another. That's the signal to split: pull the frontend-only rules into a frontend-scoped file, the test-only rules into a test-scoped file. Let the structure grow to match your project's real complexity, not an imagined one. A small project may never need scoping; a large one will thank you for it. Scope when one rulebook stops fitting, and not before.

7 · Portable across the team

As with everything here, scoped instruction files live in your repository and travel with it, so their benefit is collective. Every developer's assistant applies the frontend rules in the frontend and the backend rules in the backend, automatically and consistently — no one has to remember which conventions apply where, because the files know. A new teammate opening a test file immediately gets your testing conventions. That area-specific expertise, which usually lives only in senior engineers' heads, is now encoded and applied the moment anyone touches the relevant code. And because these are versioned files, your conventions evolve deliberately — update the api rules once, and every assistant follows the new standard.

8 · A simple test you can run this week

9 · Glossary — every term, spelled out

Instructions file

A .instructions.md file of guidance that can be scoped to specific files.

applyTo

A path pattern at the top of an instructions file that decides which files it applies to.

Glob / wildcard pattern

A path with wildcards (like **/*.test.ts) that matches a set of files.

Scoping

Applying a rule only where it's relevant, rather than to the whole project.

Context economy

Using the limited context window efficiently by loading only the rules that apply.

Layered guidance

Always-on instructions, scoped instructions, and on-demand prompt files — general to specific.