gate-check

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,workflow,qa.level,testing.strict,performance.enforce,team.size,project.stage,system_overrides

已在上方解析——按原样使用；--review 会覆盖 review_mode。无阻塞项 → 默认值见 .claude/docs/config-resolution.md。

阶段门验证

此技能用于验证项目是否已准备好进入下一个开发阶段。它会检查必需的产物、质量标准和阻塞项。

与 /project-stage-detect 不同：该技能用于诊断（“我们现在处于哪个阶段？”）。 此技能用于给出指引（“我们是否已准备好进入下一阶段？”并给出正式结论）。

生产阶段（7 个）

项目将经历以下阶段：

1. 概念 — 头脑风暴、游戏概念文档
2. 系统设计 — 梳理系统、编写 GDD
3. 技术准备 — 引擎配置、架构决策
4. 预生产 — 原型制作、垂直切片验证
5. 生产 — 功能开发（Epic/Feature/Task 跟踪已启用）
6. 润色 — 性能优化、试玩、修复 Bug
7. 发布 — 发布准备、认证

阶段门通过时（或用户明确接受 CONCERNS 结论的风险时——见第 6 节），请同时更新 project.yaml 中的阶段（设置 project.stage: <new-stage>），并将新的阶段名称写入 production/stage.txt（单行，例如 Production）。双写可保持与尚未迁移的钩子的向后兼容性。此操作会立即更新状态行。

---

1. 解析参数

目标阶段： $ARGUMENTS，移除任意 --review <mode> 参数对后得到的内容（空白表示自动检测当前阶段，然后验证下一次转换）。/gate-check --review full 不会指定阶段。

注意：在 solo 模式下，会跳过导演派生流程（CD-PHASE-GATE、TD-PHASE-GATE、PR-PHASE-GATE、AD-PHASE-GATE）——gate-check 仅检查制品是否存在。在 lean 模式下，阶段门导演仍会运行（阶段门正是 lean 模式的用途）；运行多少个由下文的 workflow 设置决定。

workflow（参见 .claude/docs/workflow-modes.md）：

gate-check 在项目范围内运行，因此会使用项目级 workflow 确定整个阶段门的制品检查清单（已加载的阶段门文件），并在验证 MVP GDD 时，按系统参考 workflow_overrides.system_overrides.<system>——固定到更高层级的系统，在阶段门通过前必须满足该层级的章节数量要求，无论项目级 workflow 如何设置（见第 2b 节“按系统覆盖”）。

gate-check 遵循 workflow，但不受 automation 控制。 制品检查清单会随层级变化；协作提示协议（“协作协议”部分）始终适用——阶段门是有意设置的人工检查点，绝不会自动运行。

qa.level：控制阶段门的测试执行要求；workflow 则控制必需的制品。modes.rigor 会同时设置二者；如需单独调整测试执行要求，请显式设置 qa.level。在 minimal 下，不启用任何测试门槛——测试证据和单元测试制品项变为非必需项，第 3 节的 testing.strict 检查不执行；烟雾检查不会放宽（第 2b 节）——但在此级别下，/smoke-check 不运行游戏测试（其自动化行显示为 WAIVED），因此构建检查（如果已设置，则使用 commands.smoke，否则使用 commands.build）、启动检查和关键路径检查是最低要求——没有人启动过的构建属于未评估——没有测试的项目仍可通过。在 standard 下，Logic + Integration 测试必须通过。在 full 下，必须进行完整覆盖率检查 + 回归测试套件（如果设置了 qa.coverage_minimum，则以其作为最低覆盖率要求）。UI 和 Visual/Feel 故事所需的保留截图不属于测试项：任何 qa.level 都不会放宽这些要求（第 2b 节）。

team.size：不影响阶段门运行的导演数量——评审组规模由 workflow 轴决定（第 4b 节）。此值只影响每位导演评审时的专家深度。individual 使用核心专家组；small 使用标准专家组；studio 增加引擎子领域专家。它绝不会跳过导演——跳过导演由 review_mode 控制。review_mode 和 team.size 均由 modes.rigor 设置——一次严谨度选择会同时设置二者；显式设置时，各自仍会覆盖对应轴的值（full-rigor 项目使用 studio 专家组；较低层级使用 individual）。

• 有参数：/gate-check production——验证是否已准备好进入指定阶段

• 无参数：使用与 /project-stage-detect 相同的启发式方法自动检测当前阶段，然后在运行前向用户确认：

  使用 AskUserQuestion：

  • 提示："检测到的阶段：[当前阶段]。将运行 [当前阶段] → [下一阶段] 转换的阶段门。是否正确？"
  • 选项：
    • [A] 是 — 运行此阶段门
    • [B] 否 — 选择其他阶段门（如选择此项，则显示第二个选项控件，列出所有阶段门选项：Concept → Systems Design、Systems Design → Technical Setup、Technical Setup → Pre-Production、Pre-Production → Production、Production → Polish、Polish → Release）

  未提供参数时，切勿跳过此确认步骤。

---

2. 阶段门定义

每个阶段门的检查清单——必需的产物、质量检查以及对应工作流层级的精简项——都存放在各自的文件中。只阅读目标阶段转换对应的行；切勿加载其他文件。

阶段门	定义文件
概念 → 系统设计	references/gate-systems-design.md
系统设计 → 技术准备	references/gate-technical-setup.md
技术准备 → 预生产	references/gate-pre-production.md
预生产 → 生产	references/gate-production.md
生产 → 润色	references/gate-polish.md
润色 → 发布	references/gate-release.md

每个文件都会先说明 full 基线，然后列出该阶段门的 standard 和 minimal 精简项。应用第 1 节确定的层级。

2b. 工作流层级调整

现在阅读 references/2b-workflow-tier.md 并按其要求执行——本阶段的步骤在该文件中，不在这里。如果在本阶段期间对话经过压缩或恢复，请再次阅读。

3. 运行阶段门检查

现在阅读 references/3-run-gate-check.md 并按其要求执行——本阶段的步骤在该文件中，不在这里。如果在本阶段期间对话经过压缩或恢复，请再次阅读。

4. 协作评估

现在阅读 references/4-assessment.md 并按其要求执行——本阶段的步骤在该文件中，不在这里。如果在本阶段期间对话经过压缩或恢复，请再次阅读。

5. 输出判定结果

现在阅读 references/5-verdict.md 并按其要求执行——本阶段的步骤在该文件中，不在这里。如果在本阶段期间对话经过压缩或恢复，请再次阅读。

6. PASS 时更新阶段

现在阅读 references/6-update-stage.md 并按其要求执行——本阶段的步骤在该文件中，不在这里。如果在本阶段期间对话经过压缩或恢复，请再次阅读。

7. 收尾的后续步骤小部件

现在阅读 references/7-next-steps.md 并按其要求执行——本阶段的步骤在该文件中，不在这里。如果在本阶段期间对话经过压缩或恢复，请再次阅读。

协作流程

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

1. 先扫描：检查所有产物和质量门
2. 询问未知事项：对于无法验证的事项，不要默认判定为 PASS
3. 展示发现：显示完整的检查清单及状态
4. 由用户决定：判定结果仅为建议——用户最终决定下一步怎么做；只有阶段写入受其约束（第 6 节）
5. 取得批准：“我可以将此阶段门检查报告写入 production/gate-checks/ 吗？”
6. 绝不自动修复：如果缺少必需产物，请报告 FAIL 判定结果，并指出需要运行的技能（例如“运行 /test-setup”）。不要创建缺失文件，也不要自动重新运行阶段门检查。通过创建文件来人为制造 PASS，会违背阶段门的目的。

绝不阻止用户继续工作——判定结果只决定此技能是否写入新阶段。若判定为 CONCERNS，用户可以明确接受列出的风险后继续推进，报告会记录这一点（第 6 节）；若判定为 FAIL 或 NOT ASSESSED，则阶段保持不变，直到重新运行并通过检查；与此同时，用户仍可继续处理阻碍项。