Manage Claude Code With the Habits of a Good Team Lead

What You'll Get

A compressed method for managing agents: the habits that work best for leading a team, condensed into 5 steps and 1 checklist to run before you let it work on its own. Each step maps to a feature that already exists in Claude Code. The article includes 3 pieces you can copy directly: a task brief template, a rule block to paste into CLAUDE.md, and a checklist for starting unattended tasks.

Get the division of labor right: the agent's job is to finish the work and produce evidence; your job is to explain the context, define "done," and make the calls at the critical points. Writing the prompt is only a small part of it. Most of the effort goes into how you hand things off and how you verify the results.

Why You're Already a Manager

Every day you work with Claude Code, you repeatedly do these things: pick tasks, hand them off, wait for results, review them, and decide whether to merge. That is management; the only difference is that your subordinate is an agent. The things that made you miserable under a bad boss almost all have an equivalent with an agent:

Vague handoffs: you toss over a single sentence, while the real requirements stay in your head, so the result is naturally wrong.
Trusting reports without checking evidence: it says "done" and you believe it, and in the end you become its tester.
Micromanaging everything: you fill the rules with capitalized "MUST" and "NEVER," and the agent ends up slower and more rigid.

The good news is that after suffering through so many bad handoffs, you already know what a good handoff looks like. The five steps below apply that to agents.

Step 1: Tell It What It Can't See

When an agent receives a task, the first thing it does is read your code. It can see the directory structure, naming conventions, and how tests run faster than you can explain them. So don't restate the code in your brief. Spend your words on what isn't in the repository: why this work matters, what was decided in meetings, what must not be touched, and what counts as finished.

For example, a one-sentence task like "occasionally the CSV export garbles characters" can be expanded with this template:

Goal: [Customers export order CSVs from the back office, and Chinese characters occasionally turn into garbled text when opened in Excel]
Why it matters: [This week 6 customers have complained, and support has to convert the encoding by hand each time]
Known clues: [Only happens with notes containing emoji; opens fine in Numbers on Mac]
Constraints: [Do not change the CSV column order, since downstream scripts read by position; do not introduce new dependencies]
Out of scope: [Export speed, exporting to Excel format]
Definition of done: [Add a test case containing Chinese and emoji that opens correctly in Excel; all existing export tests pass]
Report back: [Which files changed, why it was changed this way, test output]

Not every task needs a brief this complete. For exploratory work, you can state things loosely and fill in details as you go. If you're unsure what you want, have it ask you questions in return until it can write a requirements document, save that document as a file, then start a new session and work from it. That document will also serve as the basis for acceptance later.

If it needs to see an issue tracker, error panel, or team chat logs, connect the relevant tools the same way you would grant permissions to a new colleague. Command-line tools it already knows how to use, such as gh, don't need special instructions.

Step 2: Approve the Plan Before Action

For larger tasks, enter plan mode, where it only produces a proposal without changing code. Go back and forth until you're satisfied, then let it write the code. When the plan is right, the work often gets done in one pass.

When reviewing the plan, focus on what it assumed by default. Asking directly "what are you least confident about in this plan?" is like asking a subordinate in a one-on-one "where are you stuck?" For especially large changes, you can open a second session and have it review the plan as a senior engineer, which is the cheapest time to correct direction.

When working in parallel, first confirm that the pieces of work don't overlap. If several agents modify the same code, you don't get several times the output; you get a merge conflict that several people have to resolve together. Claude Code's built-in /batch can split a large mechanical change into multiple pieces, each done in its own independent working copy (worktree) and opened as its own PR. Your job is to check that the split has no overlaps and that shared interfaces are merged first.

Step 3: Give It a Check It Can Use to Judge Its Own Work

This is the most valuable step. An agent stops as soon as it feels the work "looks done." Without any way to check, "looks done" is its only standard, and all verification falls on you.

The checking method only needs to give a clear pass or fail: tests, whether the build succeeds, lint, comparison scripts, or page screenshots. When changing a UI, have it actually open the page in a browser and keep adjusting until it looks right. Writing the commands that run these checks into CLAUDE.md (the instruction file it reads at the start of every session) is the single most useful line in that file.

Once you have checks in place, choose the level of force you need:

Level	How	Suited for
Verbal request	"After the changes, run the login-related tests until they all pass"	Routine small tasks
Set a goal	Use `/goal` to write a completion condition that is checked after every round; if not met, it keeps going	Long-running tasks in the background
Enforce	Configure a Stop hook so the round can't end if the type check fails	Checks that must never be skipped
Independent review	Use `/code-review` to hand the changes to a new session that hasn't seen your conversation	Before merging

When asking it to review, say exactly what to review. A bare "find problems" never comes back empty-handed; if you say "only look for issues that would cause wrong results, and ignore code style," the results will be far more precise.

Step 4: Watch the First Minute, Restart After Two Failed Corrections

The first minute after a task starts is the most worth watching. As soon as you spot the wrong direction, press Esc to interrupt and state your point clearly.

If you've corrected the same thing twice and it's still wrong, don't correct it a third time. The problem is most likely in your handoff, not in the agent's effort. If you keep correcting, the failed attempts stay in the conversation, and it has to reread all of it every round. The right move is to clear the session, write what you learned from those two corrections into a better prompt, and start over.

Rolling back is now cheap: /rewind can return both the code and the conversation to an earlier point. So you can safely let it try a bolder approach first and roll back if it doesn't work. Afterward, think about why it went off track, and write anything worth remembering into the rules described in the next step.

Step 5: Write Anything Corrected Twice Into the Rules

Having to re-correct the same thing every session is the biggest waste. When you correct the same thing for the second time, write it into the project's CLAUDE.md; for a whole repeated workflow, turn it into a Skill (see the Skill handbook). What you write down won't be lost when a colleague leaves or the model changes.

CLAUDE.md should be short and cover only these kinds of things:

How to verify (specific commands)
Places in the code that are easy to misread
Decisions that can't be seen from the repository
Things corrected twice

There are two kinds of rules: prompts, CLAUDE.md, and Skills are "suggestions," and the model decides based on the situation whether to apply them; hooks and deny rules are "hard requirements" that are enforced every time. For most things, let the agent judge for itself, since it looks at the real code and often judges better than rules you wrote in advance. Only the few things that must be done 100% of the time warrant a hook, such as "never modify auto-generated client code."

The reverse also needs regular cleanup: anything in CLAUDE.md you've emphasized several times that it still ignores should become a hook; hooks that only enforce personal preferences should be deleted. Current models no longer need all-caps commands or phrases like "think carefully" and "don't slack off," and including too many of them causes overcompliance. For an agent, too many procedures are the new micromanagement.

Condense these five steps into the block below and paste it directly into the project's CLAUDE.md or AGENTS.md, so the agent reads it at the start of every task:

New accounts get 10 free credits, plus 1 more for each daily check-in. Spend 1 credit to unlock and it stays open for you.

Replace the bracketed items with your project's real commands and examples. The "Known Pitfalls" section can start out empty; let the agent add entries itself when it is corrected, and review it periodically to remove outdated ones.

Before Letting It Run Alone: Five Questions

Before letting an agent run in the background, overnight, or on a schedule, answer these five questions, the same way you would before handing a project to a senior colleague and going on vacation:

Question	How to answer
Is "finished" defined for it?	A `/goal` completion condition, a requirements file, or a failing test it must fix until it passes
Can it check its own work?	Tests, Stop hooks, a review step
Where is its scope of activity?	Permission settings, a sandbox, a separate working copy, one branch it may push
When must it stop?	Turn limit, spending cap
Where do results go, and who approves them?	A PR or a summary; any irreversible action needs human approval

Pilot new tasks first: for batch tasks, run 3 files first, tune the prompt, then run the rest; for any new automated task, personally watch the first few runs through to completion, like a probationary period.

Keep the Decisions for Yourself

You can hand off the work, but not the judgment. Product tradeoffs, security boundaries, and whether to ship are yours to decide. Review every change using the standard of "if this breaks, I don't want to be woken up at midnight." If the tests are green and the naming looks reasonable so you click approve, that isn't review; it's rubber-stamping.
Keep changes small. Let it change as much at once as you can realistically review.
The speed at which you add agents should track your ability to check their work. The first few agents are easy; each additional one after that demands more of your attention. Being able to run more in parallel depends on your needing to watch less and less, not on watching more closely. Use notifications instead of repeatedly checking, and keep background tasks in one place to review together.
Measure outcomes, not output. Look at how long a PR takes from opening to merging, and how often rework and rollbacks happen; "how many lines of code the AI wrote" is not a goal. When you count merged PRs, count rollbacks too.
Be willing to say no. Opening a PR costs almost nothing now, but every PR needs someone to review it and someone to maintain it. Before starting, ask three questions: Who wants this? How will we know it succeeded? When should we stop?

Where the Analogy Breaks Down

Managing people is far harder than managing agents. Being able to run five agents doesn't mean you can lead five people: motivation, conflict, career development, and long-term trust are not things an agent has.
Rework is almost free. For a contested technical approach, you can have it build two or three versions and compare them.
It has no experience, only notes. Automatic memory lives only on your computer, and colleagues' sessions can't see it. Lessons worth passing on need to be written into files shared with the team.
It agrees with you too easily. A good engineer will push back on your mistaken requests, while an agent will mostly comply, and you may over-trust it. Have it argue the reverse of its own answer to block some overconfidence.
Every agent you run shares one profile of talents and blind spots, and that profile shifts with each model update, so your habits need to adjust accordingly.
Don't crowd out newcomers' chances to practice or the team's time to learn. When agents take over the entry-level work, you'll need to deliberately arrange how new people build fundamental skills.

Notes

These five steps are ordered by payoff: with limited time, do Step 3 first and give every task a check that can run.
/goal, /batch, /rewind, /code-review, and hooks require a fairly recent version of Claude Code; if a command isn't found, update first.
When CLAUDE.md grows long, prune it: it is read in full at the start of every session, and outdated rules only add noise.
To turn a repeated workflow into a Skill, or to understand why context fills up, see the context handbook and the workflow handbook.