By name: multitask
description: "Run several tickets to draft PRs at the same time, one isolated worker per ticket. Use when the user passes multiple tickets and wants them worked in parallel. Composes task-to-pr per ticket; never writes code itself."
user-invocable: true
argument-hint: " e.g. LIN-101, LIN-102, LIN-103"
Multitask
Turn a list of tickets into draft PRs in parallel. You are the coordinator: partition the work, run one worker per lane, report the fleet. You never write code yourself.
Workflow
- Classify independence first. Read each ticket and the code it touches. Tickets that share files, schema, or behavioral assumptions overlap: group them into one sequential lane. Truly independent tickets get their own lanes. If most of the tickets overlap, say so and run them sequentially; parallelism is not worth the coordination cost.
- Isolate each lane: its own worktree, its own branch, one full-session worker. Use the harness's mechanism for parallel workers (subagents, worker threads); when none exists, run the lanes one after another and say so.
- Each worker runs
task-to-prfor its ticket, end to end. - Monitor. When a lane fails or its outcome changes shared assumptions, stop the lanes that depend on it and report; don't let workers build on a broken premise. Report failures, don't silently retry them.
- Report the fleet: every ticket with its branch, PR URL, and status, including stopped and blocked lanes. Clean up worktrees whose PRs are open.
Rules
- Cap parallel lanes around five. The bottleneck is human review of the resulting PRs, not the workers.
- Never merge, rebase, or cherry-pick between lanes. One ticket, one branch, one PR.
- The coordinator never edits code. Fixes happen inside the lane's worker.
- A failed lane is reported, not quietly absorbed into another lane.