story-splitting-for-deliverylisted

# Story Splitting for Delivery (Progressive Admission) ## Core idea This is the primary story-splitting skill. Build the end-to-end path first, fully closed. Then admit one safe case at a time. Everything not yet admitted stays rejected — invalid, unsupported, or not implemented. Each admission is a thin, testable, demonstrable, ideally deployable story. This is related to walking skeleton / tracer bullet thinking, but the distinctive move is **default-deny with progressive widening**. ## When this skill fits Use it as the default whenever work is too big for one iteration or needs a delivery sequence. Progressive admission is especially natural when there is a clear cycle: - message queue / event processing - HTTP operations or API handlers - batch file / import processing - form fields and validation - UI controls that enable one action after another - schema or protocol versioning over time - multi-path user journeys, roles, channels, or rule variants If the admission boundary is not obvious, invent one from the variations in the work (paths, data shapes, rules, interfaces, roles). Do not fall back to component/task decomposition. Use `user-pov-sliced-stories` only when the main need is user-invoke / user-uses-result formatting. ## Target shape of each admission slice A good admission slice: - keeps the full end-to-end path wired - admits exactly one new case, shape, type, field set, or rule - continues to reject all non-admitted cases with a stable response - is unit