The bridge — AGENTS.md and CLAUDE.md

Here’s the part worth the price of admission. If you’ve taken the Claude Code course or the Codex course on this site, you already wrote a convention file for a repo — an AGENTS.md, or a CLAUDE.md. You spent real effort getting it right: the conventions, the don’ts, the architecture notes an agent needs to not embarrass you in review. The natural assumption walking into Copilot is that you start over with copilot-instructions.md and re-encode all of it in a tool-specific file.

You don’t. Copilot reads those files natively. The same AGENTS.md, the same CLAUDE.md, unchanged — drop it in the repo and Copilot picks it up. The work transfers. This is the convergence the rest of this curriculum has been pointing at: the conventions are a property of your repo and your team, not of whichever agent happens to be reading them this week, and the file format is becoming a shared standard rather than a per-tool silo.

Turn it on

Reading these files is gated by a setting per format, so you flip the one matching the file you have:

• AGENTS.md — enabled by chat.useAgentsMdFile. Copilot reads the AGENTS.md at your repo root and treats it as instructions, the same way it treats copilot-instructions.md.
• CLAUDE.md — enabled by chat.useClaudeMdFile. Copilot looks in the familiar places: the repo root, .claude/CLAUDE.md, CLAUDE.local.md, and your personal ~/.claude/CLAUDE.md.

So the file you wrote in another course doesn’t move and doesn’t change. You enable the setting, and the conventions you already captured are in play on every Copilot request — exactly as if you’d written them into copilot-instructions.md, except you didn’t have to.

Nested AGENTS.md — preview

There’s a preview capability for nested AGENTS.md files — a per-directory file that applies to its subtree, useful in a monorepo where each package has its own conventions — behind chat.useNestedAgentsMdFiles. It’s experimental; know it exists, but don’t build your setup on it yet. Path-scoped rules have a stable mechanism, covered in the next lesson.

Which file, when you’re choosing fresh

If you’re not arriving with an existing file, you’re picking a format rather than rescuing work. A practical way to choose:

• If your team standardizes on a tool-agnostic convention file — one AGENTS.md that every agent on the team reads — that’s the most portable choice, and it’s the one the ecosystem is converging on.
• If you’ve already invested in CLAUDE.md from another tool, keep it; Copilot reads it.
• If you only ever use Copilot in this repo, copilot-instructions.md is the simplest and is supported on every surface without a setting.

These aren’t mutually exclusive in spirit, but resist scattering the same conventions across three files — pick the one your team will actually maintain, and keep it the single source of truth.

Why this matters beyond convenience

The deep point isn’t that you saved a copy-paste. It’s that context is repo-shaped, not tool-shaped. Your team’s conventions describe how your code should be written; they shouldn’t have to be re-authored every time you adopt a new agent. The agents that read a shared convention file let you write your context down once and carry it across tools — which is the entire thesis of context engineering: close the gap once, reuse it everywhere.

If you came here from one of the other courses, this is the moment the courses stop being separate tracks and start being one practice with different front ends. If you didn’t, the Claude Code course and the Codex course walk through authoring the same kind of file from the other side — and whatever you write there lands here for free.

Next, the inverse problem: one repo, two zones with different conventions. Path-specific rules with applyTo.