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.