Subtask gives every Claude Code subagent its own Git worktree

One Git worktree per task is the whole concurrency model

Everything Subtask does hangs off a single decision: each task gets its own Git worktree. Two subagents editing two branches in two directories cannot collide on a file lock, which is the failure that stops people from running parallel agents in one checkout.

Tasks are named like branches. The README's own transcript shows `subtask draft fix/auth-bug ...` and `subtask draft feat/api-metrics ...` issued in one turn, so a single request becomes several tasks, each with a branch-shaped name that ends up in the worktree path. Task state is persisted in folders rather than in memory, which is what lets a later session pick up where an earlier one stopped.

Three status values appear in the listing: draft for something not started, working for a subagent inside it, and replied once the subagent has answered and Claude has come back with something to review. The `subtask list` output in the README shows all three at once, one draft task sitting next to a working one and a replied one.

The claim the README makes about Claude interrupting and talking with subagents is the part that distinguishes this from a plain task runner: the loop does not end when a subagent is spawned, it stays open for follow-up messages on the same task.

The TUI is a Bubble Tea program reading those task folders

Running `subtask` with no arguments opens the terminal interface, which the README says shows progress, diffs and conversations. The dependency list in go.mod says how that is built: charmbracelet bubbletea for the event loop, bubbles and lipgloss for the widgets and styling, glamour for markdown rendering in the conversation pane, huh for the interactive forms, termenv and ultraviolet for terminal handling, go-osc52 for clipboard and escape sequence support.

Two other dependencies explain features you would otherwise have to guess at. `github.com/rhysd/go-github-selfupdate` is why `subtask update --check` and `subtask update` exist at all, and `modernc.org/sqlite` is a pure Go SQLite, which keeps the binary free of cgo. `github.com/alecthomas/kong` handles the command line, `blang/semver` the version comparisons, and `gopkg.in/yaml.v3` the YAML that task configuration is read from.

For the conversation view, glamour is the relevant one: it renders markdown, so a subagent's diff summary and its prose are displayed as formatted text rather than raw.

The repository layout matches a Go CLI with a UI split from its core: cmd/, internal/ and pkg/ hold the program, plugin/ and .claude-plugin/ hold the Claude Code integration, docs/ the documentation, scripts/ the helper scripts, and .goreleaser.yaml the release configuration that produces the binaries behind every install method.

Four install paths, and the project says they will be simplified

Installation has more routes than most tools this size, which is a symptom of where the project is. On macOS and Linux the script route is one line:

curl -fsSL https://subtask.dev/install.sh | bash

Windows has its own PowerShell equivalent, `irm https://subtask.dev/install.ps1 | iex`. The other three are Homebrew, a Go install and plain binaries:

brew install zippoxer/tap/subtask
go install github.com/zippoxer/subtask/cmd/subtask@latest

Binaries are also published on the GitHub Releases page, which is the route to take if piping a script into a shell is not something your policy allows. The module path is github.com/zippoxer/subtask and go.mod pins Go 1.24.2, so the `go install` route needs a recent toolchain.

The README is upfront about the state of all this. A note in the setup section says Subtask is in early development and that upcoming releases will simplify installation, solve known bugs and improve Claude's proficiency. Four installers for one binary in that state is a maintenance surface, not a convenience, and the self-update path depends on GitHub reachability from the machine where you run it.

The Skill is what makes Claude reach for the CLI

The CLI alone does nothing interesting. The interesting part is the Skill, which teaches Claude Code when to call it.

The documented way to install it is to tell Claude Code to run the guide:

subtask install --guide

Claude then installs the skill at `~/.claude/skills` and asks whether subagents should run Claude, Codex or OpenCode. That question is asked once, at install time, and it decides which agent binary your tasks dispatch to. The README lists Codex subagents as supported and the built-with-it section says the author runs Codex for subagents while Claude Code leads, so both arrangements are exercised.

There is a manual path too, `subtask install` on its own, with `subtask uninstall` for removal later.

Separately, an optional plugin makes the invocation more reliable. In Claude Code:

/plugin marketplace add zippoxer/subtask
/plugin install subtask@subtask

The plugin's stated job is small and specific: it reminds Claude to use the Subtask skill when it invokes the CLI. Without it, discovery depends on Claude choosing the skill on its own, which is exactly the kind of behaviour that varies between sessions and model versions.

Merging is a conversation Claude starts, not a command you run

The workflow the README describes has three steps and none of them is a merge flag. Claude Code creates the tasks and runs the subagents simultaneously. Claude is notified when they finish and reviews the code. Claude then asks whether you want to merge or want changes requested.

That last step is the design decision. Merging stays inside the same conversation where the task was created, with the diff available in the TUI, so the person reviewing does not have to reconstruct context from a branch name. Requests for changes go back to the subagent on the same task, which is what the replied status is for: the subagent answered and is waiting on a human.

Updates are handled by the same binary, through the self-update library in go.mod:

subtask update --check
subtask update

Checking before updating is the sensible order, since a bug-fix release can change how Claude is prompted to use the tool and the README's early development note expects exactly that kind of churn.

One thing the documentation does not cover: any way to run this without Claude Code in the loop. Every documented path starts from a conversation with Claude Code and a request to use Subtask, so if you were planning a CI job or a batch script, nothing in the README describes it.

One author, two beta tags in a day, and a note about known bugs

The maintenance picture is narrow and worth stating plainly. Version 0.2.0 was tagged on 2026-01-29, one day after v0.2.0-beta.2 and v0.2.0-beta.1, both on 2026-01-28. The last push to the repository is dated 2026-04-27.

The README's own note calls the project early development and promises simpler installation, bug fixes and better Claude proficiency in upcoming releases. Combined with the release cadence above, plan on the CLI changing shape under you, and read the CHANGELOG-style release notes before upgrading a machine that several people depend on.

The repository also carries AGENTS.md and CLAUDE.md alongside a .claude/ directory, which is the standard way a project documents the rules for coding agents working inside it. A Go tool built this way, where the tool itself is the agent's task manager, keeps its own conventions in version control with the code.

Licensing is MIT, with the LICENSE file at the repository root and no CLA or other contributor agreement mentioned in the README.

For an MIT project with a single visible author, the practical question is not the licence but the bus factor: if the author stops, the worktrees, the task folders and the Claude prompt conventions stop with them, and nothing in the repository suggests a plugin API another maintainer could build against.

Editorial conclusion

Adopt Subtask if you already live in Claude Code and want three unrelated fixes worked on at once without merge conflicts, since the worktree-per-task design is the part that works and the statuses in subtask list make the state readable. Do not adopt it for CI, for a headless runner, or for a team that needs an audit trail, because the README documents no non-interactive mode, no configuration file and no test story, and the last push to the repository is dated 2026-04-27 with v0.2.0 published on 2026-01-29. Verify three things first: run subtask install --guide and confirm the skill lands where your Claude Code setup expects at ~/.claude/skills, decide now whether subagents will be Claude, Codex or OpenCode because that answer is baked into the setup, and try subtask update --check to see whether your machine can reach the update path at all before you depend on it.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. zippoxer/subtask on GitHub