I ship with Claude Code every day, and I build openseek — an open-source TUI coding agent — so I spend as much time watching how an agent reasons as I do coding with one. The tips below are not the obvious "write a CLAUDE.md" advice you have read ten times; they are the habits that actually moved my throughput.
One caveat: Claude Code moves fast, and specifics like default subagent types or flag names drift between releases. I have described stable patterns and hedged where behavior is version-dependent — when in doubt, check claude --help and Anthropic's docs against your version.
1. Treat CLAUDE.md like an API contract, not a wiki
The most common CLAUDE.md failure is not "too short" — it is "too much narration." The agent reads this file every session, so every line competes for attention with your task. Keep it lean (many keep it under ~200 lines per project), but the shape matters more than the length.
Write it as imperative rules the agent can obey, not prose it has to interpret. Bad: "We generally prefer to run tests before committing." Good: "Before any commit, run npm run verify; do not commit if it fails." Put load-bearing facts near the top — the deploy model, the one command that must never run, where the real source of truth lives. In my repos the first section is always "load-bearing rules": the things that break production if violated.
Why: a rule the agent can execute beats ten sentences it has to reason about. Narration gets skimmed; commands get followed.
2. Manage context on purpose — /clear between tasks, /compact within one
Context saturation is the single biggest quality killer I see. As the window fills, the model forgets constraints you set early, misreads requirements, and makes careless mistakes. The fix is not a bigger model — it is discipline about what stays in the window.
My rule: /clear when the task changes, /compact when the task continues. Finished the payments bug and moving to logging? /clear — you don't want the old thread bleeding in. Still deep in one feature but the window is filling? /compact around 70–75% utilization, before quality degrades rather than after. A fresh context is almost always sharper than a 90%-full one.
Why: output quality tracks context quality far more than raw session length. Clearing loses nothing if the durable decisions already live in a file.
3. Persist decisions to disk, not to the chat
When Claude makes an important call mid-session — "we're using optimistic locking here because X" — that reasoning lives only in the transcript until you /compact or /clear it away. Push durable decisions into a file: CLAUDE.md for stable repo facts, a scratch MEMORY.md or progress note for task state.
I keep a progress/ note in bigger repos that the agent updates as it goes, so when I /clear, nothing important is lost and the work stays restartable across days.
Why: chat is volatile memory; files are durable memory. Anything you would be annoyed to re-explain tomorrow belongs in a file today.
4. Explore, then plan, then code — and actually use plan mode
The workflow Anthropic recommends, and the one that saves me from the "confidently built the wrong thing" failure, has three phases. First, in plan mode, have Claude read the relevant code and explain how it actually works — no edits. Then have it produce a concrete plan: which files change, the flow, what could break. Only then leave plan mode and implement against that plan.
The planning step forces the agent to surface dependencies before it touches code — exactly where wrong-problem failures get caught cheaply. I skip it only for genuine one-liners; for anything touching more than two files, the five minutes pays for itself many times over.
Why: a plan you can read is a plan you can veto. Catching a bad approach in a plan costs a sentence; catching it after implementation costs a revert.
5. Fork to subagents for breadth, stay inline for depth
Subagents run work in an isolated context window and hand back a summary. People get this wrong by using them for everything. The heuristic that works: fork for breadth, stay inline for depth. Scanning a large codebase, researching options, summarizing many files — fan that out to subagents so their token-heavy exploration never pollutes your main context. Deep, stateful work on one feature belongs inline, where the agent keeps full continuity.
The highest-leverage use I have found is the fresh-context reviewer: before I call anything done, I have a subagent review the diff with only the diff and the completion criteria — not the reasoning that produced it. It catches gaps the author-agent rationalized away. Some setups let subagents nest and spawn their own subagents; that is powerful but easy to over-orchestrate, so reach for it only when the task genuinely decomposes.
Why: isolation is the point. A reviewer that never saw the reasoning is a real second opinion, not an echo.
6. Set up permissions so you stop babysitting
Nothing kills flow like approving git status for the hundredth time. Configure an allowlist of the safe, read-only commands you run constantly (status, diff, lint, test runner) so Claude stops prompting, and keep the dangerous stuff (force-push, destructive migrations, rm) on manual approval.
If you have used --dangerously-skip-permissions to escape the prompts, look at the newer auto permission mode instead — it aims to skip interruptions without fully removing guardrails, recovering to a safer approach when a check blocks something. Pair permissions with hooks for automated gates. Scan your own transcripts for the calls you approve over and over — those are your allowlist.
Why: every needless prompt is a context switch for you. Allowlist the boring, gate the destructive, and the agent runs while you think.
7. Install skills for recurring know-how — not more MCP servers
When you find yourself pasting the same primer prompt across projects ("here's how our deploys work", "here's the migration checklist"), that is a skill waiting to be written. A skill is a small, versioned package of instructions the agent loads only when relevant, so it teaches a capability without permanently bloating the system prompt — the opposite trade-off from MCP servers, which load their tool descriptions up front and spend context before you have typed anything.
My bias is to reach for a skill before a new MCP server whenever the need is "teach the agent how X works" rather than "connect a live external tool." I keep a curated set for my stack and browse the community index at orangebot.ai/skills for the rest. If you have never installed one, start with how to install Claude Code skills, then skim the best Claude Code skills for 2026.
Why: skills compound — write once, reuse across every project and teammate, without paying context tax until the moment it is needed.
8. Compose the primitives — skills, subagents, hooks, slash commands
The real unlock in 2026 is not any single feature; it is composing them. A slash command kicks off a plan-mode review; a hook enforces the linter; a subagent does the diff review; a skill supplies the deploy playbook. Each is weak alone and strong together. For the mental model of how these fit — slash command versus subagent versus hook — see the subagents, hooks, and slash commands guide. The failure mode is over-engineering: add each primitive when a specific annoyance justifies it, not preemptively.
Why: the primitives multiply. A good allowlist plus a reviewer subagent plus a lean CLAUDE.md is a workflow that runs unattended and still lands correct diffs.
The short version
Keep CLAUDE.md as executable rules. Clear between tasks, compact within one, persist decisions to disk. Plan before you code. Fork subagents for breadth and use one as a fresh-context reviewer. Allowlist the boring commands. Install skills for recurring know-how, and compose the primitives instead of hoarding them. None of this is exotic — it is just the difference between an agent that drifts and one that ships.
I write up what actually changed in the tooling each week: new skills worth installing, model updates, patterns that held up under daily use. If you want that in your inbox, subscribe to the weekly — and when you are ready to add a skill, the full browsable index is at orangebot.ai/skills.