Best Practices for Productive Claude Usage
Explore habits that shrink context, govern memory, refine commands, scope sessions, measure usage, and refactor.
We'll cover the following...
- The ethos: Think less, iterate faster
- Memory hygiene without the overhead of a second brain
- Commands that express your process
- Sessions sized to the phase you are in
- MCP without the “always-on” tax
- Quantify your intuition with ccusage
- Review, then refactor the loop
- CI without repetition
- A short, opinionated checklist
You’ve already set up the core components: installation, project context, planning, conversation control, commands, sub-agents, hooks, SDK usage, MCP, and GitHub. This lesson focuses on habits that improve daily use. It avoids repeating mechanics you’ve already learned. The goal is to keep things compact, practical, and easy to apply.
The ethos: Think less, iterate faster
Claude Code performs best in a quiet, well-structured environment. The aim is not more features; it is fewer frictions. Treat your setup as a small set of guardrails that preserve signal: a living memory that stays accurate, commands that represent your process, sessions sized to your current phase of work, and feedback loops that show cost before it surprises you. We’ll focus on operational patterns: when to use a tool and why it matters. We won’t cover setup or launch steps; that’s already behind you.
Memory hygiene without the overhead of a second brain
You already know what CLAUDE.md is and how to scaffold it. The advanced move is governance, not growth. Keep CLAUDE.md short enough to review quickly. If you cannot skim it between meetings, it is too long. Use a two-tier structure.
Contract: Ten to 20 lines at the top with non-negotiables: build and test commands, error-handling norms, and architectural invariants.
Pointers:
@includes to narrowly scoped docs for details such as architecture, testing strategy, and the domain glossary. These should read like headers, not essays.
When adding a convention, first ask whether it’s global and long-lasting. If it is, include it in the contract. If it’s a local detail, such as “Component X uses library Y for parsing,” document it at the module level. Link to it from CLAUDE.md only if the assistant needs to reference it frequently. Every line should earn its place. If it does not reduce future tokens or errors, remove it.
Schedule small maintenance. Once a week, run a quick sweep: remove one stale instruction, rewrite one ambiguous sentence, and add one clear example. Ten minutes now is better than a large cleanup later. In ongoing conversations, use /compact with a clear instruction, for ...