Quick wins and what's possible

Before we go deeper into how Claude Code works under the hood, here are eight things you can do today that most users discover weeks or months in. Each one costs nothing, requires no configuration, and will immediately improve your results.

The quick wins

Let me break each one down.

1. Use Opus at max effort for everything

Claude Code gives you access to multiple models. Opus is the most capable. Effort levels control how deeply Claude reasons before responding — four levels: low, medium, high, and max. Higher effort means fewer mistakes, fewer correction loops, less wasted context.

Most people save Opus for "hard tasks" and use Sonnet for routine work. Do not do this. The reasoning quality difference shows up on every task, not just the complex ones.

Make it the default so you never have to think about it. One block in your settings file:

{
  "model": "claude-opus-4-6[1m]",
  "env": {
    "CLAUDE_CODE_EFFORT_LEVEL": "max"
  }
}

Two things happening here. First, the model is set to claude-opus-4-6[1m]. The [1m] suffix opts you into the 1 million token context window instead of the default 200K. That is five times more working memory for Claude — you want this. Second, the env block sets the effort level to max. The effortLevel setting in Claude Code only supports low, medium, and high. But max — the deepest reasoning with no constraint on token spending — is only available on Opus and needs to be set via environment variable. The env block in settings.json handles this cleanly without touching your shell profile.

You can also use /effort during a session to adjust on the fly: /effort low when you want speed, /effort max when you want depth.

2. Use Plan Mode for anything non-trivial

Plan Mode (Shift+Tab twice) tells Claude to explore your codebase and create a plan before making any changes. It can read files but not edit them. You review the plan, refine it, then let Claude execute.

Anthropic's own best practices put it bluntly: "Letting Claude jump straight to coding can produce code that solves the wrong problem."

Skip Plan Mode for trivial tasks — a typo fix, a variable rename, adding a log line. Use it for everything else. A two-minute plan saves twenty minutes of fixing the wrong approach.

3. Run /init for your CLAUDE.md

CLAUDE.md is a file Claude reads at the start of every session. It contains your project's build commands, code style rules, testing instructions, and architectural decisions. It is the single most important configuration file in Claude Code.

You do not have to write it from scratch. Run /init and Claude analyzes your project — build system, test framework, code patterns — and generates a CLAUDE.md for you. It is 80% right on the first pass. Tweak the remaining 20% based on what you know about your project.

4. Reference files with @

Instead of writing "look at the login file in the auth folder," type @src/auth/login.ts. Claude reads the file before responding. No ambiguity, no searching, no wasted tool calls.

This is cheaper (fewer tokens spent searching), more reliable (Claude reads the right file), and faster (one tool call instead of three).

5. Give Claude verification criteria

This is the single highest-leverage habit you can build.

When you end a prompt with "run the tests after" or "check that the build passes," Claude verifies its own work. When a test fails, it reads the error, fixes the issue, and runs the tests again. Without criteria, Claude may skip verification entirely and move on.

6. Use /compact, /cost, and /context

/cost shows where your tokens are going: input tokens consumed, output tokens generated, breakdown by tool category. Run it periodically to stay aware of your budget.

/context visualizes your context usage as a colored grid and shows optimization suggestions — flagging context-heavy tools, memory bloat, and capacity warnings. Think of it as a dashboard for your session health.

/compact summarizes older conversation history, freeing space for new work. Use it between unrelated tasks. The key: you can give it focus instructions. /compact Focus on the API changes tells Claude what to preserve and what to summarize aggressively. Without instructions, Claude guesses what matters. With instructions, you direct the compression.

/compact Focus on the auth implementation and test results
/compact Preserve the file list and migration steps, summarize everything else
/compact Keep the architecture decisions, drop the debugging context

Think of /cost as checking your battery percentage, /context as the battery health dashboard, and /compact as a strategic save that preserves what you choose.

7. Interrupt and rewind

Esc stops Claude mid-action. Context is preserved — you can redirect without losing anything.

Esc+Esc opens the rewind menu. You can restore conversation, code, or both to any previous state. Every action Claude takes creates a checkpoint. If something goes wrong, you go back.

Anthropic's best practices add one more rule: "If you've corrected Claude more than twice on the same issue, /clear and start fresh with a more specific prompt. A clean session with a better prompt almost always outperforms a long session with accumulated corrections."

8. Use /clear between unrelated tasks

Long sessions with irrelevant context reduce performance. When you finish debugging a bug and want to start a new feature, run /clear. The new task starts with a clean context window instead of wading through a conversation about the old bug.

This feels wasteful — you are throwing away everything Claude learned. But a focused 10-minute session beats a cluttered 40-minute session every time.

What becomes possible

Those eight quick wins get you from default to solid. But Claude Code is not just a coding tool. It is an extensible system. Let me show you what becomes possible when you configure it.

The plugin landscape

There are community-built systems that extend Claude Code with specialized workflows. Each takes a different approach:

Each takes a different approach. None covers everything. The right move is to pick one, experiment with it, see what fits your workflow — and then build your own. Because if you understand how your system works, you know how to use it properly. Someone else's 57 commands will include 40 you never use.

Beyond code

This is where it gets interesting. A configured Claude Code goes well beyond writing code.

Marketing. I type /copywriting and Claude rewrites my landing page copy using marketing psychology principles — scarcity, social proof, loss aversion. I type /seo-audit and it crawls my site, checks meta tags, analyzes heading structure, and finds fifteen issues I would have missed manually.

Research. I point Claude at documentation and it produces structured research briefings I can reference later. Not summaries — structured analysis with key insights, comparisons, and recommendations I can act on.

Design-to-code. I paste a Figma URL and Claude implements the design using my project's existing components — matching spacing, typography, and color tokens. Not generic HTML. Production-ready code that follows my design system.

Deployment. Claude runs my pre-deployment checklist: database migrations applied, environment variables set, DNS configured, smoke tests passing. It tells me what is missing before I ship.

These are not hypothetical. They are commands I run on my own projects. The gap between "Claude writes code for me" and "Claude handles half my work" is what this course closes.

The gap

Quick wins get you from default to 3x. A configured system gets you to 10x. The difference is not installing more plugins or memorizing more commands. It is methodology: understanding how Claude Code actually uses resources, building around that reality, and creating a system that improves every time you use it.

That methodology is what Chapters 2 through 7 teach. And it starts with understanding the constraint.