Claude Code CLI: Best Practices

A handful of observations from working with Claude Code day to day — about memory, context, modes, and a couple of useful skills. Nothing groundbreaking, just the things I wish someone had told me earlier.

Setup once

These are the things you do at the start of a project (or once per machine) and forget about — but they pay back on every single session.

• CLAUDE.md. Put commands for running tests and linters here, along with an architecture overview, what NOT to touch, and code style conventions. The agent reads this file automatically, so you don't have to repeat the same things in every prompt.

  If your project has multiple areas, you can drop a separate CLAUDE.md into each one: the agent will pick up both the root file and the one closest to the files it's working on.

• Cultivate auto memory deliberately. Auto memory is Claude Code's built-in notebook where the agent stores notes between sessions on its own: build commands, debugging insights, your style preferences. It lives in ~/.claude/projects/<project>/memory/ as an index file (MEMORY.md) plus topic files. The index loads at the start of each session (first 200 lines or 25 KB); deeper notes are pulled in on demand when relevant. Requires Claude Code v2.1.59+, on by default; view and prune via /memory. Important caveat: this is not model fine-tuning — it's just markdown that gets pulled into context. So the agent gets "better" only as far as its notebook is good, and the notebook needs to be managed.

What works:

• Correct with words, not silent edits. "Don't use var, we use const/let everywhere" is a signal worth remembering. A silent fix in the IDE isn't.
• At the end of a hard task, ask explicitly: "remember how we fixed this" or "save to memory: this repo uses Arel, not raw SQL." Claude will ask whether to save it to project memory or global (~/.claude/).
• Every couple of weeks, open /memory and clean out anything stale (architecture changed — old notes now lie). Move team-wide findings into CLAUDE.md so they reach the whole team, not just you.

A useful end-of-session prompt:

Sum up what we did, where we got stuck, and what worked. From that, pick 1–3 notes worth saving for future sessions and suggest where each should go — project or global memory. Don't save them yet; I'll confirm.

  Sum up what we did, where we got stuck, and what worked. From that, pick 1–3 notes worth saving for future sessions and suggest where each should go — project or global memory. Don't save them yet; I'll confirm.

Working on a task

Habits for the actual work — how to brief the agent, how to keep yourself out of trouble.

• Use git as a safety net. Commit often and start agent sessions with a clean working tree — it's much easier to see exactly what the agent changed and to roll back if needed.

• Use plan mode for complex tasks. Ask for a plan first — either explicitly ("draft a plan, don't write code yet") or by switching into plan mode (Shift+Tab cycles through modes: normal → auto-accept → plan). Read it, adjust it, and only then let the agent execute. This dramatically reduces the chance of the agent spending half an hour doing the wrong thing.

• Don't default to auto-accept mode. Auto-accept — where the agent confirms all its own actions (file edits, shell commands) — is fine for short, contained tasks: rename a variable, run the linter, fix a flaky test. For anything else it's a way to rack up a dozen unreviewed changes in five minutes. Keep the default mode (manual confirmation) and turn on auto-accept consciously, for a specific stretch of work, ideally on top of a clean git state so rolling back is cheap.

• Break tasks down. Instead of "implement the whole feature," go step by step: schema first, then migration, then the endpoint, then tests. It's cheaper in tokens, easier to review intermediate results, and easier to roll back if the agent went off course.

Managing context

Context is the resource you're actually paying for — both in money and in answer quality. These three pull in the same direction.

• Watch your context size. The larger it gets, the more expensive each step becomes (the entire context is re-sent every turn) and the worse the agent holds focus. For a separate task, start a new session — or use /compact to compress the history.

• The downside of a new session is that the agent loses context and burns tokens getting back up to speed. So move the essentials (project architecture, conventions, frequently used commands) into CLAUDE.md or package them as a skill — that way they load automatically and don't eat into your context window on every start.

• Don't let the agent fix what it just broke in the same session. If it's stuck in a hole, it's better to roll back, reformulate the task, and start fresh than to pile more on top. Otherwise mistakes compound and chew through context.

Tuning and extras

The fine-tuning knobs and a couple of optional add-ons.

• Pick the model and /effort to match the task. Sonnet is cheaper and faster — usually enough for routine work (edits, refactoring, tests). Opus is for complex design, gnarly bugs, and architectural decisions. /effort controls reasoning depth (low | medium | high | xhigh | max): use low for mechanical tasks and high/max for architecture and heavy debugging.

• Attach screenshots and logs directly. For UI bugs, a screenshot saves a ton of back-and-forth; for errors, paste the full stack trace, not a paraphrase. The agent works noticeably better with raw input. (Use Ctrl+V to paste a screenshot in Claude Code CLI.)

• Install Caveman — a skill that makes Claude respond in a telegraphic style, without filler phrases or hedging. It cuts up to 75% of output tokens while keeping technical accuracy intact; code, error messages, and commit messages stay normal. Toggle on with /caveman or "caveman mode," off with "normal mode."

---

That's the set. None of it is rocket science — most of the wins come from setting up CLAUDE.md properly, leaning on plan mode, and keeping the context window honest. If you've got your own practices, drop them in the comments — I'm always looking to steal good ones.