Project context files
Give the agent accurate commands, source paths, and project rules.
Imagine your agent guesses which command starts your project — and guesses wrong. An instruction file your agent reads (what developers call a context file) stops that guessing. What makes it useful is being correct and relevant, not long.
Keep what your project needs day-to-day separate from the brief for this one task. Old instructions can make your agent repeat the wrong thing with confidence.
Why this matters
Guessed commands, paths, and rules fail silently and confidently. A short correct file beats a long drifted one every time.
What to understand
Record what would otherwise be guessed: what you are making, the real commands, who owns what, and a few checked paths — with a why when the rule is not obvious. Keep rules proportional, match the client you actually use, and revisit guidance in the same work that changes the command, boundary, or token location. Coordinate parallel agents per task: what each starts with, who owns shared files, what each hands back.
Watch for
- Copying a setup, test tool, or security promise that is not true here.
- Pasting token values and component details into files that drift apart.
- Assuming every tool reads every filename — check your agent's current docs.
- Deleting nothing and adding a conflicting note at the bottom.
- Letting the agent publish, merge, or touch other systems on its own.
Strong default
Keep shared facts in one trusted place; keep extra copies small and on purpose. Link to longer design or operations docs instead of duplicating them. Prefer "update the lockfile with the package manager" and "preserve the public API unless this task requires a migration" over blanket bans.
When this doesn't apply
Do not add extra copies or per-tool special rules by default. Use the format your project already has. You can use several agents at once when tasks are independent and you know how they fit together — you do not have to.
In practice
Product: a scheduling workspace for small crews.
Commands: use the commands verified in package.json.
UI: reuse components/ui; domain components live in features/.
Tokens: one source in app/globals.css.
Data: authorization and organization scope are enforced server-side.
Verify: replay assignment changes and failed-save recovery.Replace this sketch with your real paths and commands.
Your instruction file should not force approval of everyday work you already asked for. Several agents agreeing is not proof people can use it or it is ready to ship — you still judge the result.
Verify
Ask $context to check that paths and commands are real and flag anything unverified. Replay assignment changes and failed-save recovery against the running result.
Related skills
Use $context to create or improve the file. Continue with agent collaboration for a task brief and AI-ready design systems for focused design context.
Last updated on