Vertical slice
Skill HM-IT-CODE/forge-skills/skills/engineering/vertical-slice
Battle-tested Claude Code skills for full-stack & systems engineers
npx -y skills add HM-IT-CODE/forge-skills --skill vertical-sliceAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Breaks a feature into thin, end-to-end vertical slices that each ship independently. Use when the user describes a large feature, says "where do I start", "break this down", "plan this feature", or is tempted to build layer-by-layer (all the DB, then all the API, then all the UI). Produces an ordered list of shippable slices.
SKILL.md
2.4 KB, as published. Nobody here has run it
Vertical Slice
Big features die in horizontal layers: you build the whole database, then the whole API, then the whole UI, and nothing works until the very end. Instead, cut vertical slices — each one goes through every layer and delivers a sliver of real, demonstrable value.
What a good slice is
A vertical slice is the thinnest possible change that is end-to-end and observable. It touches whatever layers it needs (storage → logic → interface) but does the minimum in each.
- Thin: does one concrete thing a user or caller can see.
- End-to-end: runs all the way through the system, even if hardcoded in places.
- Shippable: could be merged and deployed on its own without breaking anything.
- Ordered by value + risk: the first slice should retire the biggest unknown.
Method
- Restate the feature in one sentence as an outcome, not a component list.
- Find the walking skeleton — the smallest path that exercises every layer end-to-end, even with fake data. That's slice #1.
- Enumerate slices that each add one increment of real behavior on top. For each slice write:
- Title (imperative, user-facing where possible)
- Demo — the one sentence you'd say to show it works ("now an empty list returns
[]over HTTP") - Layers touched
- Explicitly out of scope for this slice
- Order them so the riskiest assumption is tested first and each slice leaves the system shippable.
- Stop and present the plan before writing code. Let the user approve or reorder.
Anti-patterns to refuse
- "First I'll build all the models." → No. That's a horizontal layer with no demo.
- A slice whose only demo is "the code compiles." → Not a slice; it's plumbing. Fold it into a slice that produces visible behavior.
- A slice that can't ship without three other slices. → Too thick or wrongly ordered.
Output
Deliver a numbered list of slices, each with title / demo / layers / out-of-scope, plus a one-line note on which unknown slice #1 retires. Then ask which slice to build first — and hand off to tdd-loop to build it.