Of the three major coding agents, GitHub Copilot has the most
constrained instruction surface: one file
(.github/copilot-instructions.md), loaded into workspace context,
with the least room of the three. That constraint is not a limitation
to work around, it is the design brief. Here is what the file should
contain, and what to expect from it.
What belongs in the file
At ~20-30 lines, the file forces triage. The content that earns its
place, in order:
1. The stack in one line.
TypeScript on pnpm. Source in
src/, tests in**/*.test.ts.
Test:pnpm test. Lint:pnpm lint.
Copilot is at its best in inline completion and chat, both benefit
most from knowing the environment without exploration.
2. The two or three conventions with the highest violation cost.
Not everything, the conventions whose absence hurts most in review:
Conventional Commits, imperative summary. Async handlers wrapped so
rejections hit the error middleware. No new dependency without
discussion.
3. The safety rules. Secrets handling, destructive commands,
generated files. Short, absolute, non-negotiable.
4. The testing expectation, singular. One sentence. "Bug fixes
come with a regression test" outperforms a paragraph of test
philosophy.
What to leave out
- Everything your linter enforces. Copilot does not need the style guide the formatter already imposes.
-
The baseline itself. If you maintain an
AGENTS.md, the Copilot file is a condensed projection of it, the 20 lines that change Copilot's most common operations, not a copy (the copy blows the budget and helps nothing). - Tasks and state. TODO lists, current sprint focus, migration status, anything with a shelf life rots in a file nobody owns.
What to expect (calibrated honestly)
Copilot's instruction-following is the loosest of the three agents.
Set expectations accordingly:
- Strong: language/framework idioms, naming conventions, commit formats, local, per-completion behavior.
- Moderate: error-handling patterns, testing style, shows up with prompting or in chat, inconsistently in pure completion.
- Weak: multi-step procedures, cross-file policies, out of scope for inline completion by design.
The file still earns its keep on the strong tier alone: a developer's
thousands of daily completions shifting a few percent toward house
conventions is a real reduction in review noise. Just do not ask it to
be Claude Code.
The multi-agent reality
If the repo also has CLAUDE.md and Cursor rules, the Copilot file
completes the trio, and one maintenance rule prevents drift: the
Copilot file is derived from the baseline. When the baseline
changes, the question is "which 20 lines does Copilot need now?", a
deliberate re-triage, not an edit in isolation.
Our kits ship that relationship as structure: each of the twelve stack
kits generates the Copilot digest from the same source data as the
baseline, so the projection stays consistent, and because Copilot's
budget is the tightest, the digest is written to its constraints
first, with the other formats expanding from there.
If you'd rather not assemble this by hand: AgentConfig Studio on Gumroad ships this as version-pinned, validator-tested kits for 12 stacks. The complete Next.js/TypeScript kit is free (MIT) if you want to inspect the structure first.
Top comments (0)