vertical-slicing

$npx mdskill add tranhieutt/software_development_department/vertical-slicing

Plan fullstack features as end-to-end user-value slices.

  • Decompose PRDs into narrow, independently verifiable functional slices.
  • Uses Read, Glob, Grep, Write tools for planning and documentation.
  • Identifies smallest value unit and defines API contract before implementation.
  • Outputs a slice plan with contracts and implementation order.

SKILL.md

.github/skills/vertical-slicingView on GitHub ↗
---
name: vertical-slicing
type: workflow
description: "Guidelines and procedures for planning and implementing end-to-end functional slices for fullstack features."
user-invocable: true
allowed-tools: Read, Glob, Grep, Write
effort: 3
argument-hint: "[feature, epic, or PRD name]"
when_to_use: "Use when planning a fullstack feature that should be delivered as end-to-end user-value slices instead of separate backend and frontend layers."
---

# Skill: /vertical-slicing

Use this skill when planning complex fullstack features to ensure delivery by user-value units rather than technical layers.

Vertical slices should not merely cross layers. They should also protect depth:
keep complexity concentrated behind small interfaces instead of smearing logic
across DB, API, and UI callers.

## The Vertical Slicing Workflow

### 1. Identify the Smallest Value Unit
- Decompose the PRD into slices that represent a functional path.
- Example: Instead of "Authentication System," start with "Login with Email and Password".

Good slice shape:

- Narrow enough to demo or verify independently
- Complete enough to exercise the real seam end-to-end
- Small enough that one RED -> GREEN loop can prove meaningful progress
- Not a horizontal placeholder like "backend groundwork" unless that groundwork
  is a real prerequisite with its own verification

### 2. Define the Contract
- Before implementing, the `lead-programmer` or `backend-developer` must define the API contract.
- Document this in a Design Doc or temporary spec.

Prefer contracts that create deep modules: small interfaces with meaningful
behavior hidden behind them. If a contract mostly forwards data or mirrors
caller complexity, it is probably too shallow.

### 3. Plan the Slice Tasks
Organize each phase to contain:
- **Database/Data Model**: Schema changes required for this slice.
- **Backend Implementation**: Logic and API endpoints.
- **Frontend Integration**: UI components and API consumption.
- **E2E Verification**: Test verifying the whole path.

For each slice, also record:

- **Blocked by**: exact prerequisite slice(s) or `None`
- **Acceptance criteria**: observable end-to-end outcomes
- **Verification**: exact command/check for the slice
- **Interface risk**: where a shallow seam or pass-through wrapper could appear

### 4. Implementation Rules
- Do not confuse "deepest" with "lowest layer". Start where the slice creates
  the strongest behavior seam, then drive outward through the stack.
- Do not move to the next slice until the current one is "Integration Complete".
- If a horizontal change is absolutely necessary (e.g., shared middleware), implement it as a prerequisite phase 0.
- Apply the deletion test to new wrappers and adapters. If deleting the new
  abstraction would mostly simplify the code instead of reintroducing complexity
  across callers, the seam is too shallow.

## Benefits for Agents
- **Context Management**: Focusing on a slice keeps the context window filled with relevant code for that specific path.
- **Early Feedback**: The user can verify functional pieces earlier.
- **Reduced Integration Risk**: Cross-layer issues are caught within the slice implementation.
- **Better Architecture**: Tracer-bullet slices expose where interfaces are deep
  enough to keep leverage and where they are only moving complexity around.

More from tranhieutt/software_development_department

SkillDescription
agent-healthReads production/traces/agent-metrics.jsonl and displays a per-agent performance summary table for the current or a specified session. Highlights agents with high error rates or OPEN circuit breaker state.
agent-styleProvides the vendored agent-style v0.3.5 prose rule pack as a portable Claude skill. Use when installing, syncing, applying, or auditing SDD Agent-Style support in another project, or when a style-review workflow needs the bundled rules.
angular-best-practicesProvides Angular best practices for components, modules, services, and reactive patterns. Use when working with Angular TypeScript files, component templates, NgModules, RxJS observables, or when the user mentions Angular, ng, or Angular CLI.
annotateRecords unexpected API behaviors, undocumented caveats, version bugs, or non-obvious workarounds into .claude/memory/annotations.md. Use immediately when an undocumented behavior or surprising caveat is discovered during development.
aws-serverlessProvides AWS serverless architecture patterns for Lambda, API Gateway, DynamoDB, SQS, and SAM/CDK. Use when working with AWS serverless files (serverless.yml, CDK stacks) or when the user mentions Lambda, API Gateway, serverless, or AWS SAM.
backend-architectDesigns scalable backend architectures covering microservices, event-driven systems, API gateways, and data stores. Use when designing a backend system or when the user mentions backend architecture, scalability, or distributed systems.
cloud-run-puppeteerDeploys Puppeteer browser automation on Google Cloud Run with Docker. Use when running headless browser tasks on Cloud Run, or when the user mentions Cloud Run, Puppeteer, headless Chrome, or serverless browser automation.
codex-sddAdapts SDD for Codex while preserving Claude Code behavior. Use when working in Codex, setting up Codex compatibility, mapping Claude tools to Codex tools, or explaining how SDD should run outside Claude Code.
database-architectDesigns relational and NoSQL database schemas, indexing strategies, migration plans, and data modeling patterns. Use when designing a database or when the user mentions database architecture, schema design, or data modeling.
db-reviewReviews database schemas, queries, and migrations for correctness, performance, security, and best practices. Use when reviewing SQL migration files or when the user mentions database review, schema review, or query audit.