Claude Code Essentials

After months of daily Claude Code use, at work and on side projects, the thing that moved the needle was not using it more. It was the setup around it.

Four practices made the difference for me:

1. Be specific: give it rich, precise input
2. CLAUDE.md: teach it your codebase once
3. Plan Mode: let it think before it writes
4. Context management: keep conversations short and on topic

1. Be Specific (Use Rich Input)

The less specific you are, the more room the model has to make assumptions, and they rarely match what you had in mind.

Example

Name the technology, the versions, and the outcome you expect. Say what it should look like and how it should behave.

Richer input than text

Depending on the task, add:

• Screenshots: drag and drop, or paste with Cmd+V (Ctrl+V on Windows and Linux). Designs, error states, UI you want fixed
• File references: @filename puts the file in context, with tab completion
• Data: pipe it in: cat error.log | claude
• URLs: the docs for the library or API you want used

Since I started working this way, I went from three or four iterations per feature to usually getting it right the first time.

Specific prompts are necessary, but explaining your stack every session gets old. That's what CLAUDE.md is for.

2. Master CLAUDE.md Files

Before I used CLAUDE.md, I was explaining our codebase setup and structure every single session.

How it works

CLAUDE.md files are loaded hierarchically:

1. Enterprise policy: /Library/Application Support/ClaudeCode/CLAUDE.md (macOS), or C:\ProgramData\ClaudeCode\CLAUDE.md (Windows) - organization-wide instructions
2. Project memory: /CLAUDE.md or /.claude/CLAUDE.md - team-shared instructions for the project
3. User memory: ~/.claude/CLAUDE.md - personal preferences for all projects

Subdirectories can carry their own (frontend/CLAUDE.md, backend/CLAUDE.md), and any of them can pull in other files with @path/to/file. A new session loads whichever apply to the directory you started in.

What to include - An example

Best practices

1. Keep it under 100 lines - Claude loads this every session, and bloat kills signal
2. Test and refine - Like production prompts, test effectiveness and remove fluff
3. Edit it from inside a session - /memory opens the loaded memory files, so a lesson goes in the moment you learn it
4. Version control project files - Check them into git for team collaboration
5. Create multiple CLAUDE.md files - Root + subdirectory (frontend/CLAUDE.md, backend/CLAUDE.md) for focused guidance
6. Initialize with /init - Claude can generate a starter CLAUDE.md for your project

3. Use Plan Mode

On simple changes like "add a loading spinner while the user data is pending", I'll start straight in ⏵⏵ accept edits on mode.

For anything touching multiple files or with side effects, I start in ⏸ plan mode on.

In plan mode, Claude reads and thinks before it writes. It weighs approaches, flags problems, and commits to one strategy before touching a file.

How to enter Plan Mode

• Press Shift+Tab until the status line reads plan mode
• Or say "plan this first" in the request

Give it room to think

Extended thinking is a toggle, Option+T on macOS and Alt+T elsewhere, and /effort sets how hard the model works on each turn. I keep thinking on in plan mode and raise the effort for:

• Unclear requirements that need exploring first
• Multi-file refactors and architectural changes
• Anything security-sensitive

Then ask a question that deserves the extra thought:

Store Plans as Files

For bigger features, have Claude write the plan to a file:

Now you have something to review before any code exists. Adjust the approach, add constraints, cut scope, all without spending tokens on implementation. Once agreed, the file stays the reference for the whole feature, across as many /clears as it takes.

4. Break It Down & Manage Context

The context window is 200k tokens by default, with 1M opt-in on the newest models. That sounds like plenty until you're deep in a debugging session and the answers get vaguer about your setup with every turn.

The problem with context pollution

• Auto-compact spends tokens summarising the conversation, and loses detail doing it
• Error logs, permission prompts and repeated output pile up
• Large MCP results, a whole page fetch or a big query, land in context and stay there
• Long conversations drift toward generic answers

Best practices for context management

1. Use /clear frequently

I clear after every finished subtask. Once the code is committed and the tests pass, that context has done its job.

2. Break large tasks into phases

3. Be surgical with file references

• Instead of: "Look at everything in the /components folder"
• Try: "Review @components/AuthForm.tsx and @hooks/useAuth.ts"

4. Let Claude write the breakdown

5. Turn the breakdown into tickets

Then take each one in its own conversation.

The guiding principle

Keep the context window full of things that matter to the task in front of you, and nothing else.

Resources

• Official Claude Code Documentation
• Claude Code Best Practices - Anthropic Engineering