The model is the fulcrum.
The harness is the lever.

Context: the one resource you actually manage

The loop is given; you manage what goes in and when to clear it. Almost every difference in outcome traces here. After each step, you stand at a branch point — 5 choices, 4 of them about managing context quality:

Compaction is lossy: near the limit the whole conversation becomes a summary, and the model continues from it in a fresh window. The danger is when automatic compaction fires — exactly at the model's weakest moment:

Scenario: 5 files read, approach A failed, switch to B.

Companion "Summarize from here": Claude condenses what it learned into a handoff note — a letter from the future Claude to its past self ("I tried A, it didn't work, because…") — so a later session doesn't repeat it.

Rewind is also the cheaper move. It only cuts those turns off the end, so everything before them is still cached and it costs nothing; /compact rewrites the whole conversation and therefore always costs something. If the last few turns went somewhere you don't want to keep, rewind to just before them instead of reaching for /compact.

/compact and /clear both clear context; the difference is who decides what to keep:

New task = new session. For related tasks: highly relevant → continue (skip re-reads); otherwise /clear. Subagent mental test — "do I need the tool output itself, or just the conclusion?" Conclusion only → dispatch. More in Layer 3. The downside belongs here too: without your conversation it sometimes has to re-read what the main session already held while paying for its own turns, so a small job is pure overhead, and the main session only gets back what the subagent chose to report. For a noisy job you hand off repeatedly, give it a definition of its own with model: haiku; otherwise it runs on whatever the main session is running on.

Nothing gets sent just once. Anything that lands in the conversation, a file Claude read or the output of a command it ran, is sent again on every turn after it for the rest of the session (a turn being one complete round trip from your or a tool's input to the model's response). Those re-sends are cached and therefore cheap, but cheap is not free, and they occupy room the model has to think around on every turn. A session's cost comes down to three things:

The startup share is directly inspectable: run /context in a fresh session to see what is loaded, keep CLAUDE.md to specific instructions and move workflow-specific material into skills that load only when used, and turn off any MCP server this session does not need with /mcp. Almost everything added later is tool results, and how much Claude reads depends on how much it has to work out on its own:

The file takes up the same room either way, so mention it once per conversation; @-mentioning it again on a later turn generally attaches a second copy.

The other side is command output. Whatever your tests, a build or a git log prints is appended just like a file Claude read, and stays for the same number of turns. The counterintuitive part sits on either side of one threshold:

Claude will often handle this with flags and tail; for tighter control, the docs have a small hook that rewrites noisy commands before they run so only the lines that matter come back. The cheaper habit is to put the two or three commands you run all day into CLAUDE.md, quiet flags included, written the way you would type them — running a single test file with npx vitest run --reporter=dot, for instance. It saves a turn and a few hundred lines of output in every session after it.

Retention costs too. One long session costs more than the same work spread over a few short ones, so don't carry one task's context into the next: /clear when you start something new, /compact when the earlier part of the same task is done. The supporting moves: /rename before you /clear if you'll want the session back; when you /compact, say what to keep, or add a Compact instructions section to CLAUDE.md if it is always the same; and on a 1M model, /autocompact 200k puts the auto-compact safety net back where it used to be, which needs Claude Code v2.1.221 or later.

Some turns happen while you are not typing. A /loop fires as a full turn inside the session where you set it up, carrying that whole conversation every time, and if more than an hour has passed since the last turn, that is a cache miss on top. Start a fresh session in another terminal and run the loop from there.

Knowledge & tools: a 7-layer build order

The core framework. An often-missed premise: the harness matters as much as, or more than, the model. First the underlying mechanism — Claude finds code via agentic search, not RAG:

The cost: it needs enough starting context to know "where to begin," and navigation quality tracks setup quality. Conclusion — teams that invest in codebase setup get better results.

Many people think a skill is just a SKILL.md. It's actually a folder — SKILL.md is only the entry point, with scripts, references, templates, even its own hooks alongside it. That's exactly what makes it stronger than a prompt.

Mechanically, each skill's name and description sit in the system prompt, which is what makes them the trigger surface: Claude scans those entries, decides which to use, and invokes it by issuing an ordinary Bash call to cat the relevant SKILL.md into context. Referenced files such as references/api.md are then read with a further cat only when actually needed. The whole load chain is Claude pulling content on demand with general tools, not the harness pre-injecting it.

Anthropic groups the common uses into nine kinds, from looking up docs all the way to ops:

Nine best practices from Anthropic's hundreds of internal skills:

Sharing: small teams check into .claude/skills; for scale, a plugin marketplace (with vetting). A PreToolUse hook logging invocations shows what's popular. One lesson: good skills start as a few lines and improve as you hit edge cases.

MCP brings external data and systems into the session. This piece covers plugging it in, not designing a server (out of scope here). Two cost levers — both client capabilities:

MCP and Skills are complementary: MCP gives tools and data, Skills give operating knowledge, and the strongest agents use both. (The five MCP-server design patterns are out of scope here.)

2.2 gave a build order, "in what sequence to stand up which capabilities." Here is the orthogonal lens: once you already have a concrete instruction, which carrier should hold it? Anthropic groups the carriers into seven, and what separates them isn't function but four axes: when it loads, whether it survives compaction, context cost, and how much authority it carries. Three weren't covered on their own above; the most important is a distinct constraint carrier, Rules (markdown under .claude/rules/, with a paths: field that scopes it so it loads only when Claude touches a matching file). Its split with CLAUDE.md: a rule with no path scope is mechanically the same as putting the text in root CLAUDE.md, always loaded and always burning tokens, so its value lives entirely in paths. A single directory's convention belongs in a nested CLAUDE.md; a cross-cutting constraint scattered across directories (say, "every handler validates input first") fits a path-scoped rule better.

---
paths:
  - "src/api/**"
  - "**/*.handler.ts"
---
All API handlers must validate input with Zod before processing.

The green column, "survives compaction?", is the axis not covered systematically before: put an instruction in a carrier that compaction drops, and in the back half of a long session it may simply be gone. A subdirectory CLAUDE.md vanishing once that directory stops being touched is the easiest one to get bitten by.

What actually decides which CLAUDE.md files load at session start is where the session starts: every CLAUDE.md / CLAUDE.local.md on the ancestor chain from ~/.claude/ down to the launch directory loads at start, and only directories below it are on-demand. Launching in a subdirectory preloads the whole chain's conventions, which is both the intended way to get local context and how context quietly gets heavier.

Hooks fire across the whole agentic loop, with events seeded all the way from SessionStart to SessionEnd, and every tool call re-runs the PreToolUse → tool executes → PostToolUse cycle each turn. Hook configuration lives outside the main context and bypasses compaction entirely. PreToolUse is the one deterministic blocking gate: a hook that exits with code 2 denies the call. The dashed cluster on the right holds off-spine, asynchronous events that fire independently of the main flow.

The last two carriers are best left alone in most cases. Output styles overwrite the default system prompt, stripping "you are a software-engineering assistant" along with its safety and verification habits, unless you set keep-coding-instructions: true; to adjust style, check the built-in Proactive / Explanatory / Learning first. Append-system-prompt applies to one invocation and only adds to the role, but the more you pile on, the less faithfully it's followed.

Close with a "symptom → relocate" lookup. The earlier table reads carrier-first; this one runs the other way: catching yourself writing a certain kind of thing into CLAUDE.md is usually the signal it belongs somewhere else.

Two more symptoms are covered earlier in this section: a "never do X" rule needs hooks plus permissions, with managed settings for org-wide enforcement (see the authority paragraph above); an unscoped constraint that only applies to src/api/** is mechanically identical to putting it in CLAUDE.md unless you add paths: (see the Rules paragraph).

Published alongside Claude Opus 5 on 24 July 2026, Thariq Shihipar's official Anthropic post, "The new rules of context engineering for Claude 5 generation models," extends the less-is-more throughline from 2.6 with evidence from Claude Code itself. For Opus 5 and Fable 5, Anthropic removed over 80% of the system prompt "with no measurable loss on our coding evaluations." It attributes the root cause directly: "Overall, we found that we were overconstraining Claude Code, both through our system prompt and in our CLAUDE.md files and skills." The transcript evidence adds a mechanism beyond context capacity. A single request could inherit "leave documentation as appropriate" from one layer and "DO NOT add comments" from another. Even when Claude recovered the intended answer, it had to spend attention reconciling overlapping constraints before acting. That reconciliation cost is distinct from the token cost of carrying the instructions at all.

The highlighted rows are new to this article. The two unhighlighted ones restate principles covered in 2.1, 2.4, 2.6 and 2.7; only their new parts are added below.

The progressive-disclosure principle is already established; the addition here is its application to Claude Code's built-in tool surface. Anthropic says some of its tools use deferred loading: the agent must retrieve their full definitions through ToolSearch before use, and the Task tools are the named example of what this makes affordable. Section 2.5 described the MCP client-side switch that withholds external tool definitions; here, the same mechanism governs Claude Code's own tools. Anthropic also removed repeated instructions from the system prompt, judging tool descriptions sufficient to carry usage guidance without duplication.

Auto-memory supersedes the old # hotkey workflow by saving relevant work and user preferences automatically. Anthropic presents four forms of rich reference: an HTML artifact created with Artifacts, a detailed test suite, a function in another codebase to port, and a rubric evaluated through dynamic workflows and verifier agents, which lets Claude check taste in a given field against a standard (their example: what good API design looks like). It favors executable or code-adjacent references over prose: "For example, a HTML mockup of a design will generally produce better results than a description of the design or a screenshot." The seven-carrier taxonomy from the earlier "Steering Claude Code" post remains unchanged.

Anthropic packaged the audit as claude doctor, exposed in Claude Code through /doctor, as the automated entry point for rightsizing Skills and CLAUDE.md files. That turns the six reversals into routine maintenance, and the closing section takes the same idea further: build it, then cut it.

Orchestration: who should hold the plan

The question becomes: does Claude carry the whole plan turn by turn, or is it held elsewhere? Principle: don't split small tasks; don't make the model hold an entire large plan in context alone.

The maturity path in one line: conversation first, automation later. Start in natural language, watch what recurs, then harden it:

What separates the three isn't scale, it's one question: who holds the PLAN token. With Subagent/Skill, Claude holds it turn by turn and intermediates land in context; with a Workflow, the script holds it and Claude sees only the final answer.

A Workflow isn't a replacement for a Skill; they're orthogonal: a Skill changes "what the model knows," a Workflow changes "how things are deterministically orchestrated." An agent fanned out in a workflow can load a skill first.

Convergence is the exit condition, not a fixed round count. Triggers: workflow in a prompt / /effort ultracode / a saved command; a built-in /deep-research. On by default for Max/Team/API, manual via /config for Pro, off for Enterprise. Token use far exceeds a normal session — try a small task first; before a big run, check /model and route lighter stages to a smaller model.

The default harness packs planning and execution into one context; on long-running, massively parallel, or adversarial work it breaks — three ways, which is exactly why the plan should move into a script:

Workflows fix all three structurally: laziness — the script holds the full checklist, not done until the loop ends; self-preference — verification by another independent agent; goal drift — the goal lives in the script, immune to compaction.

Comparative judgment beats absolute scoring, especially for ranking.

Counterintuitively, it's often more useful for non-technical work. Of the nine use cases named officially, over half aren't about writing code:

When not to use it: Workflows can produce exceptional results, but not every task needs one and they burn far more tokens. First ask "does this really need more compute" — most traditional coding tasks don't need a five-person review panel. Tips: a detailed prompt matters most; small tasks can use a quick workflow; pair with /loop and /goal; write use 10k tokens to cap; press s to save into ~/.claude/workflows or a skill. Treat it as a starting point, not an endpoint.