How to Give Claude Code Context
Claude Code works out of the box, but it gets noticeably better once it knows your project — the stack, the conventio...
Claude Code works out of the box, but it gets noticeably better once it knows your project — the stack, the conventions, the commands, the reasons behind your architecture. The difference between a generic coding assistant and one that fits your codebase is almost entirely context.
Here's every way to give it that context, and where each one fits.
How do you give Claude Code context about your project?
CLAUDE.md is the primary method. It's a Markdown file Claude Code reads automatically at the start of every session, holding the project context you'd otherwise repeat in every prompt: tech stack, structure, conventions, build and test commands, architectural decisions.
You don't reference it or attach it. If it's in your project, Claude has already read it. Put it at the repo root, commit it to git, and the whole team shares the same baseline.
(For the full breakdown, see What Is CLAUDE.md?.)
How do you generate a CLAUDE.md automatically?
Run /init in your project. Claude Code scans the codebase — detecting frameworks, patterns, dependencies — and generates a draft CLAUDE.md.
Treat the output as a starting point, not a finished file. Trim the generic boilerplate, add your real standards, and link out to deeper docs where needed. The auto-generated version captures structure; you add intent.
What is Claude Code's auto memory?
Claude Code has a second memory system alongside CLAUDE.md: auto memory. Where CLAUDE.md is what you write deliberately, auto memory is what Claude learns from your corrections over time, without manual effort.
Claude writes its own notes (in ~/.claude/projects//memory/), and the entry point loads into each session. Subagents can maintain their own auto memory too. The two systems are complementary: CLAUDE.md for the instructions you set on purpose, auto memory for what Claude picks up as you work.
How much context should you give?
Less than you'd think. Target under 200 lines in CLAUDE.md. Longer files consume more context tokens and, counterintuitively, reduce how reliably Claude follows the instructions.
Use progressive disclosure: keep CLAUDE.md lean and point Claude to deeper docs only when needed, rather than inlining everything. Put universal rules at the root and module-specific rules in subdirectories, where they load only when relevant. Let auto memory pick up the rest organically instead of front-loading every detail.
What about context that isn't project-specific?
Here's the gap every method above shares: they all give Claude context about the project. None of them carry the context that isn't tied to one codebase.
Think about an agency building in Claude Code for a client. The useful context isn't just "this Next.js repo uses Prisma." It's who the client is, their brand and constraints, the team's standards, the decisions made across the whole engagement. That context spans repos — and it's needed in more tools than Claude Code. The same client context should be available when you switch to Cursor, or draft an update in another tool.
CLAUDE.md can't do that. It's per-project and Claude-Code-only. The layer that can is a structured context vault — personal, team, project, or client — that you connect once and deliver to any MCP-compatible tool. For the agency, that means client context loaded into every tool working on the engagement, not re-pasted into each repo's CLAUDE.md.
CLAUDE.md handles the codebase. A context layer handles the context that lives above any single project or tool.
→ How context reaches your tools: How to Deliver Personal Context to AI Tools
→ Set up your context vault with Unabyss →
