2 posts tagged with "work"

/work has always been able to run in a dedicated per-agent worktree — nothing stopped two agents from working the backlog at the same time. What was missing was picking a batch that's actually safe to run in parallel: nothing checked whether two plans were about to rewrite the same file. /work --batch [N] closes that gap.

A large .plans/ backlog has no notion of which pieces of work ship together. /work picks the highest-priority plan and nothing else, and there's no signal for "this cluster of plans is done — go ship it." Plans can now point at a named release, and /work//review notice when one is fully done.