vertical-slice-planning

jclfocused's avatarfrom jclfocused

Use this skill when discussing feature breakdown, PR structure, implementation ordering, or how to decompose work. Guides thinking about vertical slices (end-to-end functionality) rather than horizontal layers (all of one layer first). Triggers on "how should we break this down?", "what order should we implement?", "how many PRs?", or decomposition discussions.

⭐1stars🔀0forks📁View on GitHub🕐Updated Dec 23, 2025
[Project Management]

When & Why to Use This Skill

The Vertical Slice Planning skill optimizes software development by guiding the decomposition of complex features into thin, end-to-end functional slices. This approach prioritizes shippable progress and continuous integration over traditional horizontal layering, helping teams deliver user value faster, reduce integration risks, and maintain a stable codebase throughout the development lifecycle.

Use Cases

  • Feature Decomposition: Breaking down a high-level feature into independent sub-tasks that deliver complete end-to-end functionality rather than isolated technical layers.
  • PR Strategy Planning: Organizing a complex implementation into a logical sequence of Pull Requests that keep the codebase functional and easy to review at every step.
  • Agile Workflow Optimization: Helping development teams move away from 'infrastructure-first' bottlenecks toward a 'user-action-first' delivery model to accelerate feedback loops.
  • MVP Scoping: Identifying the thinnest possible version of a feature to minimize initial development time while still providing a testable and valuable user experience.
namevertical-slice-planning
descriptionUse this skill when discussing feature breakdown, PR structure, implementation ordering, or how to decompose work. Guides thinking about vertical slices (end-to-end functionality) rather than horizontal layers (all of one layer first). Triggers on "how should we break this down?", "what order should we implement?", "how many PRs?", or decomposition discussions.

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:

  1. Build all database models
  2. Build all API endpoints
  3. Build all UI components
  4. Wire everything together

Problems: Nothing works until everything is done, late integration issues, hard to show progress.

Vertical Approach (Prefer)

Building thin, complete features:

  1. User can view empty product list (UI → API → DB)
  2. User can add a product (UI → API → DB)
  3. 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

  1. What's the first thing a user should be able to do? → First slice
  2. What's the simplest version of this action? → Strip nice-to-haves
  3. What do we need to learn before building more? → Early slices
  4. 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.