The four commands: /init, /memory, /import, and trimming with /doctor

You have cloned a repo, or you are three months into one, and there is no CLAUDE.md — or there is one and nobody can remember what half of it is for. Lessons 6.1 through 6.4 covered what these files are, what belongs in them, and who writes them. This one is the small set of commands that create, inspect, adopt and shrink them — and the fact that only one of them ever proposes making the always-loaded instructions smaller.

First session in a repo

The documented opening move is two commands in order:

First session in a repo. Run /init to generate a starter CLAUDE.md, then /memory to refine it. — Commands

Here is the whole toolkit:

Four of those write and one only reads, and that split is newer than it looks: /import arrived in v2.1.213, and before v2.1.205 /doctor reported without changing anything. The one that only reads, /context, is the command that matters most here, and Lesson 3.2 already put it in your hands.

/init writes a draft, not a file you keep

Run /init to generate a starting CLAUDE.md automatically. Claude analyzes your codebase and creates a file with build commands, test instructions, and project conventions it discovers. If a CLAUDE.md already exists, /init suggests improvements rather than overwriting it. — Memory

Two facts in that paragraph earn their keep. First, /init is safe to run in a repo that already has a file: it proposes rather than clobbers. Second, and more useful, it tells you exactly where the generated content came from — Claude analyzed your codebase. The docs are direct about where your own effort goes next:

Refine from there with instructions Claude wouldn't discover on its own. — Memory

Two variations worth knowing:

• Setting CLAUDE_CODE_NEW_INIT=1 makes /init interactive. It asks which artifacts to set up — CLAUDE.md files, skills and hooks — explores your codebase with a subagent, fills gaps with follow-up questions, and presents a reviewable proposal before writing any files.
• It reads your other agents' rules. /init reads Cursor rules, in .cursor/rules/ or .cursorrules, and Copilot rules, in .github/copilot-instructions.md, and folds the relevant parts into the generated CLAUDE.md. With CLAUDE_CODE_NEW_INIT=1 set it also reads AGENTS.md, .devin/rules/, .windsurf/rules/ or .windsurfrules, and .clinerules.

/memory lists, /context proves

These two get confused, and the distinction is the whole reason both exist.

The /memory command lists your CLAUDE.md, CLAUDE.local.md, and other memory file locations across user and project scopes, including user and project CLAUDE.md entries for files that don't exist yet. — Memory

Selecting a file opens it in your editor; selecting one that does not exist yet creates it first. /memory is also where you toggle auto memory on or off and open the auto memory folder — the surface Lesson 6.4 sent you to.

But a location is not a load. The next sentence on the same page is the one to remember:

To check which files actually loaded into the current session, run /context. — Memory

Lesson 6.1 made the case that scope and launch directory decide which files load at all. /memory answers where your instructions could live; only /context answers what is in this session. It is how you stop reasoning about the load rules and simply look.

Bringing another agent's config in

If the repo is already configured for another coding agent, you have three ways to stop maintaining two files, and they are not equivalent. Two of the three are plain Markdown and work on any version; the third is a command, and a recent one.

The /import command is the broad one:

Bring configuration from other coding agents on your machine, currently OpenAI Codex and Google Gemini CLI, into Claude Code, including instruction files, MCP servers, commands, subagents, and skills. — Commands

It "appends a one-time copy of instruction files such as AGENTS.md to the matching CLAUDE.md". Read one-time twice: after the import, the two files are separate objects and keeping them in step is your job. That is the case for the @AGENTS.md import or the symlink instead — unless you also need the MCP servers, commands, subagents and skills, which neither of those carries.

Add --dry-run to preview without writing anything, or --yes to skip the interactive picker. /init knows about the command too: if it finds configuration from a coding agent that /import supports, it offers to carry it over with /import. You are asked, rather than left to find out the command exists.

/doctor and the trim check

Lesson 1.2 used claude doctor from the terminal to prove the install was healthy. The in-session /doctor is that same checkup with the ability to act on what it finds — and that is a recent shape for the command:

Before v2.1.205, /doctor opened a read-only diagnostics screen and pressing f sent the report to Claude. — Commands

The old screen did the diagnosis this level cares about — it "flagged oversized memory files and subagent definitions" (Errors) — but the acting was yours, or Claude's once you pressed f and handed it the report. The checkup still flags oversized memory files, alongside unused extensions; what changed is that it can now propose the edit rather than leave you the reading.

That proposing is a second job the command grew in v2.1.206, and it belongs to this level:

Deduplicates local CLAUDE.md files against checked-in ones, trims checked-in CLAUDE.md files by cutting content Claude could derive from the codebase, and migrates the always-loaded guidance that remains into skills and nested CLAUDE.md files that load on demand. — Commands

Three separate moves in one sentence — dedupe, trim, migrate — and the trim has a stated editorial policy. It "cuts content Claude can derive from the codebase, such as directory layouts, dependency lists, and architecture overviews, and keeps pitfalls, rationale, and conventions that differ from tool defaults."

Learn the policy and not merely the command, because it is a rule you can apply by hand — and not one to apply unread. A proposal to cut an architecture overview is usually right, and occasionally that overview is the only place a non-obvious decision was written down. Which is why a command that can act does so the careful way:

Reports findings first and asks for confirmation before changing anything. — Commands

Whether to make the cuts, and where each cut line should go instead, is Lesson 6.6.

When an instruction still is not landing

You wrote the rule, and Claude ignored it. The debug guide works through the causes in a fixed order, and it starts by ruling out the boring one.

1. Is the file there at all? Run /context.

Run it first to confirm whether your CLAUDE.md, rules, or skill descriptions are present at all. — Debug your configuration

If the file is missing from the Memory files breakdown, the guide sends you to check its location against how CLAUDE.md files load — the rules Lesson 6.1 covered. One documented exception looks like the same symptom and is not a fault at all: subdirectory CLAUDE.md files load on demand, when Claude reads a file in that directory with the Read tool, and not at session start. A nested file absent from a fresh session's breakdown is behaving as documented.

2. It loaded, and is still being ignored. The cause is then in how the instruction is written, and the docs name three: an instruction vague enough to interpret multiple ways, two files giving conflicting direction, or a file grown long enough that individual rules get less attention. The first two are Lesson 6.2; the third is Lesson 6.6, and it is the one people diagnose last.

3. Turn everything off.

Start with claude --safe-mode, which launches a session with all customizations disabled, including CLAUDE.md, skills, plugins, hooks, MCP servers, and custom commands and agents. — Debug your configuration

Authentication, model selection, built-in tools and permissions keep working, so if the problem disappears here, one of the disabled surfaces is the cause and you can bisect from there. Managed hooks and settings policy from your organization still apply, so safe mode is not proof that nothing is loaded.

4. Watch the loading itself. For the lazy cases — a nested CLAUDE.md, a rule with paths: frontmatter — there is a hook event for exactly this. Lesson 5.2 wired a Stop hook to gate a turn; this one gates nothing:

Use the InstructionsLoaded hook to log exactly which instruction files are loaded, when they load, and why. — Memory

Each invocation gets the file path, its scope as memory_type, and a load_reason of session_start, nested_traversal, path_glob_match, include or compact — the last firing when instruction files are re-loaded after a compaction event. The matcher runs against load_reason, so "matcher": "path_glob_match|nested_traversal" fires only on lazy loads.

Which way each command pulls

Two of these commands add to the always-loaded instructions: /init writes down what it discovered by reading the codebase, and /import appends a copy of another agent's instruction file to the matching CLAUDE.md. /doctor is the one that proposes taking content back out, and only in a session where you ran it.

The trim check needs v2.1.206 and /import v2.1.213, so both are in reach on a current build — and still nothing in the tooling keeps the two directions in balance: the file grows on its own and shrinks only when someone decides to shrink it. That part is a habit, and Lesson 6.6 is about acquiring it.

Checkpoint

1. You run /memory, see ~/.claude/CLAUDE.md listed, and conclude your personal rules are in this session. What have you actually confirmed, and which command confirms the rest?

   ›Show answerAnswer

   You have confirmed a location, not a load. /memory lists memory file locations across user and project scopes — including entries for files that do not exist yet — so a path appearing in that list does not even prove the file exists, let alone that it reached this session. Selecting the entry opens it in your editor, and creates it first if it is one of those not-yet-existing ones.

   /context confirms the rest: it shows what actually loaded into the current session, under the Memory files breakdown. It is also the first step of the debug guide's fixed order when an instruction is not landing, precisely so you rule out the boring cause before theorising about the interesting ones.

2. A teammate ran /init on Monday and committed the result. On Friday you run /doctor and it proposes deleting a large part of that file. Who was wrong, what should Monday have looked like, and which lines will the trim check leave behind?

   ›Show answerAnswer

   Neither command is wrong — they are pointed at the same target from opposite ends. /init writes down what it found by analysing the codebase; the trim check cuts content Claude can derive from the codebase. So /init output is by construction made of exactly the material /doctor looks for, and a big trim proposal is the expected result rather than a sign either tool misfired.

   The mistake was committing it unedited, which checks in a context bill paid in every session by every teammate for facts Claude can read for itself. Monday should have been the documented opening move — /init, then /memory to refine it — treating the generated file as an accurate first draft and adding the instructions Claude would not discover on its own. The trim keeps pitfalls, rationale, and conventions that differ from tool defaults, and proposes cutting directory layouts, dependency lists and architecture overviews. Read the proposal rather than accept it: /doctor reports findings and asks for confirmation first, and occasionally an architecture overview is the only place a non-obvious decision was ever written down.

3. Your repo already has an AGENTS.md that another team keeps updating. You want Claude Code to follow it without maintaining a second copy. Which of the three approaches fits, and which one would quietly go stale?

   ›Show answerAnswer

   Put @AGENTS.md at the top of CLAUDE.md. The import is live — expanded at session start — so the other team's edits arrive on their own, and you can append Claude-specific text below it. The symlink (ln -s AGENTS.md CLAUDE.md) is live too and works if you need nothing Claude-specific, though on Windows it requires Administrator privileges or Developer Mode, which makes the import the portable choice.

   /import is the one that goes stale. It appends a one-time copy of instruction files such as AGENTS.md to the matching CLAUDE.md, after which the two are separate objects and keeping them in step is your job — the second copy you set out to avoid. Reach for it (v2.1.213 or later) only when you also want the MCP servers, commands, subagents and skills, which neither live approach carries.

4. A rule in a subdirectory CLAUDE.md is being ignored. You want evidence, not a theory. Name two things you can run, and say what each would prove.

   ›Show answerAnswer

   Run /context first. It proves whether the file is present in this session at all, under the Memory files breakdown — and for a nested file you have to read the premise carefully: subdirectory files load on demand, when Claude reads a file in that directory with the Read tool, so absence from a fresh session's breakdown is documented behaviour rather than a fault. Have Claude read a file in that directory, then look again.

   Then add the InstructionsLoaded hook, which logs exactly which instruction files load, when, and why. Each invocation gets the file path, the scope as memory_type, and a load_reason of session_start, nested_traversal, path_glob_match, include or compact, so it proves whether your nested file loaded and on what trigger; matching on "nested_traversal" narrows it to the lazy loads. It answers did it load and why and nothing else — it has no decision control, cannot block or modify loading, and its JSON output fields are discarded. If both say the file did load, the cause is in how the instruction is written: vague, contradicted, or lost in a file grown too long.