gate-check

可以将翻译结果写入 .claude/skills/gate-check/SKILL.md 吗？

---

---
name: gate-check
description: "验证项目是否准备好进入下一个开发阶段。产出 PASS/CONCERNS/FAIL 判定结果，附带具体的阻碍项和所需工件。"
argument-hint: "[目标阶段: systems-design | technical-setup | pre-production | production | polish | release]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Bash, Write
---

# 阶段关卡验证

此技能验证项目是否已准备好进入下一个开发阶段。
它会检查所需工件、质量标准和阻碍项。

**与 `/project-stage-detect` 的区别**：该技能是诊断性的（"我们在哪？"）。
本技能是规范性的（"我们准备好推进了吗？"并附带正式判定）。

## 生产阶段（7 个）

项目依次经历以下阶段：

1. **概念** — 头脑风暴、游戏概念文档
2. **系统设计** — 映射系统、编写 GDD（游戏设计文档）
3. **技术搭建** — 引擎配置、架构决策
4. **前期制作** — 原型开发、垂直切片验证
5. **正式制作** — 功能开发（Epic/Feature/Task 跟踪已激活）
6. **打磨** — 性能优化、试玩测试、缺陷修复
7. **发布** — 上线准备、平台认证

**当关卡通过时**，将新阶段名称写入 `production/stage.txt`
（单行，例如 `Production`）。这会立即更新状态栏。

---

## 1. 解析参数

- **带参数**：`/gate-check production` — 验证是否准备好进入指定阶段
- **无参数**：使用与 `/project-stage-detect` 相同的启发式方法自动检测当前阶段，
  然后验证下一个阶段转换

---

## 2. 阶段关卡定义

### 关卡：概念 → 系统设计

**所需工件：**
- [ ] `design/gdd/game-concept.md` 存在且有内容
- [ ] 游戏支柱已定义（在概念文档或 `design/gdd/game-pillars.md` 中）

**质量检查：**
- [ ] 游戏概念已经过评审（`/design-review` 判定结果非"需要重大修订"）
- [ ] 核心循环已描述且已理解
- [ ] 目标受众已确定

---

### 关卡：系统设计 → 技术搭建

**所需工件：**
- [ ] 系统索引存在于 `design/gdd/systems-index.md`，至少枚举了 MVP 系统列表
- [ ] `design/gdd/` 中至少有 1 份 GDD（game-concept.md 和 systems-index.md 之外的）

**质量检查：**
- [ ] GDD 通过设计评审（8 个必需章节齐全）
- [ ] 系统依赖关系已在系统索引中映射
- [ ] MVP 优先级层级已定义

---

### 关卡：技术搭建 → 前期制作

**所需工件：**
- [ ] 引擎已选定（CLAUDE.md 中的技术栈不再是 `[CHOOSE]`）
- [ ] 技术偏好已配置（`.claude/docs/technical-preferences.md` 已填写）
- [ ] `docs/architecture/` 中至少有 1 份架构决策记录（ADR）
- [ ] 引擎参考文档存在于 `docs/engine-reference/`

**质量检查：**
- [ ] 架构决策覆盖核心系统（渲染、输入、状态管理）
- [ ] 技术偏好已设置命名规范和性能预算

---

### 关卡：前期制作 → 正式制作

**所需工件：**
- [ ] `prototypes/` 中至少有 1 个带 README 的原型
- [ ] `production/sprints/` 中存在首个 Sprint 计划
- [ ] 系统索引中所有 MVP 层级的 GDD 均已完成

**质量检查：**
- [ ] 原型验证了核心循环假设
- [ ] Sprint 计划引用了 GDD 中的真实工作项
- [ ] 垂直切片范围已定义

---

### 关卡：正式制作 → 打磨

**所需工件：**
- [ ] `src/` 中有按子系统组织的有效代码
- [ ] GDD 中的所有核心机制已实现（交叉比对 `design/gdd/` 与 `src/`）
- [ ] 主要游玩路径可从头玩到尾
- [ ] 测试文件存在于 `tests/`
- [ ] 至少有 1 份试玩报告（或已运行 `/playtest-report`）

**质量检查：**
- [ ] 测试通过（通过 Bash 运行测试套件）
- [ ] 任何 Bug 跟踪器或已知问题中没有严重/阻断级 Bug
- [ ] 核心循环游玩效果符合设计（对照 GDD 验收标准）
- [ ] 性能在预算范围内（检查 technical-preferences.md 中的目标）

---

### 关卡：打磨 → 发布

**所需工件：**
- [ ] 里程碑计划中的所有功能已实现
- [ ] 内容已完成（设计文档中引用的所有关卡、资源、对话均已存在）
- [ ] 本地化字符串已外部化（`src/` 中无硬编码的面向玩家的文本）
- [ ] QA 测试计划已存在
- [ ] 平衡数据已经过评审（已运行 `/balance-check`）
- [ ] 发布清单已完成（已运行 `/release-checklist` 或 `/launch-checklist`）
- [ ] 商店元数据已准备（如适用）
- [ ] 更新日志/补丁说明已起草

**质量检查：**
- [ ] 完整的 QA 轮次已由 `qa-lead` 签字确认
- [ ] 所有测试通过
- [ ] 性能目标在所有目标平台上均已达成
- [ ] 无已知的严重、高或中等级别 Bug
- [ ] 无障碍基础项已覆盖（按键重映射、文本缩放等，如适用）
- [ ] 所有目标语言的本地化已验证
- [ ] 法律要求已满足（EULA、隐私政策、年龄评级等，如适用）
- [ ] 构建编译和打包正常

---

## 3. 执行关卡检查

针对目标关卡中的每一项：

### 工件检查
- 使用 `Glob` 和 `Read` 验证文件存在且有实质性内容
- 不要只检查文件是否存在 — 验证文件有真实内容（不仅仅是模板头部）
- 对于代码检查，验证目录结构和文件数量

### 质量检查
- 对于测试检查：如果配置了测试运行器，通过 `Bash` 运行测试套件
- 对于设计评审检查：`Read` GDD 并检查 8 个必需章节
- 对于性能检查：`Read` technical-preferences.md 并与 `tests/performance/` 中的
  性能分析数据或最近的 `/perf-profile` 输出进行对比
- 对于本地化检查：在 `src/` 中使用 `Grep` 搜索硬编码字符串

### 交叉引用检查
- 将 `design/gdd/` 文档与 `src/` 实现进行对比
- 检查架构文档中引用的每个系统是否有对应的代码
- 验证 Sprint 计划引用的是真实的工作项

---

## 4. 协作评估

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

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

**切勿对无法验证的项目假设为 PASS。** 将其标记为"需要人工检查"。

---

## 5. 输出判定结果

关卡检查：[当前阶段] → [目标阶段]

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

所需工件：[X/Y 项已就绪]

• design/gdd/game-concept.md — 已存在，2.4KB
• docs/architecture/ — 缺失（未找到 ADR）
• production/sprints/ — 已存在，1 个 Sprint 计划

质量检查：[X/Y 项通过]

• GDD 包含 8/8 个必需章节
• 测试 — 失败（tests/unit/ 中有 3 个失败）
• [?] 核心循环试玩 — 需要人工检查

阻碍项

1. 无架构决策记录 — 运行 /architecture-decision 创建一份 覆盖核心系统架构的 ADR，然后再进入正式制作。
2. 3 个测试失败 — 在 tests/unit/ 中修复失败的测试后再推进。

建议

• [解决阻碍项的优先操作]
• [非阻断的可选改进项]

判定：[通过 / 有顾虑 / 未通过]

• 通过：所有所需工件齐全，所有质量检查通过
• 有顾虑：存在少量差距，可在下一阶段中解决
• 未通过：必须先解决关键阻碍项才能推进

---

## 6. 通过时更新阶段

当判定为**通过**且用户确认要推进时：

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

示例：如果通过了"前期制作 → 正式制作"关卡：
```bash
echo -n "Production" > production/stage.txt

写入前务必询问："关卡已通过。是否可以将 production/stage.txt 更新为 'Production'？"

---

7. 后续行动

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

• 没有游戏概念？ → 运行 /brainstorm 创建一个
• 没有系统索引？ → 运行 /map-systems 将概念拆解为系统
• 缺少设计文档？ → 运行 /reverse-document 或委托给 game-designer
• 缺少 ADR？ → 运行 /architecture-decision
• 测试失败？ → 委托给 lead-programmer 或 qa-tester
• 没有试玩数据？ → 运行 /playtest-report
• 性能未知？ → 运行 /perf-profile
• 未本地化？ → 运行 /localize
• 准备发布？ → 运行 /launch-checklist

---

协作协议

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

1. 先扫描：检查所有工件和质量关卡
2. 询问未知项：不要对你无法验证的事项假设为通过
3. 展示发现：显示完整清单及其状态
4. 用户决定：判定仅为建议 — 由用户做出最终决定
5. 获取批准："是否可以将此关卡检查报告写入 production/gate-checks/？"

绝不阻止用户推进 — 判定仅为建议性意见。记录风险， 让用户自行决定是否在有顾虑的情况下继续推进。