plan-to-sliceslisted

Read `PROJECT_BRIEF.md` and produce `SLICES.md` — an ordered sequence of vertical, demoable slices, each with acceptance criteria a dev can turn into tests If there's no brief, tell the user to run `define-project` first. Slicing without a brief just ships the ambiguity forward into dev turns ## Process 1. **Read the brief.** Scope, MVP, technical approach, risks 2. **Explore the codebase** if one exists. Module boundaries, test patterns, what's already there. Slices land where seams already exist 3. **Identify vertical slices.** Slice 1 is the thinnest end-to-end path that proves the core approach 4. **Order by dependency and risk.** Uncertain integrations push forward so you learn early. User-facing value before internal polish. Clearly label dependencies so independent slices can run in parallel 5. **Write acceptance criteria** — 3–5 observable outcomes per slice ## Slicing rules - Every slice is vertical. No "set up the database" slice unless the project is pure infra. A horizontal slice can't be demoed, so you lose the feedback that makes slicing valuable - O11y lives inside the slice that introduces the behavior - Sizes within an order of magnitude. If one slice is 10x the others, split it; if one is 1/10th, fold it in. Agents complete well-sized vertical slices strongly — don't over-fragment out of caution ## Acceptance criteria Observable and verifiable. "POST /users returns 201 with user ID" — not "user creation works." Scoped to this slice; don't duplicate cr