/vertical-slice

name: vertical-slice
description: "Pre-Production validation — build a production-quality end-to-end build to confirm the full game loop is achievable before committing to Production. Run after GDDs, architecture, and UX specs are complete. Produces a PROCEED/PIVOT/KILL verdict that gates the Pre-Production → Production transition."
argument-hint: "[--review full|lean|solo]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion
model: sonnet
agent: prototyper
isolation: worktree

Purpose

The **vertical slice** answers a different question from the concept prototype: *"Can we build this full game loop at production quality, on schedule?"*

**Default use** — run late in Pre-Production, after GDDs, architecture, and UX specs are complete. It is a near-production-quality build demonstrating one complete [start → challenge → resolution] cycle.

**Post-pivot?** If a PIVOT verdict from an earlier vertical slice sent you back to revise GDDs and architecture, run this again after revisions to re-validate. It can be run as many times as needed until a PROCEED or KILL verdict is reached.

It validates:

1. The pipeline (can the team actually produce this quality of content?) 2. Execution feasibility (are the architecture decisions correct for this game?) 3. Fun survival (does the fun from the concept prototype survive full design?) 4. **Velocity** (how long did this take? That's your real production rate estimate.)

**Earlier in the project?** If you haven't written GDDs yet and want to validate whether the core idea is worth designing, run `/prototype` (concept prototype) instead.

---

Phase 1: Resolve Review Mode and Load Context

Resolve the review mode: 1. If `--review [full|lean|solo]` was passed → use that 2. Else read `production/review-mode.txt` → use that value 3. Else → default to `lean`

See `.claude/docs/director-gates.md` for the full check pattern.

Read the following files to understand the full design intent:

• `CLAUDE.md` — tech stack and engine
• `design/gdd/game-concept.md` — core fantasy and game pillars
• `design/gdd/systems-index.md` — MVP systems and their priorities
• `docs/architecture/architecture.md` — layer structure
• `docs/architecture/control-manifest.md` — technical rules for implementation
• Key GDDs for the systems being sliced

---

Phase 2: Define the Slice Scope and Validation Question

Before building, define the **falsifiable validation question**:

> *"Does a player, starting from nothing, experience [core fantasy from game-concept.md] > within [N] minutes, without developer guidance — and can we build one such loop > in [X] days at representative quality?"*

Both parts matter: player experience AND build feasibility.

**Scope discipline:**

• Include ALL core loop systems (minimum). If a system is required to complete one

[start → challenge → resolution] cycle, it must be in the slice.

• **Target scope: 3–5 minutes of polished, continuous gameplay.** This is the

industry-standard vertical slice length — long enough to demonstrate mechanics and tone, short enough to build at representative quality. If your slice would take longer than 5 minutes to play through, cut content, not quality.

• **Cut scope before cutting quality.** A low-quality slice that looks nothing like

the intended game cannot validate production feasibility.

• If the scope feels too large to build in 1–3 weeks, the slice scope is wrong —

not too big to build, but the slice is trying to prove too much at once.

**Scope creep warning:** The vertical slice is the highest-risk moment for scope creep in the pre-production phase. Features feel "almost there" and it's tempting to add "just one more system." Resist this. Cut, do not extend.

Present scope to the user before building and get confirmation.

---

Phase 3: Plan the Build

Define in bullet points:

• Systems implemented (which GDD sections are being exercised)
• The complete game loop cycle ([start] → [challenge] → [resolution] exactly)
• Art and audio quality level (placeholder acceptable, representative preferred)
• Specific, measurable success criteria for the validation question
• Hard time limit: [X] days. If exceeded, scope was wrong — stop and reassess.

Ask the user to confirm scope before building.

Once confirmed, write a session checkpoint to `production/session-state/active.md` (create `production/session-state/` if it does not exist). Include: concept name, validation question, systems in scope, art quality level, and current phase ("Phase 4 — Implement"). Update this file at the end of each build day with what was completed. This is the primary recovery mechanism if the session ends mid-slice — multi-week Engine builds will span many sessions.

---

Phase 4: Implement

Ask: "May I create the vertical slice directory at `prototypes/[concept-name]-vertical-slice/` and begin implementation?"

If yes, create the directory. Every file must begin with:

// VERTICAL SLICE - NOT FOR PRODUCTION
// Validation Question: [What this build is proving]
// Date: [Current date]

**Quality standards** — higher than concept prototype, not full production:

• Follow architecture layers from `docs/architecture/control-manifest.md`
• Naming conventions from `.claude/docs/technical-preferences.md`
• No hardcoded gameplay values — use constants or config files
• Basic error handling on critical paths
• Placeholder art acceptable; representative art preferred

**Multi-turn loop:** After writing the initial files, ask the user to run the build and report what they observe. Iterate until the complete game loop cycle is demonstrable. Each round: 1. User runs → reports errors or observations 2. Agent fixes errors or adjusts systems 3. Repeat until the full [start → challenge → resolution] cycle is playable

**Sunk cost checkpoint (day 3 of planned timeline):** If the full game loop cycle is not yet demonstrable, stop and reassess. Either the scope is too large or an arch