jclfocused Vertical Slice Planning Skill
This skill guides the decomposition of features into vertical slices - thin, end-to-end pieces of functionality that can be shipped independently.
When to Use
Apply this skill when:
- Breaking down a feature into sub-issues
- Deciding implementation order for a feature
- Planning PR structure for a feature
- Users ask "how should we break this down?"
- Discussing what to build first
- Reviewing feature decomposition plans
What is a Vertical Slice?
A vertical slice cuts through ALL layers of the application to deliver a thin piece of complete functionality.
┌─────────────────────────────────────────┐
│ HORIZONTAL LAYERS │
├─────────────────────────────────────────┤
│ UI Layer │ █ │ │ │ │
├────────────────┼───┼─────┼─────┼────────┤
│ API Layer │ █ │ │ │ │
├────────────────┼───┼─────┼─────┼────────┤
│ Service Layer │ █ │ │ │ │
├────────────────┼───┼─────┼─────┼────────┤
│ Data Layer │ █ │ │ │ │
└────────────────┴───┴─────┴─────┴────────┘
↑
Vertical Slice
(Complete feature)
Vertical vs Horizontal
Horizontal Approach (Avoid)
Building all of one layer before moving to the next:
- Build all database models
- Build all API endpoints
- Build all UI components
- Wire everything together
Problems: Nothing works until everything is done, late integration issues, hard to show progress.
Vertical Approach (Prefer)
Building thin, complete features:
- User can view empty product list (UI → API → DB)
- User can add a product (UI → API → DB)
- User can edit a product (UI → API → DB)
Benefits: Each slice is shippable, continuous integration, visible progress.
How to Identify Vertical Slices
1. Start with User Actions
What can the user DO? Each action is often a slice.
2. Find the Thinnest Version
For each action, what's the minimal implementation?
- Skip validation (add later)
- Skip edge cases (add later)
- Skip optimization (add later)
3. Order by Dependency
Which slices enable other slices?
- "View list" before "Filter list"
- "Create item" before "Edit item"
Slice Sizing Guidelines
| Size | Indicators |
|---|---|
| Too Big | Multiple user actions, >2 days work, many acceptance criteria |
| Too Small | Just infrastructure, just types, <1 hour work |
| Just Right | One capability, 1-2 days, 3-5 acceptance criteria |
Naming Convention for Issues
Use prefixes to show slice relationships:
SLICE 1: Basic product list display
SLICE 1.1: Add product image support
SLICE 2: Product search functionality
Questions to Guide Slicing
- What's the first thing a user should be able to do? → First slice
- What's the simplest version of this action? → Strip nice-to-haves
- What do we need to learn before building more? → Early slices
- If we had to ship tomorrow, what would we cut? → Later slices
Integration with Linear Workflow
When creating Linear issues:
- Parent issue = Full feature context
- Direct sub-issues = Vertical slices (potential PRs)
Each slice should be independently deployable, testable, and valuable.
Remember: Ship working software frequently. Slices make this possible.