# Vertical Slice Planning

> 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.

- Skill: `jclfocused/vertical-slice-planning` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add jclfocused/vertical-slice-planning`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jclfocused/vertical-slice-planning/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: jclfocused (https://skillmd.com/u/jclfocused)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/jclfocused/vertical-slice-planning

---


# 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.**