Feed Claude the right context, not everything

Put in the prompt exactly what the task touches: the goal, the rules it must obey, and the one or two files it reads or changes. Leave out the rest. More text does not produce a better answer. It dilutes the signal and makes the relevant lines harder for Claude to find.

This guide is about that judgement call: what goes in, what stays out, and how to load it with the Claude Code CLI so you do not paste the same thing twice.

Why is sending everything the wrong default?

A reflex when Claude gets something wrong is to add more: paste another file, paste the whole module, paste the README again. That reflex is backwards. The model reads every token you send, on every turn. When the request that matters sits inside 200,000 tokens of unrelated code, it competes with all of it for attention.

Three concrete costs come with stuffing the window:

• Attention dilutes. A precise instruction buried in a wall of files is easier to miss than the same instruction in a tight prompt.
• Cost rises. You pay per input token, every turn. A bloated context that repeats across a 30-turn session multiplies that bill.
• Contradictions creep in. Two stale files that disagree force Claude to pick one, and you do not control which.

The skill is selection. A context windowThe text Claude reads before it answers: your prompt, loaded files, conversation history, and any rules is a budget, and you are the one deciding how to spend it.

The three questions

Before you send a prompt, run each candidate piece through three questions.

1. Does the task touch this? If Claude is fixing a login bug, the billing module does not belong in the window. The file being edited, the function being called, the error being chased: those touch the task.
2. Must Claude obey this? Rules, type signatures, an API contract, the exact output format. Constraints belong in the window even when they are not "code," because breaking them is the most expensive kind of wrong answer.
3. Will Claude fail without this? A schema it must match, a sibling file that defines the interface, the full error trace. If the answer depends on it, include it. If the answer would be identical without it, cut it.

If a piece fails all three, it is noise. Leave it out.

What belongs in the context window?

Everything outside these four is a candidate for the cut: unrelated files, abandoned ideas from earlier in the chat, generated lock files, a README that repeats what the code already says.

Include, conditionally include, exclude

Be specific, not exhaustive

Vague prompts make Claude guess, and guessing pulls in more than you need. Name the file. Name the function. State the rule. Compare these two requests for the same task.

A vague request that forces Claude to explore the whole project:

A precise request that points at exactly what the task touches:

The second prompt names two files, states the symptom, and sets one constraint. Claude reads those two files and nothing else. The window stays tight and the answer stays on target.

How do I load files into Claude Code without copy-paste?

Pasting file contents into the chat works, but it is slow and it gets stale the moment you edit the file. Claude Code gives you cleaner tools.

@-mention the files the task touches

Typing @ followed by a path in your message loads that file into the context for that turn. Mention only the files the task reads or changes.

This loads two files. It does not load the rest of the directory, and it does not ask Claude to go hunting. You decided the scope; Claude works inside it.Common gotchaAn @-mention loads the file as it was at that turn, not a live link.If Claude edits it ten turns later, your original mention is now a stale copy, so re-mention the file after a big change to refresh the window with the current text.

Let Claude retrieve instead of pre-loading

When you know the subsystem but not the exact file, do not dump the folder. Ask Claude to find it. Claude Code runs grepA command-line tool that searches file contents for a pattern and file reads as tool calls and pulls in only the lines that match.

Only the matching excerpts land in the window. This is retrieval over stuffing: search for the signal, do not import the haystack.

Choose the loading method by what you know

Where do durable rules belong?

Some context is not about one task. It is the same on every task: your coding conventions, the build command, where handlers live. Pasting that into every prompt wastes your time and the window. Put it in a CLAUDE.md memory file instead.

A CLAUDE.md at the project root is loaded at the start of every session, so the rules are present without you re-typing them. Keep it to facts that apply every time.

# Project rules
 
- Run `npm test` before every commit.
- API handlers live in `src/api/handlers/`.
- Use 2-space indentation.
- Co-locate tests with source as `*.test.ts`.

The official guidance is to keep each CLAUDE.md under 200 lines. Longer files consume more context and Claude follows them less reliably, so write specific rules and delete ones that no longer apply. A vague rule is noise that still costs tokens.

For instructions that only matter in part of the codebase, scope them to a path with a rule file under .claude/rules/ so they load only when Claude works with matching files:

---
paths:
  - "src/api/**/*.ts"
---
 
# API rules
 
- Every endpoint validates its input.
- Use the standard error response format.

This keeps the always-on CLAUDE.md lean while still giving Claude the right context when it opens an API file.

What this looks like end to end

The stable layer loads itself. You add only the task-specific files. You name the goal and the rules. Claude fetches anything else on demand. At no point do you paste the whole project.

Watch and trim a long session

A long session accumulates history fast. Tool calls, file reads, and earlier answers pile up, and old turns about a direction you abandoned become pure noise.

See where the window is going

Run /context to see current usage as a grid, with suggestions for context-heavy tools and warnings as you approach capacity.

/context

Run /cost (an alias for /usage) to see what the session has cost and how usage breaks down.

/cost

Check these before starting a large task. If the window is already full of stale work, clear or compact it first.

When should I use /compact versus /clear?

When the conversation grows long but you are still on the same task, run /compact. It replaces the raw history with a summary and frees the window while keeping your direction.Common gotchaDo not run /compact right after loading a file or error trace you still need Claude to work from verbatim.The summary is lossy, so the exact line numbers, the schema, or the failing assertion can get paraphrased away, and Claude then edits against a blurred memory of the code. Compact first, then @-mention the files for the next step so the real text is fresh in the window.

/compact

When you switch to an unrelated task, run /clear. It starts a fresh conversation with an empty window while keeping your project memory, so old auth-debugging turns do not leak into a new layout task.

/clear

The rule of thumb: /compact to stay light inside one task, /clear between tasks. A project-root CLAUDE.md survives both. After /compact, Claude re-reads it from disk and re-injects it, so your rules persist.

Common mistakes

A checklist before you hit enter

• Does every piece in the prompt touch the task, gate it, or prove a failure?
• Have I named the files instead of dumping the folder?
• Have I stated the goal and the constraints in plain words?
• Are durable rules in CLAUDE.md, not re-pasted?
• If the session is long, have I run /context and then /compact or /clear?
• Am I sending a full file when Claude only needs one function?

A prompt that passes this list is cheaper, faster, and more accurate than one assembled by reflex. For the deeper mechanics of the window itself, read Context Engineering. For loading external tools and data without bloat, see MCP fundamentals.