/vertical-slice

name: vertical-slice
description: "Pre-production validation — end-to-end build to confirm the full loop is achievable before committing to Production. After GDDs, architecture, UX specs."
argument-hint: "[--review full|lean|solo]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(bash "*/.claude/skills/vertical-slice/../../hooks/yaml-helper.sh" resolve_config *)
model: sonnet

!`bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation,workflow`

Resolved above — use as-is; `--review` overrides `review_mode` for this run. No block → defaults in `.claude/docs/config-resolution.md`.

Vertical Slice

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

See `.claude/docs/director-gates.md` for the full check pattern. Individual gate definitions live in `.claude/docs/director-gates/[gate-id].md` — the spawned agent reads its own gate file; do not read it in the parent session.

Every `AskUserQuestion` call follows `.claude/docs/automation-modes.md` (collaborative asks always · guided major-only · autonomous logs and proceeds; `automation_always_ask` categories always prompt).

Read the following files to understand the full design intent. Read each GDD, ADR and the control manifest by section: find the headings you need with the Grep tool (pattern `^#`, content mode) and Read those ranges with offset and limit.

• `CLAUDE.md` — tech stack and engine
• `design/gdd/game-concept.md` — core fantasy and game pillars (or

`design/game-brief.md`, the one-page brief that replaces it at `rigor: minimal` — pitch, core loop and "what they feel" line; it has no 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 or game-brief.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. Name the checkpoint file in that confirmation: "May I record this plan in `production/session-state/active.md`?"

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:

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

Write `[comment]` in each file's own comment sy