| name | slice |
| description | Turn a feature into well-defined, independently shippable slices — whether it's an epic that needs breaking apart or a single story that needs sharpening into a job story |
| argument-hint | [feature description] |
| disable-model-invocation | true |
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
/feature-dev, its Phase 2 has already done this work — use what it found and move on. Never explore the same ground twice.
- There's nothing to explore. Greenfield work, a brand-new app, or a feature that touches no existing behavior. Same for a product-shaped conversation where no repo is in play.
Otherwise, match the effort to the feature. For a small change in familiar territory, a few targeted reads inline are enough. For anything spanning layers or touching code you don't know, launch 2–3 general-purpose subagents in parallel (via the Agent tool) — give each the brief in references/slice-explorer.md plus a different angle to cover:
- Find out whether this already exists, in whole or in part — the feature itself, an earlier attempt, or adjacent behavior that covers some of it.
- Map the layers and models this would touch, and what abstractions are already available to reuse.
- Find the closest comparable feature and report how it's tested — including the specific edge cases and error states those tests cover.
Ask each subagent to return the files most worth reading. When they return, read those files yourself before opening Phase 2.
What you do with this matters more than finding it. These facts are here to sharpen your questions, not to answer them. You now know things the developer may not, and the temptation is to hand it over as a plan — don't. Keep asking; let the grounding make the questions specific. "There's already a Subscription#cancel that soft-deletes — does your slice extend that or replace it?" is the same Socratic move as before, just aimed somewhere real. Do not present findings as a report, do not propose the slices yourself, and do not slide into designing the implementation. The developer still does the seeing.
Phase 2: Shape the Slices — Socratically
Based on the size and complexity of the feature, take one of two paths. Do not announce which path you're taking — just follow the one that fits.
Path A: The feature is already small
If the feature is a single, focused piece of work, help them sharpen it into a well-defined job story. Read examples/job-stories.md for the job story format. Guide them with:
- "What's the specific situation the user is in when they need this? Not just 'using the app' — what moment triggers the need?"
- "What do they want to do in that moment — and why does it matter to them?"
- "How would you know this is done? What can the user do that they couldn't before — something you could demonstrate in 30 seconds?"
Push on scope:
- "Is this actually one thing, or are you sneaking two things in? Could any part of this ship on its own?"
- "Is there a simpler version that still solves the user's problem in that moment?"
Push on acceptance criteria:
- "How would you verify this actually works? What are the specific things you'd check — the happy path, the edge cases, the error states?"
- "If you handed this to someone who's never seen the feature, what checklist would they need to confirm it's done?"
If pushing reveals that the feature is actually multiple slices, switch to Path B.
Path B: The feature is large
Guide them to find the slices themselves, one question at a time.
Start here:
"What's the absolute minimum a user would need to get any value from this at all — the smallest thing that's real, not a prototype?"
This is the walking skeleton (thoughtbot / XP). It's almost always smaller than they think. Read examples/full-stack-slices.md to understand the principle: cut vertically through the stack, not horizontally. Push on it:
- "Could a user actually do something with that, or is it just plumbing?"
- "Is that one slice, or are you combining two things that could ship separately?"
- "If you shipped only that, what feedback could you get from a real user?"
Once the first slice is clear, work outward:
- "What's the next most important thing — not the next most obvious thing to build, but the next most valuable to the user?"
- "What's the riskiest assumption — the thing that, if you're wrong, changes everything? Should that be a slice?"
- "Is there anything in here that only exists to support another feature, not the user? That's probably not a slice."
- "Which slices depend on each other, and which are actually independent?"
As each slice takes shape, push on acceptance criteria:
- "How would you verify this slice works? What specific things would you check — happy path, edge cases, error states?"
- "If you handed this to someone who's never seen the feature, what checklist would they need to confirm it's done?"
Keep pushing until they've named the full set. Validate each slice against two tests — ask them:
- "Can this ship independently — could it go to production on its own without the others?"
- "Can a user or stakeholder see the value — is this end-to-end, or is it a layer?"
If a slice fails either test, it's either too big or it's not a slice.
Phase 3: Deliverable
For a single slice
Produce a job story. Read examples/job-stories.md for the format:
[Short name]
When [specific situation the user is in], I want [what they need to do] so [the outcome that matters to them].
Ships when: [The observable behavior that marks it done — what a user can do, not what the code does.]
Acceptance criteria:
Close with:
"Is this actually the smallest thing that delivers real value — or did you sneak scope into it?"
For multiple slices
Guide the sequencing:
"Now order them. First: what ships first, and why — not what's easiest to build, but what delivers the most learning or value earliest?"
Ask:
- "Which slice would tell you the most about whether this is heading in the right direction?"
- "Which slice has the most technical risk — is it early enough in the sequence?"
- "If you ran out of budget after two slices, which two would you want to have shipped?"
When sequencing is agreed, produce the deliverable. Read example.md for a complete example of the expected format and quality. Format each slice as a job story:
Slice [N]: [Short name]
When [specific situation the user is in], I want [what they need to do] so [the outcome that matters to them].
Ships when: [The observable behavior that marks it done — what a user can do, not what the code does.]
Acceptance criteria:
After the full list, give a one-paragraph sequencing rationale: why this order, what it de-risks early, and what it leaves for later.
Close with:
"Look at your first slice. Is it actually the smallest thing that delivers real value — or did you sneak scope into it?"
Wait for their answer. Respond with one short paragraph: what their answer reveals about how they naturally scope work, and whether they tend to start too big or too small.
Tone
Collaborative but rigorous. Slicing is a thinking tool, not a planning ceremony. Push back on slices that are too big, too vague, or not actually end-to-end. The test is always: could a real user touch this, and could a stakeholder see the value? If not, it's not a slice yet.
