Working Effectively with Claude Code — Part 1: Context, Skills & Prompting

If you've used Claude Code for more than a few minutes, you've probably felt the difference between a session that flows and one that fights you. More often than not, that difference isn't about the model getting smarter — it's about how well you work with the one thing that governs everything Claude Code does: its context window.

This is the first of a two-part guide. Part 1 is about working effectively inside a single session: understanding what Claude Code can and can't see, using skills, prompting well, and keeping long sessions sharp. Part 2 goes a level up — agents, subagents, and how to set up a multi-agent environment.

How Claude Code sees your project

The most important thing to internalize is that Claude Code has a finite context window, and everything competes for space in it: your messages, the files it reads, the output of every command it runs, and its own reasoning. It isn't a database with your whole repo loaded in — it reads files on demand, pulling in only what it needs as the conversation unfolds. Every file it opens costs tokens, and you can check how full the window is at any moment with the /context command.

The interactive widget below makes this concrete. Read a large file or go a few rounds of back-and-forth and watch the window fill; then try /compact or /clear and see what happens:

When the window gets close to full, Claude Code triggers auto-compaction: it summarizes the conversation so far to make room, keeping the key code and decisions. That's useful, but it isn't free — summarizing can drop details, so anything you truly need to persist should live somewhere more durable than the chat history.

What loads at session start

Not everything is read on demand. A handful of things load automatically the moment a session starts, while everything else waits until it's needed:

Knowing which side of that line something falls on is the key to keeping your context lean. The auto-loaded column is essentially "always there," so it's exactly where your standing instructions belong.

CLAUDE.md — your project's standing instructions

CLAUDE.md is where you tell Claude Code the things it should always know about your project. It comes in a few flavors, loaded in order:

• ~/.claude/CLAUDE.md — your personal file, applied across every project.
• ./CLAUDE.md or .claude/CLAUDE.md — the project file, checked into git and shared with your team.
• CLAUDE.local.md — personal overrides for a single project, kept out of version control.
• An org-wide managed policy file, for teams that need it.

It's auto-loaded at the start of every session and re-injected after compaction, so it survives even when the conversation gets summarized away. A good CLAUDE.md is short and specific:

# CLAUDE.md
- Package manager: pnpm (never npm).
- Run `pnpm test` after any change under `src/`.
- Never edit files in `migrations/` without asking.

One caveat is worth understanding: CLAUDE.md is context, not enforced configuration. Claude reads it and generally follows it, but it can still deviate — it's guidance, not a hard rule. When you need a genuine guarantee ("never write to this folder," "always run the linter before committing"), reach for Hooks, which fire deterministically at specific points in the lifecycle. And keep the file tight: past roughly 200 lines, adherence drops off as it competes with everything else for attention.

Auto Memory vs CLAUDE.md

There's a second file that's easy to confuse with CLAUDE.md: Auto Memory. The distinction is simple — CLAUDE.md is what you write; Auto Memory (MEMORY.md) is what Claude learns and saves on its own as you work. The first ~200 lines of it load automatically each session, so useful facts it picked up last time carry over to the next. You write one; Claude maintains the other.

Skills — packaged, on-demand capabilities

Skills are reusable workflows and domain knowledge, packaged as a SKILL.md file (plus any supporting files) under .claude/skills/<name>/. Custom commands and skills are now the same mechanism, so anything you'd previously reach for as a slash command fits here too.

You invoke a skill directly with /name, or Claude runs one on its own when it's clearly relevant. The clever part is how they use context: only the skill descriptions load at session start — short summaries so Claude knows what's available — while the full content loads only when a skill is actually used. That means you can keep a rich library of skills without paying for all of it upfront. Reach for one whenever you have a multi-step procedure you repeat: a deploy runbook, a review checklist, a project-specific workflow.

Prompting well

Everything above shapes what Claude can see; prompting shapes what it does with it. A few habits pay off consistently.

Be specific from the start. Reference files directly with @path/to/file, spell out constraints and edge cases, and point to an existing pattern in the codebase instead of describing it. The more precise your first message, the fewer corrections you'll need.

Give Claude something to check. A task with a built-in success criterion is far more likely to land on the first try:

• ❌ implement validateEmail
• ✅ implement validateEmail. Tests: user@example.com → true, invalid → false, user@.com → false. Run the tests after.

Explore before you implement. For anything non-trivial, start in Plan mode (Shift+Tab to cycle modes, or /plan). Claude reads, explores, and writes a plan without touching your source — you review it, then let it build.

Delegate, don't dictate. Treat Claude like a capable colleague: give direction and let it work out which files to read and commands to run. Micro-managing every step usually just burns context.

Course-correct early. Hit Esc to interrupt mid-action without losing the thread. And if you've corrected the same thing two or three times with no progress, stop — /clear and rewrite the prompt from scratch. A fresh, sharper prompt beats a long argument.

Keeping long sessions sharp

Put the pieces together and a simple routine falls out:

• Use /clear between unrelated tasks so old, failed approaches don't linger in context.
• Use /compact focus on <topic> when a single long task has filled the window but you want to keep going.
• Keep durable rules in CLAUDE.md so they survive compaction.
• Hand heavy investigation to subagents — they run in their own context window and return just a summary, keeping your main session clean. (That's the bridge to Part 2.)

Myths to avoid

• "Compaction keeps your full history." It summarizes — detail can drop. Durable rules belong in CLAUDE.md.
• "CLAUDE.md is enforced config." It's context. Use Hooks when you need a guarantee.
• "Plan mode never asks for permission." It only prevents edits; shell commands still prompt.

Coming up in Part 2

That's the core of working with Claude Code inside a single session — see the window, keep it lean, and prompt with intent. In Part 2, we go one level up: what agents and subagents actually are, when to delegate to them, and how to set up a multi-agent environment where several Claudes work in parallel. See you there.