Back to Details

vertical-slice

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

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.
Vertical Slice（垂直切片） 要回答的问题与概念原型不同： “我们能否按计划构建出达到生产质量的完整游戏循环？”
默认使用场景 —— 在预生产阶段后期执行，需在GDD、架构和UX规格完成后进行。它是一个接近生产质量的版本，展示一个完整的[启动→挑战→解决]循环。
调整后复用？ 如果之前的Vertical Slice给出了PIVOT判定，让你返回修改GDD和架构，那么在修订完成后需再次执行本流程以重新验证。可根据需要多次执行，直到得出PROCEED或KILL判定。
它将验证以下内容：
  1. 流水线能力（团队是否真的能产出该质量的内容？）
  2. 执行可行性（针对这款游戏的架构决策是否正确？）
  3. 趣味性留存（概念原型中的趣味性在完整设计后是否依然存在？）
  4. 开发速度（构建这个版本花了多久？这就是你真实的生产速率预估。）
项目早期场景？ 如果你还未编写GDD，想验证核心创意是否值得设计，请改用
/prototype
（概念原型）流程。

Phase 1: Resolve Review Mode and Load Context

阶段1：确定评审模式并加载上下文

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
确定评审模式：
  1. 如果传入了
    --review [full|lean|solo]
    参数 → 使用该模式
  2. 否则读取
    production/review-mode.txt
    文件 → 使用其中的值
  3. 若以上都不满足 → 默认使用
    lean
    模式
完整的检查规则请查看
.claude/docs/director-gates.md
。
读取以下文件以理解完整的设计意图：
  • CLAUDE.md
    —— 技术栈与引擎
  • design/gdd/game-concept.md
    —— 核心幻想与游戏支柱
  • design/gdd/systems-index.md
    —— MVP（最小可行产品）系统及其优先级
  • docs/architecture/architecture.md
    —— 层级结构
  • docs/architecture/control-manifest.md
    —— 实现的技术规则
  • 与当前切片相关的关键GDD文档

Phase 2: Define the Slice Scope and Validation Question

阶段2：定义切片范围与验证问题

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.
在构建前，定义可证伪的验证问题：
“玩家从零开始，能否在[N]分钟内体验到[来自game-concept.md的核心幻想]，且无需开发者指导——同时我们能否在[X]天内构建出一个该质量的游戏循环？”
两个部分都很重要：玩家体验和构建可行性。
范围管控原则：
  • 必须包含所有核心循环系统（最低要求）。如果某个系统是完成[启动→挑战→解决]循环所必需的，就必须纳入切片范围。
  • 目标范围：3–5分钟的流畅、连续游戏体验。 这是行业标准的Vertical Slice时长——足够展示机制与基调，同时又短到能以代表性质量完成构建。如果你的切片游戏时长超过5分钟，请削减内容，而非降低质量。
  • 先缩范围，再降质量。 低质量的切片与预期游戏相差甚远，无法验证生产可行性。
  • 如果范围大到需要1–3周才能完成，说明切片范围设定有误——不是内容太多无法构建，而是切片试图一次性验证过多内容。
范围蔓延警告： Vertical Slice是预生产阶段范围蔓延风险最高的环节。功能看起来“差一点就完成”，很容易让人忍不住想“再加一个系统”。请抵制这种诱惑，要做减法，而非扩展。
在构建前向用户展示范围并获得确认。

Phase 3: Plan the Build

阶段3：规划构建

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.
用 bullet 点定义以下内容：
  • 要实现的系统（将用到哪些GDD章节）
  • 完整的游戏循环（明确[启动]→[挑战]→[解决]的流程）
  • 美术与音频质量等级（可使用占位资源，但优先使用代表性资源）
  • 验证问题的具体、可衡量成功标准
  • 硬性时间限制：[X]天。如果超时，说明范围设定有误——停止并重新评估。
在构建前请用户确认范围。
确认后，将会话检查点写入
production/session-state/active.md
（若
production/session-state/
目录不存在则创建）。内容包括：创意名称、验证问题、纳入范围的系统、美术质量等级、当前阶段（“阶段4——实现”）。每个构建日结束后更新该文件，记录已完成的工作。这是会话中途中断时的主要恢复机制——多周的引擎构建会跨越多个会话。

Phase 4: Implement

阶段4：实现

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 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.
询问：“我可以创建Vertical Slice目录
prototypes/[concept-name]-vertical-slice/
并开始实现吗？”
若得到许可，创建该目录。所有文件必须以以下内容开头：
// VERTICAL SLICE - NOT FOR PRODUCTION
// Validation Question: [本版本要验证的内容]
// Date: [当前日期]
质量标准 —— 高于概念原型，但未达到完整生产级：
  • 遵循
    docs/architecture/control-manifest.md
    中的架构层级
  • 遵循
    .claude/docs/technical-preferences.md
    中的命名规范
  • 游戏数值不得硬编码——使用常量或配置文件
  • 关键路径需具备基础错误处理
  • 可使用占位美术资源；优先使用代表性美术资源
多轮循环： 写完初始文件后，请用户运行版本并反馈观察结果。迭代直到完整游戏循环可演示。每一轮流程：
  1. 用户运行 → 报告错误或观察结果
  2. Agent修复错误或调整系统
  3. 重复直到完整的[启动→挑战→解决]循环可玩
沉没成本检查点（计划时间线的第3天）： 如果此时仍无法演示完整游戏循环，请停止并重新评估。要么是范围太大，要么是架构假设错误。请明确指出障碍，而非继续迭代。
循环可演示后，至少开展1次游戏测试会话。
游戏测试技巧： 如果能找到没见过这款游戏的人来测试——朋友、家人、在线社区成员——请安静观察，不要解释任何内容，不要指导他们。他们的困惑之处就是游戏自身未传达清楚的地方。这比自我测试的信号更有效。
没有外部测试人员可用？ 在团队内部轮换：开发者A构建了系统X，那么开发者A可以作为系统Y的“小白”测试员。即使是两人团队也能有效轮换。单人开发？请离开2-3天，然后以新玩家的身份体验——你无法获得完美的第一印象信号，但能发现关键障碍。也可以尝试“静默通关”：一次性玩完自己的切片，中途不停止修复问题，记录每一个犹豫的瞬间。
想要更丰富的观察数据？ 请测试员在玩的时候出声思考——实时叙述他们正在做什么以及原因。“我在尝试搞清楚怎么攻击……我按了E……没反应……是不是点击？”这能在困惑产生的瞬间就发现问题，而非事后回忆。这种方式最适合验证新手引导和UI清晰度。静默观察更适合体验测试；出声思考会略微改变体验，但能产生更细致的UX数据。
异步远程选项： 使用Loom或OBS录制会话——给测试人员版本，让他们录制屏幕+音频，然后把视频发给你。你无需同步排期就能获得真实的第一印象数据，适用于跨时区场景。
在AI、NPC或复杂系统完全实现前测试其行为？ 使用**绿野仙踪（Wizard of Oz）**技术：一个人正常游玩，另一个人秘密实时控制NPC或系统行为。玩家会以为这是自动化的。这能在系统实现完成前验证AI或经济系统的设计意图——并明确系统需要产生哪些行为才能让体验合理。在Vertical Slice中尤其有用，当AI系统在范围内但还未打磨到可无引导测试的程度时。

Phase 5: Playtest Debrief

阶段5：游戏测试复盘

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]. 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.
循环已可演示。在撰写报告前，先通过实际游玩收集结构化观察结果。不要跳过这一步直接生成报告——报告的质量取决于你在此处收集的观察结果。
请准确说出：
“从头开始完整体验[启动→挑战→解决]循环，就像你是一个不知道版本如何构建的新玩家。不要跳过步骤或使用开发者快捷键。完成完整循环后再回来——或者遇到阻碍时就返回。”
用户返回后，逐个询问以下问题：
  1. 循环完成情况：
    “你是否在无需我指导或预先了解版本的情况下，独立完成了完整的[启动→挑战→解决]循环？”
  2. 时间检查：
    “你花了多久才进行第一次有意义的操作——也就是你觉得自己真正开始玩游戏的那一刻？”
  3. 核心幻想体验：
    “这款游戏本应让你感受到[来自game-concept.md的核心幻想]。你有这种感受吗？请诚实回答——不要说‘有点’，请具体说明你感受到了什么以及什么时候感受到的。”
  4. 障碍点：
    “是什么让你停滞、困惑或脱离了体验？有没有任何时刻你不确定该做什么，或者出现了故障？”
  5. 流水线检查：
    “作为开发者而非玩家，你觉得以这个质量完成整个游戏是否可行？构建过程中，哪些部分的耗时让你感到意外？”
  6. 判定结果：
    “PROCEED、PIVOT还是KILL——请给出具体原因。”
如果任何回答模糊不清，请询问：“你能告诉我具体是哪个时刻发生的吗？”精确的观察结果才能让报告有价值，模糊的回答只会生成无用的报告。

Phase 6: Generate Vertical Slice Report

阶段6：生成Vertical Slice报告

Track velocity throughout the build. Log:
  • Day 1: what was built
  • Day 2: what was built
  • etc.
This is the most honest data you will ever have about your production rate. Do not skip it. It feeds directly into sprint planning.
Read 
.claude/docs/templates/vertical-slice-report.md
to get the report structure. If the template file is not found, use this fallback structure:
  • ## Vertical Slice Report — [Game Title] — [Date]
  • ### Executive Summary
    (PROCEED / PIVOT / STOP verdict + 2-sentence rationale)
  • ### Core Loop Validation
    (what was tested, what passed, what failed)
  • ### Feel Assessment
    (animation, controls, feedback — subjective notes)
  • ### Technical Findings
    (performance, engine issues, architectural risks)
  • ### Velocity Log
    (day-by-day actual progress — do not skip)
  • ### Recommended Next Steps
Fill in every section based on what was observed and built during this session. The velocity log must reflect actual day-by-day progress, not estimates — this is the most honest production rate data you will ever have. Replace all placeholder text with real observations.
在构建全程跟踪开发速度。记录：
  • 第1天：完成的内容
  • 第2天：完成的内容
  • 以此类推
这是你能获得的最真实的生产速率数据。不要跳过这一步，它会直接用于迭代规划。
阅读
.claude/docs/templates/vertical-slice-report.md
获取报告结构。如果找不到模板文件，使用以下备用结构：
  • ## Vertical Slice报告 — [游戏名称] — [日期]
  • ### 执行摘要
    （PROCEED / PIVOT / STOP判定 + 2句话的理由）
  • ### 核心循环验证
    （测试了什么，通过了什么，失败了什么）
  • ### 体验评估
    （动画、操控、反馈——主观记录）
  • ### 技术发现
    （性能、引擎问题、架构风险）
  • ### 开发速度日志
    （逐日实际进度——请勿跳过）
  • ### 建议下一步行动
根据本次会话中观察到的内容和完成的工作填写每个部分。开发速度日志必须反映实际逐日进度，而非预估——这是你能获得的最真实的生产速率数据。将所有占位文本替换为真实观察结果。

Lessons Learned

经验总结

  • What assumptions were broken by actually building to near-production quality?
  • What surprised us about the pipeline or architecture?
  • What would we change about the slice scope if we ran this again?

Ask: "May I write this report to
`prototypes/[concept-name]-vertical-slice/REPORT.md`?"

If yes, write the file. Then update `prototypes/index.md` (create if it does not
exist) — append one row to the vertical slice table: concept name, date, verdict,
and a link to the REPORT.md. Note whether this was a first-run slice or a re-run
after a PIVOT. The velocity log in this report is some of the most valuable data in
the project — cross-reference it with sprint estimates.

---
  • 构建接近生产质量的版本后，哪些假设被打破了？
  • 流水线或架构的哪些方面让我们感到意外？
  • 如果再次执行这个流程，我们会如何调整切片范围？

询问：“我可以将这份报告写入`prototypes/[concept-name]-vertical-slice/REPORT.md`吗？”

若得到许可，写入该文件。然后更新`prototypes/index.md`（若不存在则创建）——在Vertical Slice表格中追加一行：创意名称、日期、判定结果，以及REPORT.md的链接。注明这是首次切片还是PIVOT后的重新切片。本报告中的开发速度日志是项目中最有价值的数据之一——请与迭代预估交叉参考。

---

Phase 7: Creative Director Review

阶段7：创意总监评审

Review mode check:
  • solo
    → skip. Note: "CD-PLAYTEST skipped — Solo mode."
  • lean
    → skip (not a PHASE-GATE). Note: "CD-PLAYTEST skipped — Lean mode."
  • full
    → spawn 
    creative-director
    via Task using gate CD-PLAYTEST (
    .claude/docs/director-gates.md
    ).
Pass: the full REPORT.md content, the validation question, game pillars and core fantasy from 
design/gdd/game-concept.md
.
The creative director evaluates the vertical slice result against the game's creative vision and pillars, then confirms, modifies, or overrides the recommendation. Their verdict is final. Update REPORT.md if the verdict differs.
评审模式检查：
  • solo
    → 跳过。记录：“CD-PLAYTEST已跳过——Solo模式。”
  • lean
    → 跳过（非阶段准入 gate）。记录：“CD-PLAYTEST已跳过——Lean模式。”
  • full
    → 通过Task调用
    creative-director
    ，使用准入 gate CD-PLAYTEST（
    .claude/docs/director-gates.md
    ）
传递以下内容：完整的REPORT.md内容、验证问题、来自
design/gdd/game-concept.md
的游戏支柱和核心幻想。
创意总监会根据游戏的创意愿景和支柱评估Vertical Slice结果，然后确认、修改或推翻之前的建议。他们的判定为最终结果。如果判定结果不同，请更新REPORT.md。

Phase 8: Summary and Next Steps

阶段8：总结与下一步行动

Output a summary: the validation question, velocity data, and final recommendation. Link to 
prototypes/[concept-name]-vertical-slice/REPORT.md
.
If PROCEED: Your vertical slice validated the full game loop. The project is ready for Production.
Recommended next steps:
  • /create-epics layer:foundation
    — plan Foundation layer epics
  • /create-epics layer:core
    — plan Core layer epics
  • /create-stories [epic-slug]
    — break each epic into implementable stories
  • /sprint-plan
    — plan the first sprint using velocity data from the slice
  • /gate-check pre-production
    — formally advance the stage to Production
Playtest note: 
/gate-check
will look for documented playtest evidence. At minimum, 1 documented session with a REPORT.md showing PROCEED is required to pass the gate. More sessions give more reliable signal — 3+ is recommended before committing the full team to Production, but is not a hard gate.
If PIVOT:
Before routing back to GDD revision, capture the carry-forward note. Ask these two questions (plain text, one at a time):
  1. "What systems or mechanics worked at this quality level and should be preserved in the revised design?"
  2. "What specifically failed — the core loop, the architecture, the pipeline, or the fun?"
Ask: "May I write this to 
prototypes/[concept-name]-vertical-slice/PIVOT-NOTE.md
?"
If yes, write the file with: what worked, what failed, the specific systems or architecture decisions that need revision, and what the next slice should prove differently. When 
/vertical-slice
is next run after a PIVOT, check the 
prototypes/
directory for a 
PIVOT-NOTE.md
— use it to frame the new validation question and inform scope decisions.
  • Revise affected GDDs with 
    /design-system [mechanic]
  • Address architecture issues via 
    /architecture-decision
  • Then re-run 
    /vertical-slice
    to validate the revised direction
If KILL:
Before abandoning the concept, confirm the verdict is sound:
  • Full game loop takes >5 minutes even for an experienced player?
  • No emotional high point (delight, surprise, satisfaction) observed in any playtest session?
  • 50%+ of testers confused or stuck at the same point after 2+ slice attempts?
  • Architecture issues would require rebuilding more than 50% of what was built?
  • This is the 3rd vertical slice attempt on the same concept?
If 2+ boxes apply → KILL verdict is sound. If 0–1 apply → one targeted PIVOT may recover the concept.
Document the kill in 
prototypes/GRAVEYARD.md
 (create if it doesn't exist). Ask: "May I append this to 
prototypes/GRAVEYARD.md
?" If yes, add one entry:
undefined
输出总结：验证问题、开发速度数据和最终建议。附上
prototypes/[concept-name]-vertical-slice/REPORT.md
的链接。
如果是PROCEED： 你的Vertical Slice验证了完整游戏循环。项目已准备进入Production（生产阶段）。
建议下一步行动：
  • /create-epics layer:foundation
    —— 规划基础层epic
  • /create-epics layer:core
    —— 规划核心层epic
  • /create-stories [epic-slug]
    —— 将每个epic拆解为可实现的用户故事
  • /sprint-plan
    —— 使用切片的开发速度数据规划第一个迭代
  • /gate-check pre-production
    —— 正式将阶段推进至Production
游戏测试注意事项： 
/gate-check
会查找已记录的游戏测试证据。至少需要1次有REPORT.md记录且判定为PROCEED的会话才能通过准入 gate。建议在让整个团队投入Production前开展3次以上的测试，但这并非硬性要求。
如果是PIVOT：
在返回修改GDD前，记录需保留的内容。逐个询问以下两个问题（纯文本）：
  1. “哪些系统或机制在该质量水平下表现良好，应在修订后的设计中保留？”
  2. “具体是什么失败了——核心循环、架构、流水线还是趣味性？”
询问：“我可以将这些内容写入
prototypes/[concept-name]-vertical-slice/PIVOT-NOTE.md
吗？”
若得到许可，写入该文件，内容包括：有效的部分、失败的部分、需要修订的具体系统或架构决策，以及下一次切片应验证的不同点。当PIVOT后再次执行
/vertical-slice
时，请检查
prototypes/
目录下的
PIVOT-NOTE.md
——用它来制定新的验证问题并指导范围决策。
  • 使用
    /design-system [mechanic]
    修订受影响的GDD
  • 通过
    /architecture-decision
    解决架构问题
  • 然后重新执行
    /vertical-slice
    验证修订后的方向
如果是KILL：
在放弃该创意前，确认判定结果是否合理：
  • 即使是经验丰富的玩家，完成完整游戏循环也需要超过5分钟？
  • 在任何游戏测试会话中都未观察到情绪高点（愉悦、惊喜、满足）？
  • 经过2次以上切片尝试后，仍有50%以上的测试人员在同一环节困惑或停滞？
  • 架构问题需要重写超过50%已完成的内容？
  • 这是同一创意的第3次Vertical Slice尝试？
如果满足2项及以上 → KILL判定合理。如果满足0–1项 → 一次针对性的PIVOT可能挽救该创意。
在
prototypes/GRAVEYARD.md
中记录终止信息（若不存在则创建）。询问：“我可以将这些内容追加到
prototypes/GRAVEYARD.md
吗？”若得到许可，添加一条记录：
undefined

[Concept Name] Vertical Slice — YYYY-MM-DD

[创意名称] Vertical Slice — YYYY-MM-DD

  • Kill reason: [what specifically prevented the player from experiencing the core fantasy]
  • What worked at slice quality: [systems or mechanics that held up]
  • What failed: [core loop issue, architecture decision, or pipeline blocker]
  • Next time: [one specific change for the next time a similar concept is attempted]

- Return to `/brainstorm` with what you learned
- Or run `/prototype [new-concept]` to test a new direction cheaply first

---
  • 终止原因： [具体是什么阻碍了玩家体验核心幻想]
  • 切片质量下有效的部分： [表现良好的系统或机制]
  • 失败的部分： [核心循环问题、架构决策或流水线障碍]
  • 下次改进： [下次尝试类似创意时的具体改进点]

- 带着学到的经验返回`/brainstorm`
- 或者先使用`/prototype [new-concept]`低成本测试新方向

---

Important Constraints

重要约束

  • Vertical slice code must NEVER be refactored into production — it is reference only
  • Production code must NEVER import from 
    prototypes/
  • If recommendation is PROCEED, production implementation is written from scratch using the slice as a design reference only
  • Scope cuts are acceptable; quality cuts are not — a low-quality slice proves nothing
  • Total effort: 1–3 weeks. If longer, scope is too large — cut the slice, not the quality.
  • Day 3 sunk cost rule: if the full game loop cycle is not demonstrable by then, stop and surface the blocker
  • Networked/multiplayer games: A local vertical slice cannot validate the feel of a networked mechanic. Latency fundamentally changes how combat, movement, and prediction feel — testing locally at 0ms will feel entirely different at 80ms network delay. The slice can validate that the game loop is interesting and complete; it cannot validate that networked mechanics feel good under real conditions. Network feel requires real peers or simulated latency.
  • Vertical Slice代码绝不能重构到生产环境中——仅作为参考
  • 生产代码绝不能从
    prototypes/
    目录导入
  • 如果建议是PROCEED，生产实现需从零开始编写，仅将切片作为设计参考
  • 可以削减范围，但不能降低质量——低质量的切片无法验证任何内容
  • 总耗时：1–3周。如果超过这个时间，说明范围太大——请缩小切片范围，而非降低质量
  • 第3天沉没成本规则：如果此时仍无法演示完整游戏循环，请停止并明确指出障碍
  • 联网/多人游戏： 本地Vertical Slice无法验证联网机制的体验。延迟会从根本上改变战斗、移动和预判的感受——在0ms延迟的本地测试与80ms网络延迟下的体验完全不同。切片可以验证游戏循环是否有趣且完整，但无法验证联网机制在真实条件下的体验是否良好。联网体验需要真实玩家或模拟延迟。