My Claude Code workflow

Merge with the machine

Claude Code with Opus 4.5 is making waves. It really does feel like a step change in agentic coding tools – I built Flock, Medtracker, and retreatsfyi without writing a single line of code (although I did do a bunch of debugging myself).

My tips below.

---

Pay for Max

Max gets you much, much more usage, and is really the only feasible way to use Opus 4.5, which is a step change from older models. Just spend the money.

Multiple instances

Table stakes – you can run multiple instances of Claude Code to really rinse your usage limit. You can have Claude working on multiple features at the same time, or one main instance where you’re doing your work and then auxiliary instances that are doing other useful things like researching new features, merging in dependabot PRs, refactoring bits of the codebase etc.

Use worktrees as detailed below to make it really fly.

My usual workflow

• Check out a worktree branch

• Open Claude in --skip-permissions mode (I am insane; you should do this in some sort of sandbox)

• In plan mode, chat to Claude about what you want to build. This is especially good if you have a PRD somewhere in your repo which lists features you want to build and gives some project context.

• When you’re happy, tell Claude to build your feature, making sure all tests pass and the code is linted (or add those hints to your CLAUDE.md).

I’ll often have several Claude instances all writing up plans in multiple worktrees, and then review each plan as it comes in and get Claude to implement it.

Worktrees and worktrunk

Worktrees are super useful but have terrible ergonomics out of the box. You have to check out master, create the worktree in a specific directory, change dir, and then clean it all up when you’re done. I’m loving worktrunk, which adds a nice layer and CLI on top of worktrees. My basic workflow:

• wt list shows all your active worktrees

• you can wt switch --create <branchname> to switch to a new worktree

• wt merge runs any hooks you have defined in your config file (like running unit tests, lint), merges the branch into master, and cleans it up

You can also use a post-switch hook to launch a dev server on a specific port:

# Start dev server on a unique port per worktree (runs in background after switch)
post-switch = "bin/dev -p {{ branch | hash_port }}"

It integrates with Claude Code to show you what branch you’re on and the URL to the local server for that branch in your statusline.

Autoclaude

I wrote a tool which looks at your current tmux window, identifies which panes are running Claude Code, and lets you watch for the ‘usage limit hit’ notification. It then waits for your limit to reset and continues your session.

“Do it for me”

Wait… you mean you’re still doing things? You can just not do things!

Claude will often stop and give you instructions on how to proceed – checking app logs, checking the build status on GitHub, deploying an app to Heroku, configuring DNS on Route53. But it can do all those things itself!

Just ask Claude to “do it for me”. It’ll figure out what CLI tools you need, install them, and then do the thing for you (e.g. it’ll write a changeset to a tempfile and then pass it to the aws CLI to update your Route53 records).

Ask Claude to interview you

You can prompt Claude to use the AskUserQuestion tool to interview you. It’ll lie about how many questions you have left, so at some point you can tell it to stop and write up your answers. Claude already does this in plan mode, but by prompting it explicitly to use the tool you can use it to explore new features, vague ideas that aren’t yet fully-formed.

See this starter prompt.

Claude Code web

I think it’s a bit of a meh product and there are better ones out there. But you can ask it to bootstrap a setup script for your repo with some basic instructions (like telling it your stack and how it can boot a server, run lint and tests etc) and it’ll write one for you.

It’s still pretty good for oneshotting simple features, and it’s pretty fun to just smash out a few feature requests or bug fixes and they’re done by the time you get to your desk. You can use teleport to open the branch locally to test and make any finishing touches.

Automated QA

Install puppeteer and get Claude to open your running app in a browser and do its own integration testing. If it finds issues, it can fix them itself. Make sure to tell it to use headless mode if you don’t want random browser winders popping up all over the place.

---

I don’t think this is the last time we’ll see model and harness improvements that so drastically improve the way we write code and build products. The fact that there’s so much to get out of these relatively basic tips suggests that the harnesses could be improved much further.

Comment with any tips you have for getting the most out of Claude Code!