splitting-storieslisted

# Splitting Stories A feature or task that is too big does not get smaller by being given a smaller estimate — it gets smaller by being **split into independently valuable pieces**. The default failure mode for an LLM orchestrator is to split horizontally (UI / API / DB as separate stories), which produces tasks that are technically smaller but none of which is independently demoable. This skill exists to force vertical slicing. The output is **a list of split candidates**, not opinions — concrete child stories/tasks each with a one-line user-observable outcome and the splitting pattern that produced it. ## When to Invoke | Caller | Trigger | |---|---| | `/ship-discuss` Phase 2 (Viability Gate) | When the SPLIT signal fires ("multiple stories in a trench coat") or BUILDABLE/SIZED fails on size grounds | | `/ship-discuss` Phase 1.5b challenge | When the user describes a feature whose acceptance criteria already exceed what fits in one sprint | | `/ship-sprint` Stage 3 (task decomposition) | When a behavior draft fails the "and" test or any of the 11 patterns fires | | `/ship-sprint` Stage 5 (effort) | When a task is estimated `effort: L` and the L-confirmation checklist is uncertain | | Manual / ad-hoc | When the user says "this feels too big" | Skip for trivial inputs (single AC, single touchpoint, S effort with one obvious Red step). The splitting overhead exceeds value. ## Inputs - `story_text` — the feature/task draft to split (markdown). May be a `/ship-discuss` dr