Vertical Slice

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

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

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:

• 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 syntax — # in GDScript (.gd) and Python, // in C#, C++ and JavaScript, -- in Lua, <!-- … --> in HTML and Markdown. A header in another language's syntax is a parse error, not a label. Files that cannot hold a comment (JSON, engine-generated scene and project files) are exempt.

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

• Follow architecture layers from docs/architecture/control-manifest.md
• Naming conventions — naming.* from project.yaml; for any key absent or empty (including when project.yaml has no naming block), 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 architectural assumption is wrong. Surface the blocker explicitly rather than continuing to iterate.

Conduct at least 1 playtest session once the loop is demonstrable.

Playtesting tip: If you can get anyone who hasn't seen the game to play it — a friend, family member, online community — watch them silently without explaining anything. Don't guide them. Their confusion reveals what the game isn't communicating on its own. This gives much better signal than self-testing.

No external testers available? Use rotation within the team: Dev A built system X, so Dev A is a naive tester for system Y. Even a two-person team can rotate effectively. Solo? Step away for 2-3 days then play through as a new player — you won't have perfect first-impression signal but you'll catch the critical blockers. Also try a "silent walkthrough": play your own slice in one sitting without stopping to fix anything and log every moment you hesitate.

Want richer observation data? Ask the tester to think aloud as they play — narrate what they're doing and why in real time. "I'm trying to figure out how to attack... I pressed E... nothing... is it click?" This surfaces confusion the instant it occurs rather than in retrospect. Best for onboarding and UI clarity validation. Silent observation is still better for feel testing; think-aloud changes the experience slightly but produces far more granular UX data.

Async remote option: Record a Loom or OBS session — give someone the build, ask them to record their screen + audio, and send you the video. You get genuine first-impression data without synchronous scheduling. Works across timezones.

Testing AI, NPC, or complex system behavior before it's fully implemented? Use the Wizard of Oz technique: one person plays normally while a second person secretly controls the NPC or system behavior in real time. The player believes it's automated. This validates the design intent of an AI or economy system before the implementation is complete — and reveals exactly what behaviors the system must produce to feel correct. Particularly useful for vertical slices where an AI system is in scope but not yet polished enough for unguided testing.

Phase 5: Playtest Debrief

The loop is demonstrable. Before writing the report, collect structured observations from actually playing it. Do NOT skip to report generation — the report is only as good as the observations you capture here.

Say exactly this:

"Play through the complete [start → challenge → resolution] cycle from scratch, as if you're a new player with no knowledge of how it was built. Don't skip ahead or use developer shortcuts. Come back when you've completed the full loop — or when you've hit something that stopped you."

Once the user returns, ask these questions one at a time:

1. Loop completion:

   "Did you complete the full [start → challenge → resolution] cycle on your own, without needing any guidance from me or prior knowledge of the build?"

2. Time check:

   "How long did it take to reach the first meaningful action — the first moment where you felt like you were actually playing the game?"

3. Core fantasy:

   "The game is supposed to make you feel [core fantasy from game-concept.md or game-brief.md]. Did it? Be honest — not 'kind of' but specifically what you felt and when."

4. Blockers:

   "What stopped you, confused you, or pulled you out of the experience? Any moment where you weren't sure what to do, or where something broke?"

5. Pipeline check:

   "As the developer — not the player — does this feel achievable at this quality for the full game? What surprised you about how long things took to build?"

6. Verdict:

   "PROCEED, PIVOT, or KILL — and the specific reason."

If any answer is vague, ask: "Can you give me the specific moment where that happened?" Precise observations populate the report. Vague ones produce a useless report.

PROCEED is not available when a validation item is NO. /gate-check production FAILs a built slice with any NO in its Vertical Slice Validation — a player got through the loop without developer guidance (question 1), learned what to do within the first 2 minutes (question 2 — longer is a no), the core mechanic feels good (question 3), no critical fun-blocker bug (question 4). If any of those answers is no, the verdict is PIVOT or KILL — the user chooses — and the report names the NO.

NOT ASSESSED is the fourth verdict. When nobody has yet played the complete loop from scratch — the user cannot play it this session, or stopped before the end — the validation did not run, and the verdict is NOT ASSESSED, with the reason. It ranks above PROCEED and below PIVOT and KILL: an unplayed slice has not earned PROCEED, and a slice known to fail is more actionable than one nobody played. It is never recorded as PROCEED.