Vertical slice development mode for large features

[cangencler]

• I searched existing issues and this has not been proposed before

What problem does this solve?

When brainstorming a large feature (e.g., a self-improvement orchestrator, a plugin system, an auth overhaul), the current workflow produces a single monolithic spec → single monolithic plan → long execution chain. This creates several problems:

1. Integration risk concentrates at the end. All layers (data, logic, API, UI) get built before anything runs end-to-end.
2. Feedback arrives too late. The user (or stakeholders) can't interact with anything until the full plan is executed.
3. AI context window strain. Large plans push agents to their limits — the recent #1152 (5h token budget consumed in one run) is partly a symptom of plan size.
4. Pivot cost is high. Discovering a wrong assumption after executing 70% of a large plan is expensive.

Vertical slice development solves this by decomposing a large feature into ordered, independently shippable slices — each cutting through every layer of the system and delivering user-visible value.

Background: What is vertical slice development?

A vertical slice is a complete piece of functionality that cuts through every layer of the application — from UI to database — and delivers working, testable value in a single iteration. Instead of building all the infrastructure, then all the APIs, then all the UI ("horizontal layers"), you build one thin, complete feature at a time.

Key concepts from the literature:

• Walking Skeleton (Alistair Cockburn): The thinnest possible end-to-end implementation that links all major architectural components. It validates the architecture before expensive feature development. This is typically "slice zero."
• Elephant Carpaccio (Cockburn): A practice for learning to identify 15-20 slices where teams initially see 2-3.
• User Story Mapping (Jeff Patton): Visualize user activities horizontally, slice vertically to define releases.
• INVEST criteria: Each slice should be Independent, Negotiable, Valuable, Estimable, Small, Testable.
• Skeleton Architecture (InfoQ, 2026): Specifically designed for AI-assisted development — humans define immutable skeleton structures, AI generates feature implementations within those constraints.

The existing self-improvement plan (2026-04-15-self-improvement-vertical-slice.md) already demonstrates this thinking — it picks ONE rule and wires it through all 7 integration seams. The question is how to systematize this approach in the workflow.

Proposed solution

Introduce a Vertical Development Mode that activates for large features and decomposes them into ordered vertical slices, each of which flows through the existing plan → execute pipeline.

Where in the workflow?

After evaluating the current 7-phase brainstorming flow, the most natural insertion point is a two-touch approach:

Touch 1: Early signal during brainstorming (lightweight)

During the clarifying questions phase (Phase 2), when the system detects a large feature (multiple user journeys, multiple system layers, estimated >3 plan chunks), it asks:

"This looks like a substantial feature that touches multiple layers. Would you like to use vertical slice development to break it into independently shippable increments?"

This is just a flag-setting question — it doesn't change the brainstorming flow. The full feature still gets brainstormed, designed, and spec'd. But the system knows it will need to slice later.

Touch 2: Formal slicing after spec approval (the core)

After the spec is approved and before invoking writing-plans, a new Vertical Slicing Phase activates:

[Existing flow]
Phase 6: Spec Writing → user approves spec
  ↓
[NEW] Vertical Slicing Phase
  ↓
[Existing flow] 
Writing Plans (per slice) → Execution (per slice) → Ship

The Vertical Slicing Phase would:

1. Analyze the spec for natural slice boundaries using the nine splitting patterns from Humanizing Work:

   • Workflow steps
   • CRUD operations
   • Business rule variations
   • Data variations
   • Simple/Complex separation
   • Major effort isolation (infrastructure-heavy first slice vs. incremental additions)
   • Defer performance

2. Identify Slice 0 (Walking Skeleton): The thinnest end-to-end path that proves the architecture works. Must touch all integration points, but with minimal implementation.

3. Order subsequent slices by:

   • Dependency (what must exist before this can be built?)
   • User value (which delivers the most visible progress?)
   • Risk (which slice retires the most uncertainty?)

4. Present the slice plan to the user as an ordered list:

   Slice 0 (Walking Skeleton): Single hardcoded rule through all 7 seams
   Slice 1: Rule storage + CRUD
   Slice 2: Prompt assembly with dynamic rules
   Slice 3: User rating & feedback loop
   Slice 4: Cross-session learning
   

5. For each slice, offer two paths:

   • Direct to plan: Invoke writing-plans scoped to this slice's portion of the spec
   • Mini-brainstorm: For complex slices, run a lightweight brainstorming session (skip tool discovery and context building, reuse existing context, shorter clarifying phase)

6. After each slice ships, re-evaluate:

   • Are remaining slices still valid?
   • Has anything changed that requires re-slicing?
   • Can slices be merged or reordered?

State management

Add to state.json:

{
  "vertical_mode": true,
  "slices": [
    {
      "index": 0,
      "name": "walking-skeleton",
      "description": "Single hardcoded rule through all 7 seams",
      "status": "completed|in-progress|pending",
      "plan_file": "plans/2026-04-15-self-improvement-slice-0.md",
      "spec_sections": ["3.1", "3.2", "3.7"]
    }
  ],
  "current_slice": 0
}

Agent dispatch for slicing

The slicing analysis could use:

• Claude (sonnet): Analyze spec for slice boundaries using splitting patterns
• Gemini: Independent slice proposal for cross-validation
• Synthesis (opus): Merge proposals, resolve conflicts, produce final slice order

Complexity heuristics for auto-suggesting vertical mode

The system could auto-suggest vertical mode when:

• Design phase produced >5 sections
• Spec exceeds ~2000 words
• Multiple distinct user journeys identified
• Multiple system layers (data, API, UI, infra) are affected
• Estimated plan would have >4 chunks

What alternatives did you consider?

Alt 1: Vertical mode from session start

Make it a brainstorming session type (like profile selection). The entire brainstorm would be slice-oriented from Phase 0.

Rejected because: You need the full picture before you can slice well. Premature slicing leads to suboptimal boundaries. The current flow (brainstorm full → spec full → then slice) produces better slices because the design is complete.

Alt 2: Vertical slicing only inside writing-plans

Don't add a new phase — just make writing-plans smarter about organizing chunks as vertical slices.

Rejected because: writing-plans operates at the task/step level, not at the feature/value level. Vertical slicing is a higher-level decomposition that should produce multiple plans, not a single plan with vertical-ish task ordering.

Alt 3: Manual slicing by the user

Just let users manually break their spec into pieces and run separate brainstorming sessions for each.

Rejected because: Users already do this ad-hoc, but it loses context between sessions, doesn't carry over design decisions, and requires the user to do the hard work of identifying good slice boundaries.

Is this appropriate for core Superpowers?

Yes. This directly addresses the scalability of the brainstorming workflow for real-world features, reduces AI context window pressure, and aligns with the broader industry movement toward vertical slice development in AI-assisted workflows.

Context

• The self-improvement plan (2026-04-15-self-improvement-vertical-slice.md) is a manual example of vertical slicing — it picks one rule and wires it through all seams. This proposal would systematize that approach.
• Issue #1152 (token budget exhaustion) is partly caused by oversized plans that could be decomposed into smaller vertical slices.
• Addy Osmani's 2026 AI coding workflow advocates exactly this pattern: "brainstorm detailed spec → break into vertical slices small enough for AI context window → implement sequentially."
• The Skeleton Architecture approach (InfoQ, 2026) provides a complementary pattern for AI-assisted vertical slicing — humans own the skeleton (interfaces, base classes), AI implements the tissue (feature logic) within each slice.

References

• Humanizing Work Guide to Splitting User Stories — nine splitting patterns
• Walking Skeleton — Alistair Cockburn — slice zero concept
• Vertical Slice Architecture — Jimmy Bogard — code organization by feature
• Skeleton Architecture for AI — InfoQ — AI-specific vertical slicing
• Addy Osmani's AI Coding Workflow 2026 — spec → slice → implement loop
• Elephant Carpaccio — Alistair Cockburn — thin slicing practice

[cangencler]

Opened in wrong repo by mistake, sorry!