Context Is Part of Correctness

In addyosmani/agent-skills, context engineering is treated as an engineering control, not as a trick for saving tokens. This chapter explains how the repository decides what an agent should see, when that information should enter the task, and which material must be treated as untrusted. The practical result is a focused context packet that preserves project rules and relevant evidence without allowing stale history, irrelevant files, or instruction-like external text to steer the implementation.

The issue is easy to underestimate. An agent with too little context may invent an API or ignore a local convention. An agent with too much context may lose the active constraint among thousands of lines of background. Both failures can produce fluent work. The difference is whether the context supports the current decision or merely surrounds it.

Context has a hierarchy, not a single size

The repository describes context as a working desk rather than a filing cabinet. Its hierarchy starts with the most persistent material and moves toward the most immediate: project rules, the relevant specification or architecture material, source files for the task, current errors or test results, and the accumulated conversation. These levels do not have equal jobs.

A rules file is where durable conventions belong: the stack, commands, naming patterns, boundaries, and known project-specific hazards. A specification or architecture document explains the current feature’s purpose and constraints. Relevant source files show how the codebase actually implements nearby behavior. Error output tells the agent what is failing now. Conversation history can preserve useful decisions, but it is also the most likely layer to accumulate stale attempts, replaced drafts, and assumptions that no longer apply.

This ordering gives the agent a way to refresh itself without starting from nothing. If work moves from authentication to reporting, the rules remain relevant, but the feature-specific specification, source examples, tests, and current failure change. A session should not carry every file from the first task into the second merely because the context window permits it. The active boundary has moved.

The hierarchy also clarifies why a project rules file is not a substitute for a task packet. Rules say how this codebase generally works and what it will not permit. The task packet says which part of the system is relevant now, which acceptance condition is active, and which existing pattern should be followed. Mixing those roles either makes the permanent file too large or leaves the current task underspecified.

More context can reduce quality

Context starvation is the obvious failure: the agent lacks the project’s conventions, the type definition it must respect, or the test that reveals the expected behavior. The remedy is not to paste the entire repository into the prompt. It is to load the file being changed, the related tests, one nearby example of the desired pattern, and the types or interfaces involved. This gives the agent a local model with a reason for each included item.

Context flooding is less visible because the agent appears well informed. The important command can be buried under old error output.