Claude Code: Intermediate

Intermediate

You can run Claude Code and make a change. Now you want a workflow you can repeat on real work: a change that spans several files, on a codebase you care about. The shift from beginner to intermediate is mostly about one thing: managing what Claude knows. Everything it can see lives in the context window, and how you fill that window decides the quality of the result. This is context engineering in practice.

Give it a CLAUDE.md

CLAUDE.md is a file in your project root that Claude reads at the start of every session. It is where durable rules live: the things you would otherwise repeat in every chat.

Generate a starter with /init, then trim it by hand. Put in what Claude cannot guess:

• the test command and how to run the build
• code style that differs from the language defaults
• repo etiquette (branch and PR conventions)
• architecture decisions and known gotchas

Leave out anything Claude can infer from the code, standard language conventions, and detailed API docs (link to them instead).

Tip

Keep it under 200 lines. For each line, ask: “would removing this make Claude make a mistake?” If not, cut it. A bloated CLAUDE.md buries the real rules in noise, and Claude starts ignoring them.

CLAUDE.md survives compaction: when the window fills, Claude Code summarizes old chat, but it re-reads CLAUDE.md from disk. That is why a rule in the file beats the same rule typed into the chat: the chat gets summarized away, the file does not. (Saying “remember that…” instead saves to auto memory, which Claude writes from your corrections; browse both with /memory.)

Load the right files with @

The cheapest context is the context you hand over precisely. Type @ and a path, and Claude reads that file before it answers:

Read @src/taskboard.js and explain how due dates are stored and compared.

Pointing at the two files that matter beats letting Claude read twenty to find them. You can also paste screenshots, give a URL for docs, or pipe data in (cat error.log | claude).

Plan before you code

For anything beyond a one-line fix, separate thinking from doing. Plan mode lets Claude read files and propose an approach without touching your source.

1. Press Shift+Tab to cycle to plan mode. The prompt shows you’re in it.

2. Ask for a plan, not a change:

   I want to add a tasksByPriority function. What files change? Make a plan, don't write code yet.

3. Read the plan. Press Ctrl+G to open it in your editor and refine it.

4. Press Shift+Tab to exit plan mode and let Claude implement the agreed plan, write tests, and run them.

Reviewing a plan you can read is far cheaper than reviewing a diff you have to unpick. If the plan is wrong, you caught it for free.

Note

Skip the plan when you could describe the diff in one sentence (a typo, a log line, a rename). Plan when the approach is uncertain, the change spans multiple files, or the code is unfamiliar.

Iterate against a check, not a vibe

Claude stops when work “looks done”. On a bigger change, “looks done” is not enough. Give it something it can run and read (a test, a build, a linter) and ask it to keep going until that passes:

Add the function following the pattern of tasksDueBefore. Run `node --test` after each change and show me the passing output.

Specific instructions mean fewer corrections, and every correction you avoid is context you did not burn.

Keep the window clean

Performance degrades as the context window fills: Claude forgets earlier instructions and makes more mistakes. A few habits keep it healthy. This is the context window in daily use.

Move	When to use it
/clear	Between unrelated tasks: a clean session beats a long, polluted one
/context	See what is using space right now
/compact <focus>	Near the limit, e.g. /compact focus on the API changes
Esc Esc or /rewind	Restore conversation, code, or both from a checkpoint

The discipline that matters most: after two failed corrections, the window is full of dead ends Claude keeps tripping over. /clear and rewrite the prompt with what you just learned. The third correction is rarely the charm.

The whole loop, once

Here is the workflow end to end, on a change small enough to follow: adding tasksByPriority to the task board and showing it in the summary view. Two source files, one test file.

1. The rules are already paid for. Your CLAUDE.md says tests run with node --test and that new functions follow the existing pure-function style. You wrote that once; this session starts already knowing it.

2. Scope in plan mode. Enter plan mode and hand over the exact files:

   Read @src/taskboard.js and @src/render.js. I want tasks grouped by
   priority in the summary view. Plan the change, don't write code.

3. Correct the plan, not the diff. The plan proposes putting the sorting logic in render.js. You know data logic lives in taskboard.js; say so. One sentence now saves an unpicked diff later.

4. Exit plan mode with the check attached.

   Implement the agreed plan. Run `node --test` after each file you
   touch and paste the passing output.

5. Review evidence, not vibes. Claude edits taskboard.js, then render.js, adds a test, and one run fails before it fixes the sort order. The final message shows the passing output, and the diff has the shape you already approved in step 2.

Three prompts, no re-typed rules, no surprise diff. That is the whole intermediate skill set in one pass: durable rules in the file, thinking separated from doing, and a check instead of a vibe.

You’re done when…

• ✅ Your project has a lean CLAUDE.md (and you confirmed it loads with /memory)
• ✅ You used plan mode to scope a multi-file change before any code was written
• ✅ You loaded specific files with @ instead of letting Claude hunt for them
• ✅ You /clear between unrelated tasks out of habit

Next step

Ready to shape the harness itself: hooks, skills, subagents, MCP, and verification gates that run without you watching?

Claude Code: Advanced Permission modes, hooks, skills, subagents, MCP, and verification gates. Configure the harness around your project.