claudet: Structured Worktree Sessions for Claude Code Agents
The hard part of working with Claude Code agents isn’t getting them to write good code. It’s remembering what each one was doing when you come back tomorrow.
Between tasks, while Claude was still working, I’d review its output and start planning a different feature in my head. Sometimes two or three plans were ready before the first task was even done. So I started creating git worktrees by hand — one per feature, one Claude session per worktree. The isolation scaled. My ability to track it all did not.
After a couple of weeks, I had worktrees everywhere. Some needed resumed sessions. Some had commits ready to push. Others were waiting on PR reviews. Keeping track of which worktree was doing what, where each one left off, and what needed my attention — that became its own job. The overhead of managing parallel agents needed its own tool.
That tool became claudet.
One Agent, One Task, One Directory
Claude Code has --resume. It can pick up a conversation where you left off. For a single task, that works fine.
The problem starts when you’re working on three features at once. If they share the same directory, context bleeds between tasks. Planning for one feature mixes with execution of another. The agent can’t keep a coherent thread when the working directory is a battleground of parallel changes.
Git worktrees solve the file isolation — each feature gets its own directory, branch, and file state. Claude Code even has a --worktree flag for basic worktree creation. But isolation alone doesn’t give you coordination. Which worktree is mid-implementation? Which is waiting on review? Where did the agent leave off in each one?
The pattern I ended up with: worktree + plan file + auto-injected context. Each agent session gets a plan file that works as structured memory — not conversation history, but task state. The plan gets injected into the agent’s context on startup. The agent reads it, picks up where the task left off, and writes its progress before ending.
claudet makes this pattern easy to use.
How claudet Works
Run claudet. That’s it. You get an interactive picker to choose a repo, then pick a worktree or create a new one. Claude starts inside that worktree with the plan file already connected.
When you create a new worktree, claudet does the full setup: creates the git worktree, symlinks .env files from the main repo, runs your project setup commands (like pnpm install), and creates a plan file from a template:
# feat/user-avatars
## Context
<!-- Why this change is being made -->
## Objective
<!-- What will be done -->
## Ticket
PROJ-1234
## Target Branch
dev
## Key Files
<!-- Files that will be created/modified -->
## Test Scenarios
<!-- Test plan using AAA format -->
## Status
pending
## Progress
- 2026-03-25 09:00: Created worktree, started planningThe plan file lives at ~/.claudet/repos/<slug>/plans/<name>.md — outside the worktree, so it stays even if you delete the working directory.
When Claude starts, claudet writes a session rule into .claude/rules/session.md that tells Claude where the plan file is. Claude reads the plan, checks the Status, and knows what to do. pending means start planning. in-progress means read the last Progress entry and continue from there.
The worktree picker shows everything you need — status, branch name, PR state:
in-progress user-avatars feat/user-avatars PR #42 open
pending auth-redirect fix/auth-redirect no PR
review invoice-export feat/invoice-export PR #38 ✓ approvedNo need to remember anything. The state is right there.
Multiple Tasks, Each Following Its Own Plan
The real value shows up when you have several features going at once. Each worktree has its own plan file. Each plan tracks what was done, what’s next, and what the current status is. You don’t need to remember any of it.
When I start a session, Claude reads the plan and follows it. If the status is pending, Claude begins planning — filling in key files, writing test scenarios, defining the approach. If it’s in-progress, Claude reads the last Progress entry and continues building.
When there is nothing left to tell Claude and the code is out for review, the session can be closed. The worktree stays there, but I move on to the next task. Same for QA: once the feature is handed off, the session is done.
Days later, when review feedback arrives or QA finds an issue, I run claudet, pick that worktree, and start a new session. Claude reads the plan, sees the full history of what was built and why, and picks up from there. No context lost, no re-explaining.
When the PR finally merges, claudet clean archives the worktree — removes the directory, keeps the plan file for history.
What I Learned Building This
Context is king. A focused plan with the right input — planned decisions, expected outcomes, and progress tracking — is enough to complete a task. You don’t need complex orchestration or custom prompts. You need a clear plan file that tells the agent what it’s working on, what’s been decided, and what’s next.
Worktree management can be easy. Tracking each task in its own worktree, checking GitHub state, selecting the right directory, and resuming work after hours or days — all of this can be effective and simple. It doesn’t need to be a heavy process. A picker, a status display, and a plan file per worktree is enough.
Build on how Claude works. It’s easier to bring structure to your workflow and let Claude be fluid when all the context is set. Calling Claude from other CLI tools lets you inject flexibility where it’s needed — you control the setup, Claude does the work. claudet doesn’t fight how Claude works. It just makes sure Claude has what it needs before it starts.
Get Started
claudet is open source. Install it and run:
git clone https://github.com/lgabriellp/claudet.git
cd claudet
npm run setupIt walks you through first-time setup — scanning for repos, setting defaults. From there, it’s one command to pick a worktree and launch Claude with a plan.
Even if you don’t use the tool, the pattern works anywhere: create a worktree, write a plan file with Context, Objective, Status, and Progress sections, and point your agent at it on startup. The structured plan is what gives the agent memory. The tool just removes the friction.