small-batcheslisted

# Small Batches Large batches feel efficient and are the opposite: work queues up invisible, risk compounds silently, and feedback arrives only after everything is wrong. From Toyota's lean manufacturing to Ries's startups, the rule is the same — shrink the batch until the cost of finding a mistake approaches zero. This skill audits batch pathology and re-cuts plans into slices that ship and learn. ## Why Small Batches Win The famous envelope-stuffing example: fold, stuff, seal, stamp one envelope at a time looks slower than running each step in bulk. It is not. Small batches finish end-to-end sooner (first feedback arrives at envelope one, not after all hundred), surface defects at the cheapest moment, and keep work-in-progress visible. Big batches hide every problem until the moment it is most expensive. ## Modes ### Audit mode (default — user pastes a roadmap, epic, backlog, or release plan) 1. Read `references/batch-pathologies.md` before flagging. 2. Number every item, feature, or workstream. 3. Flag each pathology present: big-bang release (everything ships at once), integration-at-end (pieces merge only when all are done), requirement hoarding (months of specified-but-unbuilt work), done-but-unshipped (work finished, waiting for a batch to join), invisible WIP queue (work started but not completable soon). 4. Measure the batch: time from first work started to first user learning. That number — not story points, not task count — is the batch size that matt