gate-check

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Phase Gate Validation

阶段门验证（Phase Gate Validation）

This skill validates whether the project is ready to advance to the next development phase. It checks for required artifacts, quality standards, and blockers.

Distinct from
/project-stage-detect
: That skill is diagnostic ("where are we?"). This skill is prescriptive ("are we ready to advance?" with a formal verdict).

此技能用于验证项目是否准备好进入下一开发阶段，检查所需交付物、质量标准以及阻碍因素。

与
/project-stage-detect
的区别：该技能是诊断性的（"我们当前处于哪个阶段？"），而本技能是指导性的（"我们是否准备好推进？"并给出正式判定结果）。

Production Stages (7)

生产阶段（共7个）

The project progresses through these stages:

Concept — Brainstorming, game concept document
Systems Design — Mapping systems, writing GDDs
Technical Setup — Engine config, architecture decisions
Pre-Production — Prototyping, vertical slice validation
Production — Feature development (Epic/Feature/Task tracking active)
Polish — Performance, playtesting, bug fixing
Release — Launch prep, certification

When a gate passes, write the new stage name to

production/stage.txt

(single line, e.g.

Production

). This updates the status line immediately.

项目会经历以下阶段：

Concept — 头脑风暴、游戏概念文档
Systems Design — 系统映射、撰写GDD（游戏设计文档）
Technical Setup — 引擎配置、架构决策
Pre-Production — 原型制作、垂直切片验证
Production — 功能开发（Epic/Feature/Task跟踪处于活跃状态）
Polish — 性能优化、游戏测试、Bug修复
Release — 发布准备、认证

当阶段门通过时，将新阶段名称写入

production/stage.txt

（单行，例如

Production

），这会立即更新状态行。

1. Parse Arguments

1. 参数解析

Target phase:

$ARGUMENTS[0]

(blank = auto-detect current stage, then validate next transition)

Also resolve the review mode (once, store for all gate spawns this run):

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

Note: in

solo

mode, director spawns (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE) are skipped — gate-check becomes artifact-existence checks only. In

lean

mode, all four directors still run (phase gates are the purpose of lean mode).

With argument:
```
/gate-check production
```
— validate readiness for that specific phase
No argument: Auto-detect current stage using the same heuristics as
```
/project-stage-detect
```
, then confirm with the user before running:
Use
```
AskUserQuestion
```
:
- Prompt: "Detected stage: [current stage]. Running gate for [Current] → [Next] transition. Is this correct?"
- Options:
  - ```
  [A] Yes — run this gate
```
- ```
[B] No — pick a different gate
```
    (if selected, show a second widget listing all gate options: Concept → Systems Design, Systems Design → Technical Setup, Technical Setup → Pre-Production, Pre-Production → Production, Production → Polish, Polish → Release)
Do not skip this confirmation step when no argument is provided.

目标阶段：

$ARGUMENTS[0]

（留空=自动检测当前阶段，然后验证下一阶段的过渡）

同时解析评审模式（本次运行中所有阶段门实例均使用该模式）：

如果传入
```
--review [full|lean|solo]
```
→ 使用该模式
否则读取
```
production/review-mode.txt
```
→ 使用该文件中的值
否则 → 默认使用
```
lean
```
模式

注意：在

solo

模式下，会跳过生成主管代理（CD-PHASE-GATE、TD-PHASE-GATE、PR-PHASE-GATE、AD-PHASE-GATE）——阶段门检查仅变为交付物存在性检查。在

lean

模式下，仍会运行全部四位主管（阶段门正是lean模式的核心用途）。

带参数示例：
```
/gate-check production
```
— 验证进入指定阶段的就绪情况
无参数：使用与
```
/project-stage-detect
```
相同的启发式规则自动检测当前阶段，然后运行前需与用户确认：
使用
```
AskUserQuestion
```
：
- 提示："检测到当前阶段：[current stage]。即将运行从[当前阶段]→[下一阶段]的阶段门检查。是否正确？"
- 选项：
  - ```
  [A] 是 — 运行此阶段门检查
```
- ```
[B] 否 — 选择其他阶段门
```
    （若选中，展示第二个选项列表：Concept→Systems Design、Systems Design→Technical Setup、Technical Setup→Pre-Production、Pre-Production→Production、Production→Polish、Polish→Release）
无参数时不得跳过此确认步骤。

2. Phase Gate Definitions

2. 阶段门定义

Gate: Concept → Systems Design

阶段门：Concept → Systems Design

Required Artifacts:

```
design/gdd/game-concept.md
```
exists and has content
Game pillars defined (in concept doc or
```
design/gdd/game-pillars.md
```
)
Visual Identity Anchor section exists in
```
design/gdd/game-concept.md
```
(from brainstorm Phase 4 art-director output)

Recommended (not blocking):

Concept prototype exists in
```
prototypes/
```
with a REPORT.md showing PROCEED verdict (
```
/prototype [core-mechanic]
```
) — skipping this means GDDs may be written for an idea that hasn't been played. Acceptable if the concept is proven by other means.

Quality Checks:

Game concept has been reviewed (
```
/design-review
```
verdict not MAJOR REVISION NEEDED)
Core loop is described and understood
Target audience is identified
Visual Identity Anchor contains a one-line visual rule and at least 2 supporting visual principles

必需交付物：

```
design/gdd/game-concept.md
```
存在且包含内容
已定义游戏核心支柱（在概念文档或
```
design/gdd/game-pillars.md
```
中）
```
design/gdd/game-concept.md
```
中存在视觉定位锚点章节（来自头脑风暴第4阶段美术主管输出）

建议项（不构成阻碍）：

```
prototypes/
```
目录下存在概念原型，且包含显示PROCEED判定结果的REPORT.md（运行
```
/prototype [core-mechanic]
```
生成）——跳过此项意味着GDD可能基于未经过实际体验的想法撰写，若有其他方式证明概念可行则可接受。

质量检查：

游戏概念已通过评审（
```
/design-review
```
判定结果不为MAJOR REVISION NEEDED）
核心循环已被描述且明确易懂
已确定目标受众
视觉定位锚点包含一条视觉规则及至少2条支撑性视觉原则

Gate: Systems Design → Technical Setup

阶段门：Systems Design → Technical Setup

Required Artifacts:

Systems index exists at
```
design/gdd/systems-index.md
```
with at least MVP systems enumerated
All MVP-tier GDDs exist in
```
design/gdd/
```
and individually pass
```
/design-review
```
A cross-GDD review report exists in
```
design/gdd/
```
(from
```
/review-all-gdds
```
)

Quality Checks:

All MVP GDDs pass individual design review (8 required sections, no MAJOR REVISION NEEDED verdict)
```
/review-all-gdds
```
verdict is not FAIL (cross-GDD consistency and design theory checks pass)
All cross-GDD consistency issues flagged by
```
/review-all-gdds
```
are resolved or explicitly accepted
System dependencies are mapped in the systems index and are bidirectionally consistent
MVP priority tier is defined
No stale GDD references flagged (older GDDs updated to reflect decisions made in later GDDs)

必需交付物：

系统索引文件
```
design/gdd/systems-index.md
```
存在，且至少列举了MVP（最小可行产品）级别的系统
所有MVP级别的GDD均存在于
```
design/gdd/
```
目录下，且各自通过
```
/design-review
```
评审
```
design/gdd/
```
目录下存在跨GDD评审报告（来自
```
/review-all-gdds
```
）

质量检查：

所有MVP级GDD均通过单独的设计评审（包含8个必填章节，判定结果不为MAJOR REVISION NEEDED）
```
/review-all-gdds
```
的判定结果不为FAIL（跨GDD一致性和设计理论检查通过）
```
/review-all-gdds
```
标记的所有跨GDD一致性问题已解决或被明确接受
系统索引中已映射系统依赖关系，且双向一致
已定义MVP优先级层级
无过期GDD引用标记（旧GDD已更新以反映后续GDD中的决策）

Gate: Technical Setup → Pre-Production

阶段门：Technical Setup → Pre-Production

Required Artifacts:

Engine chosen (CLAUDE.md Technology Stack is not
```
[CHOOSE]
```
)
Technical preferences configured (
```
.claude/docs/technical-preferences.md
```
populated)
Art bible exists at
```
design/art/art-bible.md
```
with at least Sections 1–4 (Visual Identity Foundation)
At least 3 Architecture Decision Records in
```
docs/architecture/
```
covering Foundation-layer systems (scene management, event architecture, save/load)
Engine reference docs exist in
```
docs/engine-reference/[engine]/
```
Test framework initialized:
```
tests/unit/
```
and
```
tests/integration/
```
directories exist
CI/CD test workflow exists at
```
.github/workflows/tests.yml
```
(or equivalent)
At least one example test file exists to confirm the framework is functional
Master architecture document exists at
```
docs/architecture/architecture.md
```

Architecture traceability index exists at

docs/architecture/requirements-traceability.md

```
/architecture-review
```
has been run (a review report file exists in
```
docs/architecture/
```
)
```
design/accessibility-requirements.md
```
exists with accessibility tier committed
```
design/ux/interaction-patterns.md
```
exists (pattern library initialized, even if minimal)

Quality Checks:

Architecture decisions cover core systems (rendering, input, state management)
Technical preferences have naming conventions and performance budgets set
Accessibility tier is defined and documented (even "Basic" is acceptable — undefined is not)
At least one screen's UX spec started (often the main menu or core HUD is designed during Technical Setup)
All ADRs have an Engine Compatibility section with engine version stamped
All ADRs have a GDD Requirements Addressed section with explicit GDD linkage

No ADR references APIs listed in

docs/engine-reference/[engine]/deprecated-apis.md

All HIGH RISK engine domains (per VERSION.md) have been explicitly addressed in the architecture document or flagged as open questions
Architecture traceability matrix has zero Foundation layer gaps (all Foundation requirements must have ADR coverage before Pre-Production)

ADR Circular Dependency Check: For all ADRs in

docs/architecture/

, read each ADR's "ADR Dependencies" / "Depends On" section. Build a dependency graph (ADR-A → ADR-B means A depends on B). If any cycle is detected (e.g. A→B→A, or A→B→C→A):

Flag as FAIL: "Circular ADR dependency: [ADR-X] → [ADR-Y] → [ADR-X]. Neither can reach Accepted while the cycle exists. Remove one 'Depends On' edge to break the cycle."

Engine Validation (read

docs/engine-reference/[engine]/VERSION.md

first):

ADRs that touch post-cutoff engine APIs are flagged with Knowledge Risk: HIGH/MEDIUM
```
/architecture-review
```
engine audit shows no deprecated API usage
All ADRs agree on the same engine version (no stale version references)

必需交付物：

已选定引擎（CLAUDE.md技术栈不为
```
[CHOOSE]
```
）
已配置技术偏好（
```
.claude/docs/technical-preferences.md
```
已填充内容）
美术规范文件
```
design/art/art-bible.md
```
存在，且至少包含第1-4章节（视觉定位基础）
```
docs/architecture/
```
目录下至少有3份架构决策记录（ADR），涵盖基础层系统（场景管理、事件架构、存档/读档）
引擎参考文档存在于
```
docs/engine-reference/[engine]/
```
目录下
测试框架已初始化：
```
tests/unit/
```
和
```
tests/integration/
```
目录存在
CI/CD测试工作流存在于
```
.github/workflows/tests.yml
```
（或等效位置）
至少存在一个示例测试文件，以确认测试框架可正常运行
主架构文档存在于
```
docs/architecture/architecture.md
```

架构可追溯性索引存在于

docs/architecture/requirements-traceability.md

已运行
```
/architecture-review
```
（
```
docs/architecture/
```
目录下存在评审报告文件）
```
design/accessibility-requirements.md
```
存在，且已确定无障碍级别
```
design/ux/interaction-patterns.md
```
存在（模式库已初始化，即使内容很少）

质量检查：

架构决策涵盖核心系统（渲染、输入、状态管理）
技术偏好已设置命名规范和性能预算
已定义并记录无障碍级别（即使是"基础"级别也可接受——未定义则不可）
至少已开始设计一个屏幕的UX规范（通常在Technical Setup阶段设计主菜单或核心HUD）
所有ADR均包含引擎兼容性章节，并标记了引擎版本
所有ADR均包含GDD需求覆盖章节，并明确关联GDD

无ADR引用

docs/engine-reference/[engine]/deprecated-apis.md

中列出的API

所有高风险引擎领域（根据VERSION.md）已在架构文档中明确处理，或标记为待解决问题
架构可追溯性矩阵基础层无缺口（进入Pre-Production前，所有基础层需求必须有ADR覆盖）

ADR循环依赖检查：对于

docs/architecture/

中的所有ADR，读取每个ADR的"ADR依赖项"/"依赖于"章节，构建依赖图（ADR-A→ADR-B表示A依赖于B）。如果检测到任何循环（例如A→B→A，或A→B→C→A）：

标记为FAIL："ADR循环依赖：[ADR-X]→[ADR-Y]→[ADR-X]。循环存在时，两者均无法达到Accepted状态。移除一条'依赖于'边以打破循环。"

引擎验证（先读取

docs/engine-reference/[engine]/VERSION.md

）：

涉及引擎 cutoff 后API的ADR标记为知识风险：高/中
```
/architecture-review
```
引擎审计显示无已废弃API使用
所有ADR均使用相同的引擎版本（无过期版本引用）

Gate: Pre-Production → Production

阶段门：Pre-Production → Production

Required Artifacts:

Vertical slice exists in
```
prototypes/
```
with a REPORT.md (run
```
/vertical-slice
```
) — recommended, not blocking; if absent, surface as CONCERNS
First sprint plan exists in
```
production/sprints/
```
Art bible is complete (all 9 sections) and AD-ART-BIBLE sign-off verdict is recorded in
```
design/art/art-bible.md
```
Entity inventory exists at
```
design/assets/entity-inventory.md
```
(recommended — run
```
/asset-spec
```
with no arguments to generate collaboratively from GDDs + art bible)
All MVP-tier GDDs from systems index are complete
Master architecture document exists at
```
docs/architecture/architecture.md
```
At least 3 ADRs covering Foundation-layer decisions exist in
```
docs/architecture/
```
All Foundation and Core layer ADRs have status
```
Accepted
```
(not
```
Proposed
```
) — stories cannot be unblocked until their governing ADR is accepted

Control manifest exists at

docs/architecture/control-manifest.md

(generated by

/create-control-manifest

from Accepted ADRs)

Epics defined in
```
production/epics/
```
with at least Foundation and Core layer epics present (use
```
/create-epics layer: foundation
```
and
```
/create-epics layer: core
```
to create them, then
```
/create-stories [epic-slug]
```
for each epic)
Vertical Slice build exists and is playable (not just scope-defined) — recommended, not blocking; if absent, surface as CONCERNS
Vertical Slice has been playtested with at least 1 documented session — recommended, not blocking; if absent, surface as CONCERNS
Vertical Slice playtest report exists at
```
production/playtests/
```
or equivalent — recommended, not blocking; if absent, surface as CONCERNS
UX specs exist for key screens: main menu, core gameplay HUD (at
```
design/ux/
```
), pause menu
HUD design document exists at
```
design/ux/hud.md
```
(if game has in-game HUD)
All key screen UX specs have passed
```
/ux-review
```
(verdict APPROVED or NEEDS REVISION accepted)

Quality Checks:

Core loop fun is validated — playtest data confirms the central mechanic is enjoyable, not just functional. Explicitly check the Vertical Slice playtest report.
UX specs cover all UI Requirements sections from MVP-tier GDDs
Interaction pattern library documents patterns used in key screens
Accessibility tier from
```
design/accessibility-requirements.md
```
is addressed in all key screen UX specs
Sprint plan references real story file paths from
```
production/epics/
```
(not just GDDs — stories must embed GDD req ID + ADR reference)
Vertical Slice is COMPLETE, not just scoped — the build demonstrates the full core loop end-to-end. At least one complete [start → challenge → resolution] cycle works.
Architecture document has no unresolved open questions in Foundation or Core layers
All ADRs have Engine Compatibility sections stamped with the engine version
All ADRs have ADR Dependencies sections (even if all fields are "None")
Manual validation confirms GDDs + architecture + epics are coherent (run
```
/review-all-gdds
```
and
```
/architecture-review
```
if not done recently)
Core fantasy is delivered — at least one playtester independently described an experience that matches the Player Fantasy section of the core system GDDs (without being prompted).

Vertical Slice Validation (only run these checks if a Vertical Slice was built):

A human has played through the core loop without developer guidance
The game communicates what to do within the first 2 minutes of play
No critical "fun blocker" bugs exist in the Vertical Slice build
The core mechanic feels good to interact with (this is a subjective check — ask the user)

Verdict rules for Vertical Slice:

Slice was built AND any validation item is NO → verdict is automatically FAIL. A broken or unfun vertical slice should not advance to Production.

Slice was not built (skipped) → downgrade to CONCERNS only, not FAIL. Surface the risk clearly: "Advancing without a validated Vertical Slice increases the risk of late-stage design pivots. Recommended before committing full production scope." The user decides.

Skipping is a valid solo dev or time-constrained call. Shipping a broken one is not.

必需交付物：

```
prototypes/
```
目录下存在垂直切片，且包含REPORT.md（运行
```
/vertical-slice
```
生成）——建议项，不构成阻碍；若缺失，标记为CONCERNS
```
production/sprints/
```
目录下存在首个冲刺计划
美术规范已完成（全部9个章节），且AD-ART-BIBLE签字确认结果已记录在
```
design/art/art-bible.md
```
中
实体清单存在于
```
design/assets/entity-inventory.md
```
（建议项——运行无参数的
```
/asset-spec
```
从GDD和美术规范协作生成）
系统索引中的所有MVP级GDD均已完成
主架构文档存在于
```
docs/architecture/architecture.md
```
```
docs/architecture/
```
目录下至少有3份涵盖基础层决策的ADR
所有基础层和核心层ADR的状态为
```
Accepted
```
（非
```
Proposed
```
）——在其管辖ADR被接受前，任务无法解除阻塞

控制清单存在于

docs/architecture/control-manifest.md

（由

/create-control-manifest

从已接受的ADR生成）

```
production/epics/
```
目录下已定义Epic，至少包含基础层和核心层Epic（使用
```
/create-epics layer: foundation
```
和
```
/create-epics layer: core
```
创建，然后对每个Epic运行
```
/create-stories [epic-slug]
```
）
垂直切片构建版本存在且可玩（不仅仅是定义了范围）——建议项，不构成阻碍；若缺失，标记为CONCERNS
垂直切片已进行至少1次有记录的游戏测试——建议项，不构成阻碍；若缺失，标记为CONCERNS
垂直切片游戏测试报告存在于
```
production/playtests/
```
或等效位置——建议项，不构成阻碍；若缺失，标记为CONCERNS
关键屏幕的UX规范存在：主菜单、核心游戏HUD（位于
```
design/ux/
```
）、暂停菜单
HUD设计文档存在于
```
design/ux/hud.md
```
（若游戏包含游戏内HUD）
所有关键屏幕的UX规范均已通过
```
/ux-review
```
（判定结果为APPROVED或NEEDS REVISION已被接受）

质量检查：

核心循环趣味性已验证——游戏测试数据确认核心机制是令人愉悦的，而非仅具备功能性。需明确检查垂直切片游戏测试报告。
UX规范覆盖了MVP级GDD中的所有UI需求章节
交互模式库记录了关键屏幕中使用的模式
```
design/accessibility-requirements.md
```
中的无障碍级别在所有关键屏幕UX规范中已得到满足
冲刺计划引用了
```
production/epics/
```
中的真实任务文件路径（不仅仅是GDD——任务必须嵌入GDD需求ID+ADR引用）
垂直切片已完成，不仅仅是定义了范围——构建版本展示了完整的核心循环端到端流程，至少有一个完整的[开始→挑战→解决]循环可正常运行
架构文档中基础层和核心层无未解决的待办问题
所有ADR均包含标记了引擎版本的引擎兼容性章节
所有ADR均包含ADR依赖项章节（即使所有字段为"无"）
人工验证确认GDD+架构+Epic保持一致（若近期未运行，需运行
```
/review-all-gdds
```
和
```
/architecture-review
```
）
核心体验已实现——至少有一名游戏测试者在未被提示的情况下，独立描述了与核心系统GDD中玩家体验章节匹配的体验。

垂直切片验证（仅在已构建垂直切片时运行这些检查）：

有人已在无开发者指导的情况下完成核心循环体验
游戏在开始后的前2分钟内清晰传达了操作指引
垂直切片构建版本中不存在严重的"趣味性阻碍"Bug
核心机制的交互体验良好（此为主观检查——需询问用户）

垂直切片判定规则：

已构建切片但任何验证项未通过 → 判定结果自动为FAIL。存在问题或无趣的垂直切片不应推进到Production阶段。

未构建切片（已跳过） → 仅降级为CONCERNS，而非FAIL。需明确提示风险："未经过验证的垂直切片就推进，会增加后期设计变更的风险。建议在投入完整生产范围前完成验证。"最终由用户决定。

跳过切片验证对于独立开发者或时间紧张的项目是合理选择，但交付存在问题的切片则不可接受。

Gate: Production → Polish

阶段门：Production → Polish

Required Artifacts:

```
src/
```
has active code organized into subsystems
All core mechanics from GDD are implemented (cross-reference
```
design/gdd/
```
with
```
src/
```
)
Main gameplay path is playable end-to-end
Test files exist in
```
tests/unit/
```
and
```
tests/integration/
```
covering Logic and Integration stories
All Logic stories from this sprint have corresponding unit test files in
```
tests/unit/
```
Smoke check has been run with a PASS or PASS WITH WARNINGS verdict — report exists in
```
production/qa/
```
QA plan exists in
```
production/qa/
```
(generated by
```
/qa-plan
```
) covering this sprint or final production sprint
At least one QA plan exists in
```
production/qa/
```
covering this production phase — run
```
/qa-plan
```
if missing (CONCERNS — advisory, not blocking)
QA sign-off report exists in
```
production/qa/
```
(generated by
```
/team-qa
```
) with verdict APPROVED or APPROVED WITH CONDITIONS
At least 3 distinct playtest sessions documented in
```
production/playtests/
```
Playtest reports cover: new player experience, mid-game systems, and difficulty curve
Fun hypothesis from Game Concept has been explicitly validated or revised

Quality Checks:

Tests are passing (run test suite via Bash)
No critical/blocker bugs in any bug tracker or known issues
Core loop plays as designed (compare to GDD acceptance criteria)
Performance is within budget (check technical-preferences.md targets)
Playtest findings have been reviewed and critical fun issues addressed (not just documented)
No "confusion loops" identified — no point in the game where >50% of playtesters got stuck without knowing why
Difficulty curve matches the Difficulty Curve design doc (if one exists at
```
design/difficulty-curve.md
```
)
All implemented screens have corresponding UX specs (no "designed in-code" screens)
Interaction pattern library is up-to-date with all patterns used in implementation
Accessibility compliance verified against committed tier in
```
design/accessibility-requirements.md
```

必需交付物：

```
src/
```
目录下的活跃代码已按子系统组织
GDD中的所有核心机制均已实现（交叉比对
```
design/gdd/
```
与
```
src/
```
）
主要游戏流程可端到端游玩
```
tests/unit/
```
和
```
tests/integration/
```
目录下存在覆盖逻辑和集成任务的测试文件
本次冲刺的所有逻辑任务在
```
tests/unit/
```
目录下均有对应的单元测试文件
已运行冒烟测试，判定结果为PASS或PASS WITH WARNINGS——报告存在于
```
production/qa/
```
QA计划存在于
```
production/qa/
```
（由
```
/qa-plan
```
生成），覆盖本次冲刺或最终生产冲刺
```
production/qa/
```
目录下至少有一份覆盖当前生产阶段的QA计划——若缺失，运行
```
/qa-plan
```
（标记为CONCERNS——建议项，不构成阻碍）
QA签字确认报告存在于
```
production/qa/
```
（由
```
/team-qa
```
生成），判定结果为APPROVED或APPROVED WITH CONDITIONS
```
production/playtests/
```
目录下至少有3次不同的游戏测试会话记录
游戏测试报告涵盖：新玩家体验、中期游戏系统、难度曲线
游戏概念中的趣味性假设已被明确验证或修订

质量检查：

测试通过（通过Bash运行测试套件）
任何Bug跟踪器或已知问题中均无严重/阻塞性Bug
核心循环按设计运行（与GDD验收标准比对）
性能符合预算（检查technical-preferences.md中的目标）
游戏测试发现的问题已被评审，且严重的趣味性问题已得到解决（不仅仅是记录）
未发现"困惑循环"——游戏中不存在超过50%的测试者卡住且不知道原因的节点
难度曲线与
```
design/difficulty-curve.md
```
中的设计文档匹配（若存在）
所有已实现的屏幕均有对应的UX规范（无"在代码中设计"的屏幕）
交互模式库已更新，包含实现中使用的所有模式
已根据
```
design/accessibility-requirements.md
```
中确定的级别验证无障碍合规性

Gate: Polish → Release

阶段门：Polish → Release

Required Artifacts:

All features from milestone plan are implemented
Content is complete (all levels, assets, dialogue referenced in design docs exist)
Localization strings are externalized (no hardcoded player-facing text in
```
src/
```
)
QA test plan exists (
```
/qa-plan
```
output in
```
production/qa/
```
)
QA sign-off report exists (
```
/team-qa
```
output — APPROVED or APPROVED WITH CONDITIONS)
All Must Have story test evidence is present (Logic/Integration: test files pass; Visual/Feel/UI: sign-off docs in
```
production/qa/evidence/
```
)
Smoke check passes cleanly (PASS verdict) on the release candidate build
No test regressions from previous sprint (test suite passes fully)
Balance data has been reviewed (
```
/balance-check
```
run)
Release checklist completed (
```
/release-checklist
```
or
```
/launch-checklist
```
run)
Store metadata prepared (if applicable)
Changelog / patch notes drafted

Quality Checks:

Full QA pass signed off by
```
qa-lead
```
All tests passing
Performance targets met across all target platforms
No known critical, high, or medium-severity bugs
Accessibility basics covered (remapping, text scaling if applicable)
Localization verified for all target languages
Legal requirements met (EULA, privacy policy, age ratings if applicable)
Build compiles and packages cleanly

必需交付物：

里程碑计划中的所有功能均已实现
内容完整（设计文档中引用的所有关卡、资源、对话均存在）
本地化字符串已外部化（
```
src/
```
中无硬编码的面向玩家文本）
QA测试计划存在（
```
/qa-plan
```
输出位于
```
production/qa/
```
）
QA签字确认报告存在（
```
/team-qa
```
输出——判定结果为APPROVED或APPROVED WITH CONDITIONS）
所有Must Have任务的测试证据均存在（逻辑/集成：测试文件通过；视觉/体验/UI：
```
production/qa/evidence/
```
中的签字确认文档）
发布候选版本的冒烟测试完全通过（PASS判定结果）
与上一冲刺相比无测试回归（测试套件完全通过）
平衡性数据已被评审（已运行
```
/balance-check
```
）
发布清单已完成（已运行
```
/release-checklist
```
或
```
/launch-checklist
```
）
商店元数据已准备（如适用）
更新日志/补丁说明已草拟

质量检查：

```
qa-lead
```
已签字确认完成完整QA测试
所有测试通过
所有目标平台均满足性能目标
无已知的严重、高或中等级别Bug
已覆盖基础无障碍需求（如适用的按键重映射、文本缩放）
所有目标语言的本地化已验证
已满足法律要求（最终用户许可协议、隐私政策、年龄评级等，如适用）
构建版本可正常编译和打包

3. Run the Gate Check

3. 运行阶段门检查

Before running artifact checks, read

docs/consistency-failures.md

if it exists. Extract entries whose Domain matches the target phase (e.g., if checking Systems Design → Technical Setup, pull entries in Economy, Combat, or any GDD domain; if checking Technical Setup → Pre-Production, pull entries in Architecture, Engine). Carry these as context — recurring conflict patterns in the target domain warrant increased scrutiny on those specific checks.

For each item in the target gate:

在运行交付物检查前，若

docs/consistency-failures.md

存在则读取该文件，提取与目标阶段匹配的条目（例如，若检查Systems Design→Technical Setup，提取经济、战斗或任何GDD领域的条目；若检查Technical Setup→Pre-Production，提取架构、引擎领域的条目）。将这些作为上下文——目标领域中反复出现的冲突模式需要对特定检查进行更严格的审查。

针对目标阶段门中的每个条目：

Artifact Checks

交付物检查

Use
```
Glob
```
and
```
Read
```
to verify files exist and have meaningful content
Don't just check existence — verify the file has real content (not just a template header)
For code checks, verify directory structure and file counts

Systems Design → Technical Setup gate — cross-GDD review check: Use

Glob('design/gdd/gdd-cross-review-*.md')

to find the

/review-all-gdds

report. If no file matches, mark the "cross-GDD review report exists" artifact as FAIL and surface it prominently: "No

/review-all-gdds

report found in

design/gdd/

. Run

/review-all-gdds

before advancing to Technical Setup." If a file is found, read it and check the verdict line: a FAIL verdict means the cross-GDD consistency check failed and must be resolved before advancing.

使用
```
Glob
```
和
```
Read
```
验证文件存在且包含有意义的内容
不要仅检查存在性——需验证文件包含真实内容（不仅仅是模板头部）
对于代码检查，验证目录结构和文件数量

Systems Design→Technical Setup阶段门——跨GDD评审检查：使用

Glob('design/gdd/gdd-cross-review-*.md')

查找

/review-all-gdds

报告。若无匹配文件，标记"跨GDD评审报告存在"交付物为FAIL，并突出显示："

design/gdd/

目录下未找到

/review-all-gdds

报告。进入Technical Setup前请运行

/review-all-gdds

。"若找到文件，读取并检查判定行：FAIL判定结果意味着跨GDD一致性检查未通过，必须解决后才能推进。

Quality Checks

质量检查

For test checks: Run the test suite via
```
Bash
```
if a test runner is configured
For design review checks:
```
Read
```
the GDD and check for the 8 required sections
For performance checks:
```
Read
```
technical-preferences.md and compare against any profiling data in
```
tests/performance/
```
or recent
```
/perf-profile
```
output
For localization checks:
```
Grep
```
for hardcoded strings in
```
src/
```

对于测试检查：若已配置测试运行器，通过
```
Bash
```
运行测试套件
对于设计评审检查：
```
Read
```
GDD并检查是否包含8个必填章节
对于性能检查：
```
Read
```
technical-preferences.md并与
```
tests/performance/
```
中的性能分析数据或近期
```
/perf-profile
```
输出进行比对
对于本地化检查：在
```
src/
```
中使用
```
Grep
```
查找硬编码字符串

Cross-Reference Checks

交叉引用检查

Compare
```
design/gdd/
```
documents against
```
src/
```
implementations
Check that every system referenced in architecture docs has corresponding code
Verify sprint plans reference real work items

比对
```
design/gdd/
```
文档与
```
src/
```
实现
检查架构文档中引用的每个系统均有对应的代码
验证冲刺计划引用了真实的工作项

4. Collaborative Assessment

4. 协作评估

For items that can't be automatically verified, ask the user:

"I can't automatically verify that the core loop plays well. Has it been playtested?"
"No playtest report found. Has informal testing been done?"
"Performance profiling data isn't available. Would you like to run
```
/perf-profile
```
?"

Never assume PASS for unverifiable items. Mark them as MANUAL CHECK NEEDED.

对于无法自动验证的条目，询问用户：

"我无法自动验证核心循环的游玩体验是否良好。是否已进行游戏测试？"
"未找到游戏测试报告。是否已进行非正式测试？"
"无性能分析数据。是否要运行
```
/perf-profile
```
？"

绝不要假设无法验证的条目为PASS，标记为MANUAL CHECK NEEDED（需人工检查）。

4b. Director Panel Assessment

4b. 主管小组评估

Apply review mode before spawning any director:

```
solo
```
→ skip all four directors. Note in output: "Director Panel skipped — Solo mode. Gate verdict based on artifact and quality checks only." Proceed to Phase 5.
```
lean
```
→ spawn all four directors (phase gates always run in lean mode — this is their purpose).
```
full
```
→ spawn all four directors as normal.

(Review mode was resolved in Phase 1. Use that stored value here.)

Before generating the final verdict, spawn all four directors as parallel subagents via Task using the parallel gate protocol from

.claude/docs/director-gates.md

. Issue all four Task calls simultaneously — do not wait for one before starting the next.

Spawn in parallel:

creative-director
— gate CD-PHASE-GATE (

.claude/docs/director-gates.md

)

technical-director
— gate TD-PHASE-GATE (

.claude/docs/director-gates.md

)

producer
— gate PR-PHASE-GATE (
```
.claude/docs/director-gates.md
```
)

art-director
— gate AD-PHASE-GATE (

.claude/docs/director-gates.md

)

Pass to each: target phase name, list of artifacts present, and the context fields listed in that gate's definition.

Collect all four responses, then present the Director Panel summary:

undefined

在生成任何主管代理前应用评审模式：

```
solo
```
→ 跳过所有四位主管。在输出中注明："已跳过主管小组——Solo模式。阶段门判定结果仅基于交付物和质量检查。"继续执行第5阶段。
```
lean
```
→ 生成所有四位主管（阶段门始终在lean模式下运行——这是其核心用途）。
```
full
```
→ 正常生成所有四位主管。

（评审模式已在第1阶段解析，此处使用存储的值。）

在生成最终判定结果前，通过Task以并行子代理的方式生成所有四位主管，遵循

.claude/docs/director-gates.md

中的并行阶段门协议。同时发出所有四个Task调用——不要等待一个完成后再启动下一个。

并行生成：

creative-director
— 阶段门CD-PHASE-GATE（

.claude/docs/director-gates.md

）

technical-director
— 阶段门TD-PHASE-GATE（

.claude/docs/director-gates.md

）

producer
— 阶段门PR-PHASE-GATE（
```
.claude/docs/director-gates.md
```
）

art-director
— 阶段门AD-PHASE-GATE（

.claude/docs/director-gates.md

）

向每位主管传递：目标阶段名称、已存在的交付物列表，以及该阶段门定义中列出的上下文字段。

收集所有四个响应，然后展示主管小组总结：

undefined

Director Panel Assessment

主管小组评估

Creative Director: [READY / CONCERNS / NOT READY] [feedback]

Technical Director: [READY / CONCERNS / NOT READY] [feedback]

Producer: [READY / CONCERNS / NOT READY] [feedback]

Art Director: [READY / CONCERNS / NOT READY] [feedback]


**Apply to the verdict:**
- Any director returns NOT READY → verdict is minimum FAIL (user may override with explicit acknowledgement)
- Any director returns CONCERNS → verdict is minimum CONCERNS
- All four READY → eligible for PASS (still subject to artifact and quality checks from Section 3)

---

创意主管: [READY / CONCERNS / NOT READY] [反馈内容]

技术主管: [READY / CONCERNS / NOT READY] [反馈内容]

制作人: [READY / CONCERNS / NOT READY] [反馈内容]

美术主管: [READY / CONCERNS / NOT READY] [反馈内容]


**应用到判定结果**：
- 任何一位主管返回NOT READY → 判定结果至少为FAIL（用户可通过明确确认覆盖）
- 任何一位主管返回CONCERNS → 判定结果至少为CONCERNS
- 四位均返回READY → 有资格获得PASS（仍需满足第3阶段的交付物和质量检查）

---

5. Output the Verdict

5. 输出判定结果

undefined

undefined

Gate Check: [Current Phase] → [Target Phase]

阶段门检查: [当前阶段] → [目标阶段]

Date: [date] Checked by: gate-check skill

日期: [日期] 检查者: gate-check技能

Required Artifacts: [X/Y present]

必需交付物: [X/Y已存在]

design/gdd/game-concept.md — exists, 2.4KB
docs/architecture/ — MISSING (no ADRs found)
production/sprints/ — exists, 1 sprint plan

design/gdd/game-concept.md — 存在，大小2.4KB
docs/architecture/ — 缺失（未找到ADR）
production/sprints/ — 存在，包含1份冲刺计划

Quality Checks: [X/Y passing]

质量检查: [X/Y已通过]

GDD has 8/8 required sections
Tests — FAILED (3 failures in tests/unit/)
[?] Core loop playtested — MANUAL CHECK NEEDED

GDD包含8/8个必填章节
测试 — 未通过（tests/unit/中有3个失败项）
[?] 核心循环已进行游戏测试 — 需人工检查

Blockers

阻碍因素

No Architecture Decision Records — Run
```
/architecture-decision
```
to create one covering core system architecture before entering production.
3 test failures — Fix failing tests in tests/unit/ before advancing.

无架构决策记录 — 进入生产阶段前，请运行
```
/architecture-decision
```
创建一份涵盖核心系统架构的ADR。
3个测试失败项 — 推进前请修复tests/unit/中的失败测试。

Recommendations

建议

[Priority actions to resolve blockers]
[Optional improvements that aren't blocking]

[解决阻碍因素的优先行动]
[不构成阻碍的可选改进项]

Verdict: [PASS / CONCERNS / FAIL]

判定结果: [PASS / CONCERNS / FAIL]

PASS: All required artifacts present, all quality checks passing
CONCERNS: Minor gaps exist but can be addressed during the next phase
FAIL: Critical blockers must be resolved before advancing

---

PASS: 所有必需交付物均存在，所有质量检查均通过
CONCERNS: 存在微小缺口，但可在下一阶段解决
FAIL: 存在关键阻碍因素，必须解决后才能推进

---

5a. Chain-of-Verification

5a. 验证链

After drafting the verdict in Phase 5, challenge it before finalising.

Step 1 — Generate 5 challenge questions designed to disprove the verdict:

Tool-action requirement: At least 2 of the 5 challenge questions below must be answered by re-reading a specific file (Read tool) or re-running a specific check (Grep tool) — not by reflection alone. Mark these with [TOOL ACTION] to indicate a tool was used.

For a PASS draft:

"Which quality checks did I verify by actually reading a file, vs. inferring they passed?"
"Are there MANUAL CHECK NEEDED items I marked PASS without user confirmation? [TOOL ACTION] Re-scan the checklist for any [?] or MANUAL CHECK items."
"Did I confirm all listed artifacts have real content, not just empty headers? [TOOL ACTION] Re-read the file and check it has non-placeholder content."
"Could any blocker I dismissed as minor actually prevent the phase from succeeding?"
"Which single check am I least confident in, and why?"

For a CONCERNS draft:

"Could any listed CONCERN be elevated to a blocker given the project's current state?"
"Is the concern resolvable within the next phase, or does it compound over time?"
"Did I soften any FAIL condition into a CONCERN to avoid a harder verdict?"
"Are there artifacts I didn't check that could reveal additional blockers?"
"Do all the CONCERNS together create a blocking problem even if each is minor alone?"

For a FAIL draft:

"Have I accurately separated hard blockers from strong recommendations?"
"Are there any PASS items I was too lenient about?"
"Am I missing any additional blockers the user should know about?"
"Can I provide a minimal path to PASS — the specific 3 things that must change?"
"Is the fail condition resolvable, or does it indicate a deeper design problem?"

Step 2 — Answer each question independently. Do NOT reference the draft verdict text — re-check specific files or ask the user.

Step 3 — Revise if needed:

If any answer reveals a missed blocker → upgrade verdict (PASS→CONCERNS or CONCERNS→FAIL)
If any answer reveals an over-stated blocker → downgrade only if citing specific evidence
If answers are consistent → confirm verdict unchanged

Step 4 — Note the verification in the final report output:

Chain-of-Verification: [N] questions checked — verdict [unchanged | revised from X to Y]

在第5阶段草拟判定结果后，在最终确定前对其进行质疑。

步骤1 — 生成5个质疑问题，旨在推翻当前判定结果：

工具操作要求：以下5个质疑问题中至少有2个必须通过重新读取特定文件（Read工具）或重新运行特定检查（Grep工具）来回答——不能仅通过思考。用[TOOL ACTION]标记这些问题，表明使用了工具。

对于PASS草拟结果：

"我通过实际读取文件验证了哪些质量检查，哪些是推断通过的？"
"是否有我在未获得用户确认的情况下标记为PASS的需人工检查项？[TOOL ACTION]重新扫描检查清单，查找任何[?]或需人工检查的条目。"
"我是否确认了所有列出的交付物包含真实内容，而非仅空头部？[TOOL ACTION]重新读取文件，检查是否包含非占位符内容。"
"我视为微小问题而忽略的阻碍因素，是否实际上会阻碍下一阶段的成功？"
"我最不自信的检查项是哪一个，为什么？"

对于CONCERNS草拟结果：

"考虑到项目当前状态，是否有任何列出的CONCERNS应升级为阻碍因素？"
"该问题是否可在下一阶段解决，还是会随时间加剧？"
"我是否为避免更严格的判定结果而将任何FAIL条件降为CONCERNS？"
"是否有我未检查的交付物可能揭示其他阻碍因素？"
"即使每个问题单独来看都很微小，所有CONCERNS加起来是否会构成阻碍？"

对于FAIL草拟结果：

"我是否准确区分了硬性阻碍因素和强烈建议？"
"是否有我过于宽松的PASS项？"
"我是否遗漏了用户应了解的其他阻碍因素？"
"我能否提供最小的PASS路径——必须改变的3件具体事项？"
"失败条件是否可解决，还是表明存在更深层次的设计问题？"

步骤2 — 独立回答每个问题 请勿参考草拟的判定结果文本——重新检查特定文件或询问用户。

步骤3 — 必要时修订：

若任何答案揭示了遗漏的阻碍因素 → 升级判定结果（PASS→CONCERNS或CONCERNS→FAIL）
若任何答案揭示了被夸大的阻碍因素 → 仅在有具体证据的情况下降级
若答案一致 → 确认判定结果不变

步骤4 — 在最终报告输出中注明验证情况：

验证链: 已检查[N]个问题 — 判定结果[未变更 | 从X修订为Y]

6. Update Stage on PASS

6. PASS时更新阶段

When the verdict is PASS and the user confirms they want to advance:

Write the new stage name to
```
production/stage.txt
```
(single line, no trailing newline)
This immediately updates the status line for all future sessions

Example: if passing the "Pre-Production → Production" gate:

bash

echo -n "Production" > production/stage.txt

Always ask before writing: "Gate passed. May I update

production/stage.txt

to 'Production'?"

当判定结果为PASS且用户确认要推进时：

将新阶段名称写入
```
production/stage.txt
```
（单行，无尾随换行符）
这会立即更新所有未来会话的状态行

示例：若通过"Pre-Production→Production"阶段门：

bash

echo -n "Production" > production/stage.txt

写入前务必询问："阶段门已通过。是否允许我将

production/stage.txt

更新为'Production'？"

7. Closing Next-Step Widget

7. 收尾下一步小部件

After the verdict is presented and any stage.txt update is complete, close with a structured next-step prompt using

AskUserQuestion

Tailor the options to the gate that just ran:

For systems-design PASS:

Gate passed. What would you like to do next?
[A] Run /create-architecture — produce your master architecture blueprint and ADR work plan (recommended next step)
[B] Design more GDDs first — return here when all MVP systems are complete
[C] Stop here for this session

Note for systems-design PASS:
/create-architecture
is the required next step before writing any ADRs. It produces the master architecture document and a prioritized list of ADRs to write. Running
/architecture-decision
without this step means writing ADRs without a blueprint — skip it at your own risk.

For technical-setup PASS:

Gate passed. What would you like to do next?
[A] Run /create-control-manifest — generate the layer rules manifest from your Accepted ADRs (do this first)
[B] Run /vertical-slice — build the Vertical Slice (do this before writing epics — validate fun first)
[C] Write more ADRs first — run /architecture-decision [next-system]
[D] Stop here for this session

Note for technical-setup PASS: The Pre-Production sequence is deliberately ordered to validate fun before committing to detailed planning:
/create-control-manifest
— extract technical rules from Accepted ADRs (required before epics)
/vertical-slice
— build the Vertical Slice FIRST, before writing epics or stories
Playtest →
/playtest-report
— at least 1 session required to pass the Pre-Production gate; 3+ recommended before committing the full team
/ux-design [screen]
— UX specs for main menu, core HUD, pause menu (if not done)
/create-epics layer:foundation
then
/create-epics layer:core
— plan after fun is validated
/create-stories [epic-slug]
for each epic
/sprint-plan new
Why prototype before epics? If the prototype reveals the core loop needs to change, epics written before that discovery will be partially wrong. Validate fun cheaply first, then plan in detail. This is the #1 lesson from GDC postmortem data.

For all other gates, offer the two most logical next steps for that phase plus "Stop here".

在展示判定结果并完成任何stage.txt更新后，使用

AskUserQuestion

展示结构化的下一步提示。

根据刚运行的阶段门调整选项：

对于systems-design PASS：

阶段门已通过。接下来您想做什么？
[A] 运行/create-architecture — 生成主架构蓝图和ADR工作计划（推荐下一步）
[B] 先撰写更多GDD — 所有MVP系统完成后再返回此处
[C] 本次会话到此结束

systems-design PASS注意事项：
/create-architecture
是撰写任何ADR前的必需下一步。它会生成主架构文档和ADR撰写优先级列表。跳过此步骤直接运行
/architecture-decision
意味着在无蓝图的情况下撰写ADR——风险自负。

对于technical-setup PASS：

阶段门已通过。接下来您想做什么？
[A] 运行/create-control-manifest — 从已接受的ADR生成层规则清单（先执行此操作）
[B] 运行/vertical-slice — 构建垂直切片（撰写epic前执行此操作——先验证趣味性）
[C] 先撰写更多ADR — 运行/architecture-decision [next-system]
[D] 本次会话到此结束

technical-setup PASS注意事项：Pre-Production阶段的顺序经过精心设计，旨在投入详细规划前先验证趣味性：
/create-control-manifest
— 从已接受的ADR提取技术规则（撰写epic前必需）
/vertical-slice
— 首先构建垂直切片，然后再撰写epic或任务
游戏测试→
/playtest-report
— 通过Pre-Production阶段门至少需要1次会话；投入全团队前建议进行3次以上
/ux-design [screen]
— 主菜单、核心HUD、暂停菜单的UX规范（若未完成）
/create-epics layer:foundation
然后
/create-epics layer:core
— 趣味性验证后再进行规划
对每个epic运行
/create-stories [epic-slug]
/sprint-plan new
**为什么先做原型再写epic？**如果原型揭示核心循环需要变更，在此之前撰写的epic会部分失效。先低成本验证趣味性，再进行详细规划。这是GDC事后分析数据中的首要经验。

对于所有其他阶段门，提供该阶段最符合逻辑的两个下一步选项以及"本次会话到此结束"。

8. Follow-Up Actions

8. 后续行动建议

Based on the verdict, suggest specific next steps:

No art bible? →
```
/art-bible
```
to create the visual identity specification
Art bible exists but no asset specs? →
```
/asset-spec system:[name]
```
to generate per-asset visual specs and generation prompts from approved GDDs
No game concept? →
```
/brainstorm
```
to create one
No systems index? →
```
/map-systems
```
to decompose the concept into systems
Missing design docs? →
```
/reverse-document
```
or delegate to
```
game-designer
```
Small design change needed? →
```
/quick-design
```
for changes under ~4 hours (bypasses full GDD pipeline)
No UX specs? →
```
/ux-design [screen name]
```
to author specs, or
```
/team-ui [feature]
```
for full pipeline
UX specs not reviewed? →
```
/ux-review [file]
```
or
```
/ux-review all
```
to validate

No accessibility requirements doc? → run

/ux-design

which creates both

design/accessibility-requirements.md

and

design/ux/interaction-patterns.md

in one step

No interaction pattern library? →
```
/ux-design patterns
```
to initialize it
GDDs not cross-reviewed? →
```
/review-all-gdds
```
(run after all MVP GDDs are individually approved)
Cross-GDD consistency issues? → fix flagged GDDs, then re-run
```
/review-all-gdds
```
No test framework? →
```
/test-setup
```
to scaffold the framework for your engine
No QA plan for current sprint? →
```
/qa-plan sprint
```
to generate one before implementation begins
Missing ADRs? →
```
/architecture-decision
```
for individual decisions
No master architecture doc? →
```
/create-architecture
```
for the full blueprint
ADRs missing engine compatibility sections? → Re-run
```
/architecture-decision
```
or manually add Engine Compatibility sections to existing ADRs
Missing control manifest? →
```
/create-control-manifest
```
(requires Accepted ADRs)

Missing epics? →

/create-epics layer: foundation

then

/create-epics layer: core

(requires control manifest)

Missing stories for an epic? →
```
/create-stories [epic-slug]
```
(run after each epic is created)
Stories not implementation-ready? →
```
/story-readiness
```
to validate stories before developers pick them up
Tests failing? → delegate to
```
lead-programmer
```
or
```
qa-tester
```
No playtest data? →
```
/playtest-report
```
No playtest sessions beyond the minimum? → Additional sessions give more reliable signal. 3+ total is recommended before committing the full team. Use
```
/playtest-report
```
to structure findings.

No Difficulty Curve doc? → Create

design/difficulty-curve.md

from the template at

.claude/docs/templates/difficulty-curve.md

— or use

/quick-design "difficulty curve"

for a guided session.

No player journey map? → Create
```
design/player-journey.md
```
from the template at
```
.claude/docs/templates/player-journey.md
```
— or author it collaboratively using
```
/ux-design
```
Phase 2b.
Need a quick sprint check? →
```
/sprint-status
```
for current sprint progress snapshot
Performance unknown? →
```
/perf-profile
```
Not localized? →
```
/localize
```
Ready for release? →
```
/launch-checklist
```

根据判定结果，建议具体的下一步行动：

无美术规范？ → 运行
```
/art-bible
```
创建视觉定位规范
美术规范存在但无资源规格？ → 运行
```
/asset-spec system:[name]
```
从已批准的GDD生成每个资源的视觉规格和生成提示
无游戏概念？ → 运行
```
/brainstorm
```
创建一个
无系统索引？ → 运行
```
/map-systems
```
将概念分解为系统
缺失设计文档？ → 运行
```
/reverse-document
```
或委托给
```
game-designer
```
需要小的设计变更？ → 运行
```
/quick-design
```
处理约4小时以内的变更（绕过完整GDD流程）
无UX规范？ → 运行
```
/ux-design [screen name]
```
撰写规格，或运行
```
/team-ui [feature]
```
使用完整流程
UX规范未评审？ → 运行
```
/ux-review [file]
```
或
```
/ux-review all
```
进行验证

无无障碍需求文档？ → 运行

/ux-design

，一步创建

design/accessibility-requirements.md

和

design/ux/interaction-patterns.md

无交互模式库？ → 运行
```
/ux-design patterns
```
初始化
GDD未进行跨评审？ → 运行
```
/review-all-gdds
```
（所有MVP级GDD单独批准后运行）
存在跨GDD一致性问题？ → 修复标记的GDD，然后重新运行
```
/review-all-gdds
```
无测试框架？ → 运行
```
/test-setup
```
为您的引擎搭建框架
当前冲刺无QA计划？ → 运行
```
/qa-plan sprint
```
在开始实现前生成一个
缺失ADR？ → 运行
```
/architecture-decision
```
处理单个决策
无主架构文档？ → 运行
```
/create-architecture
```
生成完整蓝图
ADR缺失引擎兼容性章节？ → 重新运行
```
/architecture-decision
```
，或手动为现有ADR添加引擎兼容性章节
缺失控制清单？ → 运行
```
/create-control-manifest
```
（需已接受的ADR）

缺失Epic？ → 运行

/create-epics layer: foundation

然后

/create-epics layer: core

（需控制清单）

Epic缺失任务？ → 运行
```
/create-stories [epic-slug]
```
（每个epic创建后运行）
任务未准备好实现？ → 运行
```
/story-readiness
```
在开发者领取前验证任务就绪情况
测试失败？ → 委托给
```
lead-programmer
```
或
```
qa-tester
```
无游戏测试数据？ → 运行
```
/playtest-report
```
游戏测试会话未达最低要求以上？ → 额外的会话会提供更可靠的信号。投入全团队前建议进行3次以上。使用
```
/playtest-report
```
整理发现。

无难度曲线文档？ → 从

.claude/docs/templates/difficulty-curve.md

模板创建

design/difficulty-curve.md

——或运行

/quick-design "difficulty curve"

进行引导式会话。

无玩家旅程图？ → 从
```
.claude/docs/templates/player-journey.md
```
模板创建
```
design/player-journey.md
```
——或使用
```
/ux-design
```
第2b阶段协作撰写。
需要快速检查冲刺情况？ → 运行
```
/sprint-status
```
获取当前冲刺进度快照
性能未知？ → 运行
```
/perf-profile
```
未本地化？ → 运行
```
/localize
```
准备发布？ → 运行
```
/launch-checklist
```

Collaborative Protocol

协作协议

This skill follows the collaborative design principle:

Scan first: Check all artifacts and quality gates
Ask about unknowns: Don't assume PASS for things you can't verify
Present findings: Show the full checklist with status
User decides: The verdict is a recommendation — the user makes the final call
Get approval: "May I write this gate check report to production/gate-checks/?"
Never auto-fix: If required artifacts are missing, report the FAIL verdict and name the skill to run (e.g. "run
```
/test-setup
```
"). Do NOT create missing files or re-run the gate automatically. Creating files to manufacture a PASS defeats the gate's purpose.

Never block a user from advancing — the verdict is advisory. Document the risks and let the user decide whether to proceed despite concerns.

此技能遵循协作设计原则：

先扫描：检查所有交付物和质量门
询问未知项：对于无法验证的内容，不要假设为PASS
展示发现：展示完整的检查清单及状态
用户决策：判定结果是建议——最终由用户决定
获取批准："是否允许我将此阶段门检查报告写入production/gate-checks/?"
绝不自动修复：若缺失必需交付物，报告FAIL判定结果并指明需运行的技能（例如"运行
```
/test-setup
```
"）。不要创建缺失文件或自动重新运行阶段门。创建文件以制造PASS结果会违背阶段门的目的。

绝不阻止用户推进——判定结果仅为建议。记录风险并让用户决定是否忽略问题继续推进。