zippoxer/subtask: a Claude Skill that runs your tasks in Git worktrees
Claude Skill to do your tasks with subagents in Git worktrees
At a glance
- What is it?
- Subtask is a Go CLI plus Claude Code Skill that turns a request into tracked tasks, each running a subagent inside its own Git worktree. It is early software, and the README says so.
- Who is it for?
- Adopt Subtask if you already drive Claude Code or Codex on a repository and you want several tasks in flight without branch collisions, and you accept that the README itself calls the project early development. Do not adopt it if you need a stable, documented interface for CI, or if you are not working inside Git.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 141 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Subtask targets: one agent, one branch, one task at a time
A coding agent working directly in your checkout has a single working tree. If you ask it to fix an auth bug and add API metrics, those two jobs share the same files, the same index and the same branch. Sequencing them is slow; interleaving them invites conflicts. Subtask's answer is to give each task its own Git worktree, which is the mechanism that lets the README claim tasks "can be done in parallel safely".
The audience is narrow and specific. You need Claude Code or Codex already in your workflow, a Git repository as the working directory, and enough tolerance for rough edges to run a tool whose own setup note says it is "in early development". If you are looking for a general task manager, Subtask is the wrong shape entirely: it has no web UI, no boards, no assignees, and nothing to do with the Jira or Notion sense of the word subtask.
How Subtask works: tasks as folders, worktrees as isolation, subagents as workers
The flow starts with you talking to Claude Code. The README's example is a request to "fix the auth bug and add API metrics with Subtask". Claude Code then invokes the Skill, which drives the CLI. In the README's transcript you can see the shape of it: a `Skill(Subtask)` call, followed by `subtask draft fix/auth-bug` and `subtask draft feat/api-metrics`. The names look like branch names, and that is the point, because each task is backed by a worktree.
State lives on disk. The README states that "Tasks are persisted in folders", and the repository layout shows a `pkg/` and `internal/` split alongside `cmd/`, with `modernc.org/sqlite` in `go.mod`, so there is a SQLite dependency in the build. The README does not document the on-disk schema or where those folders sit, so treat the folder layout as something to inspect after install rather than something the documentation promises.
Statuses are visible through `subtask list`, which renders a table with columns for task, status and title. The example shows three states: `replied`, `working` and `draft`. A draft task has been created but has not started. That distinction matters because it means Claude can plan several tasks and then start them selectively. The README also states that Claude "gets notified when they're done", reviews the code, and then asks whether to merge or request changes. A terminal UI, launched by running `subtask` with no arguments, shows progress, diffs and conversations.
Installing Subtask and drafting your first task
The README lists several install paths. On Mac and Linux the quickest is the install script:
curl -fsSL https://subtask.dev/install.sh | bashWindows users get a PowerShell equivalent, and there are Homebrew, Go and prebuilt binary routes documented in the README. The Go route is:
go install github.com/zippoxer/subtask/cmd/subtask@latestInstalling the CLI is not enough. The Skill has to land in Claude Code's skill directory. The README recommends telling Claude Code to run the guided setup, which it says installs the skill at `~/.claude/skills` and asks whether subagents should run Claude, Codex or OpenCode:
subtask install --guideIf you prefer to do it without the guide, `subtask install` performs the install and `subtask uninstall` reverses it. There is an optional Claude Code plugin that, in the README's words, "reminds Claude to use the Subtask skill when it invokes the CLI":
/plugin marketplace add zippoxer/subtask
/plugin install subtask@subtaskWith that in place, the first real use is conversational. Ask Claude Code for something concrete and name Subtask, for example "fix the login bug with Subtask". Claude drafts the task, starts a subagent in a worktree, and you watch the table from `subtask list` or open the TUI by running `subtask`. The README does not show an expected output format for a successful draft beyond the task appearing in that table.
Where Subtask gets in your way
The README's own setup note is the first limitation: Subtask is in early development, and upcoming releases are expected to simplify installation, fix known bugs and improve how well Claude handles the tool. That is a candid statement, and it should shape how you use it. Do not put it on a critical path.
The second constraint is Git. Worktrees are a Git feature, so this design assumes a Git repository and a working directory that is one. Nothing in the README describes behaviour outside Git, and nothing describes what happens when a worktree cannot be created, for example because the branch name collides with an existing branch. There is also no documented rollback path for a task that has already spawned a subagent.
The third is the interface itself. Tasks are driven through a Skill and a CLI, not through a stable API contract. If you wanted to script Subtask from CI, the README gives you a CLI but no documented exit codes, no machine-readable output format and no versioned interface. The CLI is the product surface, and it is still moving.
Subtask compared with running worktrees by hand or with a task runner
The honest alternative is doing this yourself. `git worktree add` gives you the same isolation, and you can point an agent at each directory. What you lose is the bookkeeping: which task is in which worktree, which subagent is still working, which one is waiting on a reply from you, and what the diff looks like. Subtask's contribution is that layer, plus the ability for Claude to interrupt and talk with a subagent, which the README lists as a feature.
A second alternative is a conventional task tracker such as Jira, Notion or Asana. Those tools track human work items and their subtasks, and they have no relationship to Git worktrees or agent sessions. Choosing between them is not a close call: if the work is done by a person, use the tracker. If the work is done by a subagent in your repository, a tracker gives you a status field and nothing else.
A third comparison is against running one agent session at a time. That is simpler and has no install step, and for a single small change it is the right call. Subtask earns its place when you have several independent changes and the coordination overhead of juggling them by hand exceeds the cost of learning the tool.
Updates, licence and what maintenance looks like
Updating is built in. `subtask update --check` reports whether a newer release exists and `subtask update` applies it. The `go.mod` file includes `github.com/rhysd/go-github-selfupdate`, which is consistent with a self-update path, and `.goreleaser.yaml` at the repository root indicates releases are produced with GoReleaser. The most recent release listed is v0.2.0 from 2026-01-29, preceded by two betas earlier that month. The last push to the repository was on 2026-04-27, roughly five months before this writing, so the project is not archived but it is also not receiving daily commits.
Subtask is MIT licensed. In practical terms that permits commercial use, modification and redistribution provided the copyright notice and licence text are preserved. It does not grant trademark rights, and it comes with no warranty. That is a description of the licence text, not legal advice; if you are embedding the CLI in a product, have your own counsel read the LICENSE file.
The build targets Go 1.24.2 per `go.mod`. If you install from source rather than from a release binary, that is the toolchain floor you need.
Editorial conclusion
Adopt Subtask if you already drive Claude Code or Codex on a repository and you want several tasks in flight without branch collisions, and you accept that the README itself calls the project early development. Do not adopt it if you need a stable, documented interface for CI, or if you are not working inside Git. Before committing, verify two things yourself: that `subtask install` places the skill where your Claude Code build looks for skills, and that the subagent backend you pick (Claude, Codex or OpenCode) is the one your team is licensed to run.
Frequently asked questions
What does Subtask mean in this project?
In zippoxer/subtask, a subtask is a unit of work with its own Git worktree and its own subagent, created by Claude Code through the Subtask Skill and tracked with commands such as subtask list. It is unrelated to the subtask concept in Jira, Notion or Asana.
What is an example of a Subtask task?
The README gives the example prompt "fix the auth bug and add API metrics with Subtask", which produces two tasks, fix/auth-bug and feat/api-metrics, each drafted with its own subtask draft command and run in parallel.
How do you add a Subtask task to a project?
You talk to Claude Code and name Subtask in the request. Claude invokes the Skill and drafts the task through the CLI, and the task then appears in the subtask list table with a status such as draft, working or replied.
Community notes