Context Engineering.

Context engineering designs everything a model receives during a task, whereas prompt engineering focuses on the words in one request. Context can include instructions, conversation history and summaries. It can also include source files, tests and documentation. Tool results can land there too.

A strong prompt cannot fix missing or misleading context. If the model cannot see the current interface or a project rule, it must guess. Context engineering puts the right information in front of the model at the right time, and removes noise that could distract the model.

Context engineering also decides how context is retrieved, ordered and kept current. It covers what carries over between sessions too. Prompt writing is one part of the larger job of building a reliable information environment for the assistant.

Instruction files hold standing guidance for a coding assistant. They describe the repository layout, the build and test commands, and the coding conventions. They also set safety limits and the expected definition of done. Tools load them automatically at the project or directory scope.

They solve the problem of repeating stable facts in every prompt. Without them, each session may guess how to run tests or which helper to use.

Keep them short and specific, link to longer docs instead of copying them, and never put secrets in them.

Put in stable facts that affect many tasks:

• important directories
• standard commands
• architectural boundaries
• naming rules
• approved libraries
• any dangerous action that needs approval

Add a short definition of done, such as running focused tests and reporting any failures.

• Leave out secrets, credentials and customer data.
• Leave out temporary task details and long tutorials too. Point to a trusted document instead of copying it.
• Skip vague advice such as "write good code", because it gives the model nothing to act on.
• Drop rules that tools or linters already enforce, unless the assistant needs them to choose an approach.

A useful file is a small map and policy guide, not a complete project handbook.

A context window is the amount of text and other tokenized information a model can consider in one request. It holds:

• the prompt
• the instructions
• the prior conversation
• source files
• tool output
• the model's own response

Every model has a limit. When the window fills, older content may be removed or summarized, and important details can be lost. Even before the limit, too much unrelated material can make the model overlook the right fact.

Give the assistant current, relevant sources instead of a repository dump. For long tasks, record decisions and progress in a compact handoff. Careful context selection improves accuracy, cost, and speed.

Nearly everything the agent reads or writes consumes tokens:

• Standing text: system and project instructions, and the tool definitions.
• The conversation: your messages, earlier replies, and any summaries.
• What the agent reads: source files, search results, and documentation.
• What tools return: command output, error logs, and diffs.

Repeated content can be charged and processed again unless caching applies. Large test logs, generated files and broad searches fill the window fast without adding much value. Ask for focused output, open only the relevant file sections, and filter noisy command results.

Keep standing rules lean, because they appear in many requests. When a task changes direction, start a fresh session instead of carrying unrelated history. Watching tokens saves money, and it also keeps the model's attention on the evidence that matters.

Rules files are loaded often, so every unnecessary paragraph uses context on many requests. Long files also make important guidance harder to notice. Conflicting or overly detailed rules can cause the assistant to follow the wrong instruction, or to spend time reconciling advice that does not apply.

Keep only stable, high-impact facts that change how work should be done.

• Use clear commands, short examples, and links to deeper documentation.
• Move subsystem guidance into scoped files when the tool supports them.
• Remove rules that a formatter, type checker, or test already enforces.
• Review the file after repeated agent mistakes and after architecture changes.

Lean rules reduce cost, improve attention, and are easier for people to keep accurate.

An AI-legible repository makes its structure and intent easy for an assistant to discover. It has:

• clear names
• small focused modules
• typed interfaces
• current docs
• reliable tests
• standard commands

Important behavior is written down instead of living only in team memory.

In such a repository, an agent can find the owning module and inspect a nearby example. It can run one documented test command and understand what success means. Hidden setup and duplicate patterns force it to guess. Vague names and stale docs do the same.

Improve legibility by making boundaries explicit, removing dead code and documenting unusual decisions. Keep examples current. The goal is to make project knowledge visible and verifiable, which helps human developers too.