coding with agents_

A friend who uses Claude Code asked me how to get more out of it. She is well past typing a question and reading the answer, but she hadn't met the pieces that turn it into a real collaborator: skills, MCPs, subagents, and the rest. So I wrote the map down instead of explaining it the once.

This is not a manual and it is not a checklist. It is a glossary of the moving parts in plain words, a look at how I have wired mine, and a short pile of people and docs worth your time. Poke at whatever looks interesting and ignore the rest.

Start with one picture: the agent is only as good as what's on its desk.

The agent works at a desk with limited space (its "context window"). It can only reason about what is on that desk right now: the files you have shown it, the conversation so far, the tools it has been handed. It is sharp but forgetful, and a cluttered desk makes it worse, not better.

So the whole craft is managing that desk. Put the right things on it, give it the right tools, and clear it off between unrelated jobs. Almost every technique below is a version of that one idea.

The pieces, in plain words

CLAUDE.md

A plain markdown file at the top of a project that Claude reads at the start of every session. It is where you write down the things you would otherwise repeat every time: how the code is laid out, which libraries you prefer, your conventions, what "done" looks like. Think of it as the standing brief you would hand a new teammate. This is the single highest-leverage thing most people are missing.

Slash commands and skills

A skill is a saved workflow you trigger by name (you type /something). You write it once and call it instead of re-explaining yourself every time. My work skill is a good example: point it at a task and it opens a fresh isolated workspace off the latest main, writes a plan, has a second agent poke holes in that plan, waits for my ok, implements it, runs a set of reviewer agents over the result, then ships it. That whole sequence is one markdown file I can read and edit.

Subagents

A subagent is a fresh helper with its own clean desk. It goes off, does one focused job (search the codebase, review a diff, research a question), and reports back just the conclusion. The point is to keep your main conversation uncluttered: the helper reads the forty files, you get the two-line answer. It is also how you run many things at once, which comes up again below.

MCP servers

MCP (Model Context Protocol) is a standard way to give the agent hands and eyes beyond your files. An MCP server connects it to a real system, and it is the difference between an agent that can only talk about your code and one that can open a pull request, read your logs, or click through a page to check it renders. Anthropic describes it as a USB-C port for AI: one plug, many devices. The ones I lean on:

Hooks

Hooks are little scripts that run automatically at set moments (before a tool runs, after you stop, when a file is saved). People use them to auto-format code, block a risky command, or run the tests. This is how you turn "please remember to" into "it just happens." More advanced, but worth knowing it exists.

How the work actually flows

I don't run anything in a loop. I point a skill (usually work or research) at a task, watch the plan and the steps as they go, and when it is done I clear or compact the context and start the next thing fresh. A clean desk between tasks matters more than people expect.

There are two gears. For anything critical I keep one window open, run the skill there, and review the plan and each step myself. For a pile of parallel, less-risky work I fan out: either several Claude Code windows each running a skill, or one window that spins up subagents which each run work or research on autopilot (start to finish, without me gating every step). Same skills either way. The only question is how closely I want to supervise.

Plan mode is the built-in version of that "show me the plan before you touch anything" step, and it is the habit I would keep even if I dropped everything else.

Running several agents at once

When I fan work out like that, each agent needs its own isolated copy of the code to work in. Otherwise two of them editing the same files at the same time trample each other. There are two tools for the isolation.

The common one is a git worktree: each agent gets its own folder checked out to its own branch. Worktrees are fine, and a good place to start. They are also the mental precursor to the next thing.

I use Jujutsu (jj) workspaces instead. The short version of why: everything stays reachable from one place. You can jump between branches, commits, and files without cd-ing around a pile of separate folders, edit something in place even while three or four agents are mid-run, and (the one that matters most) review everything happening across all of them in a single view. With worktrees that cross-agent review is clumsy. jj makes "what did all my agents just do" easy to answer. It is its own little rabbit hole, and not where I would start on day one, but it is what keeps parallel work from turning into chaos.

What it looks like with the dials turned up.

To make it concrete, here is roughly how mine is wired. Not a template to copy, more so you can see what the pieces look like once they compose. Most of it lives in a public template repo of mine, which is not always in step with my private repos but resembles them closely:

The value in a skill is that it is opinionated. It pins down how you want an agent to work: how to commit, how to structure code, when to stop and ask you. That only helps if the opinions are ones you actually hold, so you either write your own or borrow a set you like. Matt Pocock publishes his skills as a repo you can read and steal from (his grill skill, which makes the agent interrogate you about a plan before it builds anything, is a good one), and my template is another starting set. Neither is gospel, just opinions you can keep or throw out.

None of this appeared at once. It accreted one file at a time, each time I caught myself repeating an instruction. That is the whole trick hiding in it: when you explain the same thing twice, write it down where the agent will read it. The setup grows itself from there.

A pile of materials

People:

Docs and essays:

One thing that actually unlocked it

I did not hand-write any of this. Not the skills, not the CLAUDE.md files, none of it. I brain-dump how I work and what I believe about code at the agent, and it writes the files. And I do that dumping by voice, which is the real unlock. Talking is far faster than typing for getting a messy idea out of your head, and the agent tidies it up into something usable. I use WisprFlow for voice-to-text.

And it is not just for writing skills. I talk through most things: what I want to build, how a system should be shaped, the trade-offs. It is especially good paired with a diagram. I have a tldraw skill that turns talking into a whiteboard, so I can describe an architecture out loud, watch it draw the system design, correct it, and go back and forth until the picture is right.

That is usually how a piece of work starts: talk it into a diagram and a written plan, read both, argue with them a bit, and only once it has settled do I hand it to the work skill to build. The talking is the cheap part. Getting the plan right before any code is where the leverage is.

So if you want to try something this week, none of it is a checklist, just low-stakes places to start:

That is the whole map. If you get stuck or find something great that I missed, tell me: [email protected].

← read the newsletter