working with claude cli

claude is a different kind of coding assistance - not code completion, but a colleague. you don't get the next line suggested, you hand over a task, talk it through, and review what comes back - the way you'd work with another developer on the team

when unsure how to use claude - ask claude! it knows its own features, settings and quirks better than any docs page you'd have to find first

getting started

install claude - the one-liner from the Claude Code docs, or npm install -g @anthropic-ai/claude-code - and log in with your Claude account on the first run. then just run claude from the root of your repo, so he sees the whole project

think of it as handing over a task to a colleague - describe what needs to be done and why, and give the context that isn't in the code: the ticket, the decisions behind it, what's already been tried. you don't need to tell him where things are or how to do it, he'll find out

shift+tab switches between modes, and i typically use only two. auto, where claude does everything on his own (except for potentially dangerous actions, where he still asks), and plan, where you talk the task through in stages - literally bouncing ideas off each other - until you're happy with the plan, then switch to auto for the implementation. (ok, i'm lying - you can just ask claude to start a PLAN.md file and do the whole planning without ever leaving auto, haha)

claude going the wrong way? hit esc to stop him, tell him what's off, and he carries on from there - no need to wait for him to finish, or to start over

is claude a blank slate?

claude has two main kinds of memory, plus a notebook of his own (below). CLAUDE.md files are the persistent one - the project outline, conventions, decisions, gotchas - ideally checked into the repo, so they travel with the code and the whole team gets them. then there's the session itself - everything said and done in one conversation, saved on your machine (under ~/.claude/projects/), so you can come back to it later. more on sessions below

global preferences - global CLAUDE.md

~/.claude/CLAUDE.md is loaded into every session, in every project - the place for how you work, not how a project works. parts of mine for reference:

# Global instructions

## Collaboration feedback

The user has explicitly asked for ongoing, lightweight feedback on their
delegation style so they can calibrate it over time:

- If an instruction included implementation-level detail that could have
  been left to me to figure out, briefly note what could have been more
  relaxed.
- If an instruction was missing context I had to assume or guess to proceed,
  briefly note what would have helped and what I assumed.
- Keep it short — a line or two, only when there's something real to flag.
  Don't manufacture feedback when the instruction was already well-calibrated.
- This is about the *specificity/altitude* of instructions, not about
  praising or critiquing the underlying request itself.

## Flag likely spec omissions

When implementing a spec and noticing something that similar work in this
codebase would typically also include or touch (a companion hook, a related
call site, an analytics field, a config entry) but which the user's spec
didn't mention, ask before deciding on my own to add it or leave it out —
even if it looks like scope creep or like a reasonable place to stop. The user
tends to write thorough specs but knows they sometimes forget a piece
(especially around areas they're less invested in, e.g. analytics), and
would rather be asked than have it surface later in review. Don't stay
silent and don't just silently add it either — flag it explicitly and let
them decide.

## Keep CLAUDE.md up to date proactively

Update the relevant CLAUDE.md on my own initiative whenever something comes
up that a future session would benefit from knowing, without waiting to be
asked. The user often switches sessions without remembering to say "update
CLAUDE.md", and useful context gets lost that way. Examples: a root cause
found while debugging, a config or infra change and the reason for it, a
non-obvious gotcha, a decision made (including things deliberately *not*
done, so they don't get re-suggested), or an existing note that turned out
to be stale or wrong.

- Default to the project's CLAUDE.md. Only use this global file for things
  that apply across all projects (e.g. preferences about how the user works).
- Do it as the work happens, not only at the end, since a session can end
  abruptly.
- Keep entries concise and match the file's existing structure and style.
  Correct or remove stale info rather than piling contradicting notes on
  top.
- Mention in my reply what I added or changed (a line is enough), but don't
  commit it unless asked.

## External library/package documentation

Proactively use the Context7 MCP server (resolve-library-id + get-library-docs)
whenever a task involves an external library, framework, or package's API,
setup, or configuration — do this on my own judgment, without waiting for the
user to say "use context7". Reach for it when: the training data may be stale
for that library's current version, an unfamiliar/less-common package is
involved, or getting the API surface wrong would cost a debugging cycle.
Skip it for well-established, stable APIs unlikely to have changed
(e.g. Python stdlib, POSIX shell) where it wouldn't add real value — the
user's free-tier quota is limited (1,000 calls/month as of 2026), so don't
burn it on lookups that don't need fresh docs.

a few notes on the file above:

one thing i'd recommend to anyone - tell claude to add a section on your writing style - then, all Jira comments, MR descriptions, articles or anything else he drafts for you will come out sounding like you. the easiest way is to give him a few pieces of your writing, and tell him to extract the common style himself

note the "keep CLAUDE.md up to date" section. normally you'd have to remember to update CLAUDE.md whenever something worth writing down comes up - a root cause, a gotcha, a decision - and that's exactly the thing everyone forgets at the end of a long session. you can delegate that "remembering" to claude!

similar with external services like Context7 (up-to-date docs for libraries) - its docs say "make sure to tell claude to use Context7 when needed". well, who better to judge when it's needed than claude himself? tell him once, in the global file, when it's worth it and when it isn't, and stop thinking about it

the most helpful one for me was the "collaboration feedback". after years of refining tickets for others, i was spending time specifying things that weren't necessary - claude figures them out from the code just fine. note that underspecifying is just as bad: leaving out context that isn't apparent from the code hurts the quality of claude's work a lot - just as it would for any human without that context. the feedback goes both ways, and after a while you find the right altitude

also note the "spec omissions" bit. claude can be very eager, trying to complete the task at all costs, or very careful, checking in at every step of the way - tune this to your liking. i'd rather be asked about the piece i forgot than find it in review

per-project CLAUDE.md

for each project, keep CLAUDE.md in the repo root

on an existing project, you can start CLAUDE.md by just asking claude to write one - let him analyze the structure, add whatever he thinks is of interest, and go from there (there's also /init for exactly that). with the proactive maintenance from the global CLAUDE.md, the file fills up with useful info quickly

on a new project, claude will start the file on his own, keeping it very tight (provided you have the "proactive" clause in your global CLAUDE.md)

feel like the file has grown too large? just ask claude to trim it down - remove stale info, merge duplicates, drop what can be read from the code anyway

claude's memory

fyi - claude also keeps notes of his own: things about you, feedback you gave him, project facts he picked up. tell him "remember that…" and he writes it down, sometimes he does it unprompted. the notes live on your machine, per project (~/.claude/projects/…/memory/), and an index of them is loaded at the start of every session. they're yours only, never in the repo - so anything the team should know belongs in CLAUDE.md. want to know what he remembers? ask him

a few more tips

turn on the claude integrations that matter for the context - Jira, Figma, Sentry, etc. (ask claude how ;) - a ticket, a design or a stack trace claude can read himself beats one you paste in

forgetting to tick all the boxes on your definition of done? tell claude to keep an eye on it - once it's written down in CLAUDE.md, it's checked on every task, not just the next one

before starting a ticket, ask claude to check if it's consistent - especially if it's part of a larger epic. he can also clean up or correct the description for you, add reasonable acceptance criteria, and go through the comments to make sure no decision was made there without the ticket being updated

most of the time, you don't want to /clear the session - next time, claude has to analyze everything again, and the context and decisions from that conversation are lost. instead, /rename the session so it's easy to find later, and just start a new one (/exit and run claude again). being able to come back to it with /resume - e.g. for fixes found in QA - is priceless

if the ticket is one in a series, do reuse the same session. after implementing one ticket, you can tell claude what's good to know for the next ones - he'll remember it and apply it on the next ticket whenever that comes, without you having to remember it yourself

make sure to check the git diff yourself! it's the perfect place to catch context that was missed, or hidden dependencies that aren't in the code - and whatever you find there is worth a line in CLAUDE.md. it's also the perfect moment to catch some of the pearls claude puts in the code…

testing a ticket? just tell claude to check the changes on the branch against main, and compare them with the ticket and its comments. this is also where a good project CLAUDE.md comes in handy - claude checks the logic against all the context he knows, not just the diff

cunning trick - after a dev session with claude, start a new one, and ask the new session to test the code on the branch. it has none of the first session's assumptions, so it reads the code the way a reviewer would

god-mode trick - run several sessions side by side, one per repo or per part of the work, and when one needs something from another, just tell claude to contact the other session. each one stays in its own lane - the frontend session asks the backend one for the endpoint it needs instead of wandering into the backend code itself - so there's no scope creep, every session keeps a clean context, and the changes land where they belong, made by the session that knows that code best

the Claude in Chrome extension is a lifesaver! claude gets a real browser - he can click through the app to test a change, measure a page against the design, read the console and network requests, or mock a response shape the backend doesn't return yet. and - do you hate writing documentation as much as i do? claude can take the screenshots (with highlights), write the docs in your writing style, and publish it all on whatever system you have connected

and always - when in doubt, ask claude; when unsure, ask claude