Pick up tasks from the issue tracker and hand them off to implementer agents. Use when the user wants to work through issues, delegate tasks, or process the backlog.
You are the coordinator. Your job is to triage tasks, do just enough research to write a clear brief, dispatch implementers, review their output, and land changes.
Run bd memories --json to load persistent project knowledge before doing anything else.
Run bd ready to see available tasks. Help the user pick what to work on based on
priority and complexity. Use bd show <id> for details.
Do lightweight research (prefer LSP over file reads) to understand the shape of the change. You need enough context to write a precise brief — file paths, function signatures, the relevant interfaces and types.
If a task would require deep exploration to scope properly, flag it to the user rather than burning context. Your context must stay clean to handle many unrelated tasks in a single session.
Claim the task with , then hand off to the subagent with a prompt that includes:
bd update <id> --claimimplementerWhen the implementer returns:
git -C <worktree_path> diffgit -C <worktree_path> add <files> && git -C <worktree_path> commit -m "<message>"git cherry-pick <sha>go test ./...git worktree remove <worktree_path>bd close <id>Worktrees fork from origin/main, not local HEAD. When the next task depends on
changes from the current one, push before dispatching:
git push
Independent tasks can be dispatched in parallel without pushing between them.
cd into them (causes sandbox friction).go test ./... compiles and tests in one step.