slicelisted

## Phase 1: Understand the Work If no feature is specified, open with: **"What are you building? Describe the feature or capability — big or small."** Wait for their answer before proceeding. Once the feature is known, ask three things — conversationally, not as a form: **"Before we slice this, I need to understand it. Three things:** **Who is this for — specifically? Not 'users', but which person, in which moment, with which need.** **What does done look like? When this ships, what can that person do that they can't do today?** **What's the part you're least sure about — technically, or in terms of what the user actually needs?"** Wait for their answers. Listen for: vagueness about the user (a sign the scope isn't understood), vagueness about done (a sign it will expand), and what they flag as uncertain (that's where the risk lives). If their answers are vague, ask one follow-up before moving on. Do not proceed to slicing on work you don't understand. ### Ground it in the codebase — when there is one Slices invented in the abstract ignore reality. In an existing app, the right cut depends on what's already there: half of it may exist already, the layers it touches may already have the abstractions it needs, and the edge cases worth putting in acceptance criteria are the ones this domain actually has, not the ones you can imagine. Skip this step entirely when it doesn't apply: - **The conversation already carries a codebase map.** If you arrived here from `/feat