How to actually get the most out of Claude Code
Better results. Fewer things to keep up with.
Claude Code moves quickly. There are LOTS of features — and you can safely ignore most of them until you need them. Here's what I'd focus on.
I cover all these concepts in my course, Claude Code — The Practical Guide. Here's the short version.
1. Write precise prompts and let Claude check its own work
Describe the outcome and constraints precisely. Give it clear validation tasks, too:
Add search by article title. Reuse our form styles. No external service. Then test it in the browser: typing, clearing the field, and a search with no results, also at phone width.
Let it implement, check, fix, and repeat. Tell it how to check: run the tests, deploy and look
at the result, or open it in a browser. Put mandatory tasks and checks in CLAUDE.md. For bigger changes, ask for a plan first. Inspect the result yourself!
2. Give it the right context
Don't let Claude guess or struggle with something you already know. Share what matters: relevant files, existing patterns, the exact URL to visit, or a pitfall to avoid. Don't assume it knows your project.
3. Give it proper agent skills
This is worth spending time on. Use skills as an on-demand knowledge base and to
encode capabilities: how to research, implement, test, or review. Each skill is a folder with
a SKILL.md file and any supporting files.
Start with a few that match your work. A few good skills beat a big collection. Read their instructions and try them on real tasks. If Claude consistently gets something wrong, add or improve a skill that explains that task better, including how to check the result.
Claude can load relevant skills automatically; use /skill-name to request one. My guide to agent skills shows how they work and how to write good ones.
4. Connect useful tools
MCP servers connect Claude to other services: reading and writing emails, working with Linear, or accessing design files. Add one when it saves work. Check what it can read or change.
If a service has a well-known command-line tool, like GitHub's gh, I'd often let
Claude use it directly. It likely already knows the commands well; an MCP connection isn't
automatically better.
5. Use Opus and raise the effort when it matters
I use Opus for everything now: planning, hard decisions and implementation. It's the default on most plans, so you probably don't need to switch at all.
What I do change is the effort level. Opus starts at medium. For planning, tricky
bugs or big decisions, raise it with /effort high or /effort xhigh.
For one hard question, add ultrathink to your prompt. The model docs cover costs and the other options.
My Opus 5.5 guide shows which effort level pays off, and the other habits that get the most out of the model.