Notes

How I work with Claude Code

Updated 2026-06-19

On this page

These are habits, not rules — the things that keep Claude Code productive and keep me in control of what actually lands.

Frame the task

The clarity of the first message sets how much steering follows. Vague asks need a lot of correction; specific ones often land on the first try.

Instead of "fix the login bug," I write: "Users see a blank screen after a failed login. Look in src/auth/, especially session handling. Write a failing test first, then fix it." Naming the files and stating what success looks like does most of the work.

TODO (Chris): drop in a task you describe often, phrased the way you'd phrase it.

Reach for plan mode on anything non-trivial

For changes that span several files, or an area I don't fully trust, I press Shift+Tab to enter plan mode. Claude reads and proposes an approach but edits nothing. I refine the plan through conversation, then approve it and let it execute. Separating "figure out the approach" from "write the code" catches misunderstandings while they're still cheap to fix.

Keep changes small and verifiable

I aim for diffs I can review in a few minutes. When Claude proposes a sprawling change, I ask it to split the work:

that's too much at once. Do it in steps, running tests after each:
1. add the table + migration
2. add the API endpoint with validation
3. wire up the UI

Small steps also make it trivial to undo one without losing the rest.

Always verify — "it compiles" isn't "it works"

This is the habit that matters most. Before I move on, I actually run the thing: the build, the test suite, and the feature by hand. Claude runs many of these itself, but I don't take "tests pass" on faith — I look at the output. When I'm unsure, I ask it to run a specific test and show me the result.

TODO (Chris): note your usual verification ritual for your main stack.

Manage context deliberately

Long sessions fill up. A few levers I use:

/clear when I move to an unrelated task.
/compact to summarize a long thread and keep going.
Esc to interrupt; Esc** **Esc opens the rewind menu to roll back to an earlier point if a direction didn't pan out.
Hand heavy reading to a subagent so the digging happens in its context, not mine.

Delegate to subagents

When Claude is about to read twenty files to answer one question, I send it to a subagent:

use a subagent to map how we handle API errors, then summarize

The subagent explores in its own context window and returns just the summary — my main thread stays focused. For workers I reuse, I define a custom subagent (see the customizing notes).

Know when to let it run — and when not to

If the direction looks right, I let Claude finish the thought instead of interrupting every step; constant nudging slows things down. But I do supervise anything with external side effects — migrations, deploys, calls to third-party APIs — and ask to see the plan before it runs.

I still drop to writing code myself when the task is three lines, when I'm learning a library by hand, or when I don't understand the surrounding code well enough to review Claude's change with confidence. In that last case I ask Claude to explain the area first, then edit.

Parallelize with git worktrees

To run more than one Claude session at once without edits colliding, I give each its own git worktree:

git worktree add ../proj-feature-auth -b feature-auth
cd ../proj-feature-auth && claude

Each session is isolated to its own working tree; I merge or rebase later.