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 separateCLAUDE.mdinto 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's loaded automatically at the start of each new session (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 files that get 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 useconst/leteverywhere" 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 Prisma, not raw SQL." Claude will ask whether to save it to project memory or global (
~/.claude/). - Every couple of weeks, open
/memoryand clean out anything stale (architecture changed — old notes now lie). Move team-wide findings intoCLAUDE.mdso 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.
- 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
/compactto 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.mdor 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
/effortto 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./effortcontrols reasoning depth (low | medium | high | xhigh | max): uselowfor mechanical tasks andhigh/maxfor 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.
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
/cavemanor "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.
This article was originally published by DEV Community and written by Mikhail Konkov.
Read original article on DEV Community

![Screenshot: /effort [low|medium|high|xhigh|max|auto] command in the Claude Code prompt](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fbvemkf3x4gy9bowdsp06.png)

