Context Scope: What to Put Into Claude, and Why It Matters

The issue: Researchers tend to think about context as a technical container — how much fits, how to avoid limits. The more important question is different: what should you include, and what should you leave out? Getting scope wrong does not just waste tokens — it degrades the quality of Claude's output in specific, predictable ways. Too much information and too little information both produce bad results, but different kinds of bad.

What "scope" actually means

The context you give Claude does two things simultaneously:

  1. It informs — Claude knows your project, your conventions, the document it is reading
  2. It frames — Claude understands what the task is, what counts as relevant, what kind of answer is expected

The framing effect is the less obvious one. What you include signals to Claude what the task is about and what matters. Including your hypothesis tells Claude the answer you expect. Including irrelevant background tells Claude to write for a broader audience than your actual question. Including previous interpretations alongside new material tells Claude to synthesise rather than read freshly.

Context is not a neutral input. It shapes what Claude thinks the job is.

How to decide what to include

The knowledgeable colleague test

Imagine explaining this task to a capable colleague — someone with general research competence but no prior knowledge of your specific project. What would you tell them before they started? That is your context. Not more.

You would not read them your entire research notes before asking them to check your bibliography. You would not explain your whole theoretical framework before asking them to format a table. Match the context to the task.

The "relevant and only relevant" principle

Include what bears on this task. Exclude what does not. A CLAUDE.md full of project background is right for reading a new primary source — it is wrong for converting a DOCX to markdown. A 20-page chapter is right context for "give me feedback on Section 3" — it is wrong context for "fix the citation in footnote 47."

The asymmetry between execution and interpretation tasks

For execution tasks (format this, extract that, convert this file), err toward more context: Claude needs to know your conventions, your output format, your terminology. This extends to compliance-sensitive tasks — drafting a grant proposal section, preparing a journal submission, filling in an institutional form. Claude's sense of what these forms require is approximate; giving it the actual specification as context (the tender document section headings, the character limits, the required subsections) is what makes output conforming rather than merely plausible. See A.issue.bounding — the "when the form is the bound" section.

For interpretation tasks (what does this source suggest, is this argument coherent, what are the weaknesses here), err toward less context: giving Claude your expected conclusion alongside the material to be interpreted is one of the most reliable ways to get a biased, useless assessment.

The "too much" crisis states

Hypothesis confirmation bias

If you tell Claude your hypothesis before asking it to analyse data or sources, it will tend to find confirmation for that hypothesis. This is not dishonesty — it is a structural property of how Claude tries to be helpful. A helpful response to "does this data support hypothesis X?" is shaped by the fact that you are already working with hypothesis X.

Consequence: You get a sycophantic analysis that mirrors your expectations back at you. The analysis may be wrong and will feel convincing.

Mitigation: For analytical tasks, give the material first and ask the question without signalling your expected answer. Ask Claude to argue against your hypothesis, not just for it. See also: A.critical.limitations — the "vibe research" section.

Attention dilution

When you give Claude a broad context — a long project background, many documents, a detailed CLAUDE.md — it writes for all of it. A question about one specific source gets an answer inflected by everything else you included. The output is generic relative to your actual question.

Consequence: Responses that are correct but not useful — they address a more general version of your task than the one you actually have.

Mitigation: Narrow the context to the task. Even with a project-level CLAUDE.md, specify in the prompt what is relevant to this particular request.

Voice contamination in reading and note-taking

If you give Claude your previous notes or interpretations alongside a new source and ask it to take notes, it will synthesise the new source with your existing interpretations rather than read it freshly. Your prior framing infects the new reading.

Consequence: Your notes on the new source reflect your existing views more than the source itself. The value of reading — encountering something new — is lost.

Mitigation: For primary reading tasks, give Claude the source and a clean brief ("read this and tell me what it says about X"), without your prior interpretation. Keep reading mode and synthesis mode separate. See also: A.workflows.notes-reading-writing — the "reading mode not writing mode" principle.

CLAUDE.md bloat

As a project grows, CLAUDE.md accumulates instructions. At some point it becomes too long to be reliably followed. Claude starts selectively attending to parts of it; some instructions are quietly ignored.

Signs: Claude produces outputs that follow some CLAUDE.md conventions but not others. Instructions near the end of a long CLAUDE.md are more often missed.

Consequence: The persistent context you built to ensure consistent outputs stops working, but silently — you may not notice until you have many inconsistently formatted extractions.

Mitigation: Keep CLAUDE.md focused on what is always true and always needed. Move task-specific instructions into individual prompts. Aim for one page; two pages maximum. Trim when the project evolves and old context is no longer accurate.

Privacy leakage from unfocused file access

In Claude Code, giving broad filesystem access or working from a folder that mixes project files with sensitive or unrelated material means Claude reads things you did not intend to include. This is the context scope problem at the filesystem level.

Consequence: API calls contain data you did not choose to share. See A.issue.privacy-security — the agentic risks section.

The "too little" crisis states

Generic outputs

Without project context, Claude writes for a general audience with no knowledge of your specific field, conventions, or constraints. The output is well-formed but useless for your actual purpose.

Signs: Claude explains basic concepts you already know; uses wrong terminology for your field; produces outputs formatted for a different purpose than yours.

Consequence: Every prompt requires significant re-work, or many follow-up prompts to steer toward what you actually needed.

Wrong constraints

Claude does not know what you have already tried, what you have already ruled out, or what is not possible in your situation. It will suggest approaches you have already rejected or solutions that violate constraints you did not state.

Consequence: Wasted rounds of correction. Claude cannot learn from what it does not know; it will keep suggesting the wrong thing until told why it is wrong.

Misaligned problem-solving

Without enough context, Claude solves a plausible version of your problem — the version that makes sense to someone who does not know your situation. That version may be subtly or significantly different from your actual problem.

Consequence: Outputs that look correct but address the wrong question. These are harder to catch than obviously wrong outputs because they have the shape of a valid answer.

Re-explanation overhead

If you do not maintain persistent context (CLAUDE.md, project notes), every session starts from scratch. Each prompt has to re-establish who you are, what the project is, what conventions you use. This is not just inefficient — it also means Claude has less context than it needs for the first few exchanges of every session.

Consequence: The best part of a session — once Claude is properly calibrated — comes after significant setup time. Sessions become shorter in effective output relative to their actual length.

Maintaining scope over time

Context needs maintenance. A CLAUDE.md written at the start of a project may be wrong six months later — the project evolved, conventions changed, some things you expected to need are no longer relevant.

At project milestones: Read your CLAUDE.md as if for the first time. Is it still accurate? Has the project's focus shifted? Are there conventions listed that you no longer use? Remove what is no longer true.

The "fresh eyes" test: Occasionally start a new session without providing any context beyond CLAUDE.md, and see what Claude produces. This reveals how much of its calibration comes from persistent context versus what you supply in individual prompts.

The update trigger: When you find yourself repeatedly correcting Claude on the same point in multiple sessions, that correction belongs in CLAUDE.md, not in each prompt.

The trim trigger: When CLAUDE.md grows beyond two pages, read it for what is actually used versus what is aspirationally there. Trim the latter.

The CLAUDE.md scope question specifically

CLAUDE.md is the main vehicle for persistent context. Getting its scope right is one of the highest-leverage things you can do.

What belongs in CLAUDE.md:

What does not belong in CLAUDE.md:

The manager's briefing test: What would you tell a capable research assistant on their first day — before they started work on any specific task? CLAUDE.md is that briefing. Not the task instructions, not the project theory, not everything you know — the standing orientation.

Quick diagnostic

If Claude's outputs are consistently too generic — ask: does Claude know enough about my project, conventions, and audience? Check CLAUDE.md; check what you include in prompts.

If Claude's outputs consistently confirm your expectations when you needed a critical view — ask: did I include my hypothesis alongside the material to be analysed? Try again without it.

If Claude's outputs are correct but irrelevant to the specific task — ask: did I give so much context that Claude wrote for the whole project rather than this question? Narrow the context.

If Claude keeps suggesting things you have already ruled out — ask: did I tell Claude what is off the table? Add it to the prompt or to CLAUDE.md if it is always off the table.

If you are spending significant time re-establishing context at the start of each session — you have a CLAUDE.md problem: either it doesn't exist or it doesn't contain what it should.

Related