Context Engineering (the Missing Discipline)

A coding agent is only as good as what's in its context window. The context window is the agent's working memory: every file you've shown it, every message you've typed, every command output, every line of code it's read. The window is finite. Even the largest frontier models top out somewhere, and "fitting" is not the same as "using effectively." A context window stuffed with 50 files of irrelevant code is worse than a context window holding the 5 relevant files.

This is the constraint everything else in the playbook responds to. Performance degrades as the context fills. The agent starts forgetting earlier instructions. It makes more mistakes. It repeats things you've already clarified. The fixes in 2.6 (the four-phase loop, the prompt patterns, the session management moves) are all, underneath, fixes for the same problem: how do you keep the right things in the agent's context window and the wrong things out.

Context engineering is the name for that discipline. It has four moves.

MOVE 1: PROJECT-LEVEL CONTEXT. Put a CLAUDE.md (or AGENTS.md, or .cursorrules, or whatever your tool reads) at the root of every project. This file explains what the project is, what the stack is, what the conventions are, and what NOT to do. The agent reads this on every session. It prevents the agent from "forgetting" the rules every time you start a new conversation. Section 2.6.1 covers what goes in (and what stays out). Template in section 8.3.

MOVE 2: SELECTIVE FILE INCLUSION. Don't dump the whole repo into the agent's context. Choose the 3-5 files relevant to the current task. Most agents have ways to do this: file tagging, @-mentions, or pointing to specific paths. Use them. Reading too many files isn't being thorough, it's being expensive: every irrelevant file in the context is a file the agent has to filter past to find the one that matters.

MOVE 3: SESSION BOUNDARIES. When you switch tasks, start a new session. Old context that isn't relevant anymore is noise the agent has to filter out, and it doesn't always filter well. The /clear command in Claude Code (and OpenClaude, and most other CLI agents) is the operational form of this move. Section 2.6.4 covers when to clear, when to compact, and when to rewind.

MOVE 4: STATE PERSISTENCE OUTSIDE THE MODEL. Anything important (the spec, the data model, the conventions, the things you've decided) lives in a file in your repo, not in the chat history. Chats end. Files persist. If the agent forgot something important, the answer is "I should have written that down" not "the agent is broken." This is also why the spec discipline in 2.2 matters: a spec is a piece of state that survives session boundaries.

The mental model for context engineering, taken whole: you are not having a conversation with an AI. You are preparing a workspace for a new junior engineer who shows up every morning with no memory of yesterday. The CLAUDE.md, the spec docs, the file structure, the README, the data shape document, the design tokens file, the roles document (see Part 5) are how you onboard them in 30 seconds instead of 30 minutes.

A reader who internalizes context engineering will look at the playbook in 2.6 and see why each pattern is shaped the way it is. The four-phase loop is context engineering applied to a single task. The prompt patterns are context engineering applied to individual messages. The session management moves are context engineering applied across time. The failure modes are what happens when context engineering breaks down. It is, more than any other single concept, the through-line of Part 2.