DEV Community: Yanai Ron

I replaced coding-agent orchestration with Git worktrees and one Python file

Yanai Ron — Wed, 16 Sep 2026 18:56:51 +0000

When I started running more than one coding agent against the same repository, the first problem was not model quality. It was filesystem state.

Two agents in one checkout can overwrite each other's files, change the same index, switch branches underneath each other, and leave a working tree that no longer explains which task produced which change. The obvious response is to add orchestration: a daemon, a task database, a process manager, or a UI.

I wanted to see how far plain Git could go first.

The isolation primitive was already there

A Git worktree gives one repository several working directories. Each worktree has its own checked-out branch and index, while the object database is shared.

That maps cleanly to a coding-agent task:

one task name
one worktree
one branch
one agent process
one reviewable diff

I turned that mapping into taskpods, a small Python CLI with no runtime dependencies.

pip install taskpods

From inside a Git repository:

taskpods start tests --agent codex exec --sandbox workspace-write "add API tests"
taskpods start docs --agent claude -p "improve the docs"

The first command creates .taskpods/tests on pods/tests. The second creates .taskpods/docs on pods/docs. Each agent runs with its worktree as the current directory.

The agents do not need a taskpods integration. Everything after --agent is passed through as the command to execute. That means the same mechanism works with Claude Code, Codex CLI, Gemini CLI, opencode, aider, or a local script.

The pod is disposable, but the result is not

An agent process exiting does not delete its worktree. The pod stays in place so I can inspect the actual diff:

taskpods list
git -C .taskpods/tests diff main
git -C .taskpods/docs diff main

If I want the change, I finish the pod:

taskpods done tests -m "Add API tests" --remove

done stages and commits the worktree, pushes its branch, and uses the GitHub CLI to open a pull request when gh is available. --remove removes the worktree after the branch is safely on the remote.

If I do not want the change:

taskpods abort tests

The abort path checks whether the branch exists on the remote. If it does, taskpods refuses to delete it automatically. That guard matters because "disposable" should describe the local environment, not already-pushed work.

There is also a cleanup command:

taskpods prune

It removes pods whose branches have already been merged upstream.

Why I kept it small

There are good tools for supervising fleets of agents, managing terminal sessions, assigning tasks, and reviewing results. taskpods is intentionally below that layer.

It does not schedule agents or coordinate their reasoning. It does not maintain a database. It does not run a daemon. It makes one narrow guarantee: each task gets a separate Git worktree and branch, and the lifecycle from start to review to PR or abort is explicit.

The current release is one Python file, supports Python 3.9+, and has no runtime package dependencies. Git remains the source of truth.

That small surface also makes it composable. A shell script, CI job, task runner, or higher-level orchestrator can call taskpods without adopting another state model.

What I am testing next

The current release is v0.4.0. PePy reports 2,117 cumulative downloads, which is enough to start seeing whether the worktree model survives use outside my own setup but far too early to declare the interface settled.

The cases I want to learn more about are:

several long-running agents against one repository
interrupted agent processes
branch cleanup after manual merges
repositories whose default branch is not main
teams that want task isolation without a permanent control plane

The code and issue tracker are here:

https://github.com/yanairon/taskpods

If you use Claude Code specifically, I maintain claude-hookbook separately: reviewed hooks for formatters, guardrails, and notifications. I kept it separate because hooks configure one agent, while taskpods isolates any agent at the Git layer.

If taskpods saves you time, the repository has optional GitHub Sponsors and Ko-fi links.

I got tired of rewriting the same Claude Code hooks in every project, so I built a hookbook

Yanai Ron — Fri, 11 Sep 2026 12:24:29 +0000

A few weeks ago I noticed every Claude Code project I touch starts with the same ritual: I want Prettier to run after Claude edits a file, I want a notification when it asks for permission, and I really want it to not touch my .env files. So I open the hooks docs, dig up an old gist, hand-write a settings.json block, get the matcher slightly wrong, debug it, and repeat the whole thing on the next project.

Hooks are one of the best features in Claude Code: deterministic shell commands that fire on events like PreToolUse or PostToolUse, so the boring stuff happens every time without relying on the model to remember. But the setup friction means most people run with zero hooks.

So I built Claude Hookbook: a reviewed library of 20 copy-ready hooks, plus a generator that composes the ones you pick into one valid settings.json.

What's in the book

20 hooks covering the stuff I kept re-doing:

Formatters that run after an edit: Prettier, ESLint, Ruff, gofmt, rustfmt.
Guardrails that block before something runs: stop Claude from writing to .env and credential files, block destructive shell commands, run gitleaks on staged changes before a commit.
Quality gates: run the nearest test after an edit, typecheck TypeScript in the background, block task completion while your project check fails.
Quality of life: desktop notification when Claude needs input, a session-start repo snapshot, re-injecting project context after a compaction.

Every hook page lists the event and matcher it uses, the risk level, what it needs installed, install and test steps, and - for the blocking ones - a recovery note for when it fires and you disagree.

The honest part: test status

Hooks run code on your machine, so I didn't want a site full of unreviewed snippets. Each hook ships with provenance (sources and what Claude Code release it was checked against) and a test badge: tested only after a real install plus a positive and negative trigger run against the current release. Until then a hook shows needs-manual-check with the exact test steps on its page. Right now most of the library carries that badge - I'd rather show you the checklist than fake a green one.

The generator

The part I built for myself: tick hooks on the site and the generator emits one merged settings.json. The single-hook pages and the generator build the config fragment from the same canonical fields, so they can't drift apart. No CLI, no account, runs in the browser.

Stack and repo

It's a static Next.js site on Vercel, all routes pre-rendered. Hooks live as one JSON file per hook, validated at build time by a Zod schema, so a malformed hook fails the build instead of failing on your machine.

Repo: github.com/yanairon/claude-hookbook. Issues and hook requests welcome - if there's a hook you keep rewriting in every project, tell me about it in the comments.

I got tired of my AI agents fighting over one repo, so I built taskpods

Yanai Ron — Thu, 10 Sep 2026 14:41:33 +0000

A few months ago I started running AI coding agents in parallel: one fixing a bug, one updating docs, one trying a refactor. The agents were fine. My repo was not.

Every agent CLI works in your working tree. Two agents on the same repo means they edit the same files, stage each other's changes, and occasionally commit on top of one another. The "solution" I kept seeing was manual git worktrees: create one per agent, remember the branch names, remember where you put them, clean them up later. It works, but it's fiddly enough that I kept not doing it.

So I wrote the thing I wanted: taskpods, a small Python CLI that wraps git worktrees into disposable "pods".

pip install taskpods

What a pod is

A pod is a git worktree plus a branch, managed as one unit. One command creates it and drops your agent inside:

taskpods start fix-auth --agent "claude -p 'fix the token refresh bug'"

That creates .taskpods/fix-auth/ as a worktree on branch pods/fix-auth and runs the agent there. --agent takes any command, so it works with claude, codex, gemini, opencode, a shell script, whatever you use. Start a second pod and the two agents never see each other's files:

taskpods start docs-update --agent "claude -p 'document the config options'"
taskpods list

The lifecycle

When an agent finishes, I review the diff like I would for a junior dev:

git -C .taskpods/fix-auth diff main

If it's good:

taskpods done fix-auth -m "fix: token refresh" --remove

That commits, pushes the branch, opens a PR if you have gh installed, and removes the worktree. If it's bad:

taskpods abort fix-auth

and the pod never existed. Abort refuses to delete work you've already pushed, which has saved me once already.

Design choices I cared about

Zero config. No daemon, no TUI, no config file to learn. It's one Python file over plain git worktree commands. If you know git, you already know what it's doing.
Agent-agnostic. Claude Code has a native worktree flag now, but it's Claude-only. I wanted the same workflow regardless of which agent I'm using that week, and I wanted the lifecycle (list / done / abort) in one place instead of in my shell history.
Boring on purpose. Pods are real worktrees with real branches. Nothing is hidden in a database somewhere; you can cd into a pod and use git normally.

What's next

It's MIT-licensed and on PyPI: github.com/yanairon/taskpods. v0.4.0 just shipped with the --agent launcher. I'd genuinely like to hear how other people run parallel agents - if you have a workflow that works better, tell me about it in the comments.