---
title: How I work with Claude Code
---
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:
```bash
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.
## See also