Context engineering for coding agents

Most teams try to fix AI coding tools by changing the model or the prompt. The bigger lever is usually the repository: what the agent can see every session, before anyone types a word.

That work is context engineering. It is the difference between an assistant that invents a second formatCurrency and one that finds the one you already have.

What “context” means here

For Copilot, Cursor, Claude Code and similar tools, context is the durable instruction and project memory the agent loads at the start of a task: AGENTS.md, .cursor/rules, Copilot custom instructions, architecture notes, and the examples those files point at.

It is not a longer chat. Chat dies when the window closes. A short file in the repo survives every session and every engineer.

What belongs in the file

Keep it short. A few hundred tokens of the right facts beat a thousand tokens of generic advice.

1. What this repo is. Two or three sentences: product, stack, how it is deployed.
2. Commands that must work. Build, typecheck, test — the exact scripts, not “run the tests”.
3. Conventions with examples. Point at a real file (see src/components/Button.astro) instead of describing style in the abstract.
4. Hard constraints. Banned libraries, secrets that must never appear in prompts, paths agents must not touch.
5. How review works here. Generated code is a draft; changes too large to review go back; CI owns formatting and secret scanning.

If a rule cannot be checked somehow — by a person in review, by CI, or by the absence of a banned import — it will not survive the first exception.

What does not belong

• A pasted style guide. Put that in the linter.
• Every possible npm script. Agents already know common tools; list only the ones that are surprising.
• Edge cases you hit once. Add a rule when the same mistake repeats.
• Secrets, production URLs with credentials, or customer data. Treat agent config as code that will leak.

One source of truth across tools

Teams often maintain .cursorrules, Copilot instructions and a README section that disagree. Pick one portable file (AGENTS.md at the repo root is a good default), keep tool-specific rules thin, and link back to the shared file.

When the agent makes the same mistake twice, update the file in the same pull request that fixes the code. Context that does not change when the codebase changes becomes noise.

How you know it worked

Context engineering is not a vibe. Take a baseline before you rewrite the rules:

• suggestion acceptance on real tasks (not demos)
• review time and pull request size on the same team
• how often reviewers send work back for “duplicate of existing helper” or “invented API”

Change the context files. Leave the model and the seat count alone for a sprint. Read the same numbers. If nothing moved, the file is still wrong — usually too long, too vague, or pointing at examples that no longer exist.

The readiness check scores tools and skills separately from review. Context engineering sits between them: better tools only help if the repository teaches the agent your house style. The policy template still decides which tools may see the code at all.

A minimal starting point

# AGENTS.md

## Project
[One paragraph: what this repo ships, language, deploy target.]

## Commands
- `npm run check` — typecheck; run after substantive edits
- `npm test` — prefer a single file when iterating

## Conventions
- Prefer patterns in [path/to/canonical/example]
- Do not add a dependency that duplicates [existing module]

## Guardrails
- Never commit secrets or put them in prompts
- Do not modify [locked paths] without an explicit ask
- Generated changes must stay reviewable; split large diffs

Fill the brackets, delete anything you cannot enforce, and treat the file as part of the product — not a one-off prompt dump.

If you want this done inside a real codebase with your conventions and CI, that is the Context Engineering Setup on the pricing page. If you only need the score of where you are today, start with readiness.