Context As Budget — Claude Code Guide

Context is a budget, not a warehouse for the entire repository

Context is a limited resource shared by conversation history, files, logs, project rules, and completion criteria. Passing the entire repository often adds noise, expands scope, and prompts unnecessary edits.

The optimal approach is the minimum sufficient context, with the option to expand it selectively when the investigation reveals a specific lack of data.

Signal	Role in the task
Goal	What should change
Affected area	Where to look for related implementation
Evidence	Why the problem is considered real
Constraints	What must not be changed
Style sample	What an accepted similar implementation looks like

Context selection order

State the goal and expected result.
Identify the affected area: module, files, classes, or tests.
Collect evidence: a log, stack trace, reproduction steps, failing test, or screenshot.
Record constraints and immutable APIs or dependencies.
Add one to three relevant files or one small module.
Add a similar implementation when the style needs to be followed.
Expand the context only after a concrete signal that data is missing.

Context depends on the task type

Task	Minimum useful set
Bugfix	Reproduction steps, stack trace, failing test, and related code
Documentation	Actual API, usage example, and current rules
Feature	Goal, affected flow, constraints, and acceptance criteria
Investigation	Symptoms, evidence, hypotheses, and questions to verify

How to ask for candidate files

Read-only request to expand context

Find files, classes, and tests related to the symptom.
Do not edit code.
Name each candidate file and explain which fact
needs to be verified before making changes.
Do not add the entire repository without a specific reason.

What not to provide

the entire repository without a need;
hours of logs instead of a short relevant fragment;
unverified old assumptions;
unrelated tasks and outdated documentation;
.env, keys, tokens, and other sensitive data.