ChildHood/.claude/skills/quality-gate-review.md

name, description

name	description
quality-gate-review	审查标准技能 — 4 道质量门标准、审查流程、强制操作清单。供 game-reviewer 子代理使用。

审查标准

本技能定义 4 道质量门的审查标准和审查后强制操作。 供 game-reviewer 子代理使用——角色完成工作后启动 reviewer 子代理，reviewer 按此标准审查。 项目管理工具操作细节参见 gitea-collab 技能。

---

审查流程

每次审查必须严格按以下流程执行：

读取交付物

• 从对应 Issue 的评论中获取产出文件路径
• 阅读交付物内容

对照质量门标准检查

• 根据交付物类型选择对应质量门（见下方 4 道质量门）

Issue 评论（强制）

• 使用 --role reviewer 操作
• 评论中标注审查者身份：审查 Agent (ai-reviewer)
• 无论通过或不通过，都必须在对应 Issue 上发布审查结论评论
• 通过：摘要 + 通过结论
• 不通过：摘要 + 具体问题清单

更新标签

• 通过：设置 review:pass 标签，移除 status:in-review
• 不通过：设置 review:fail 标签，移除 status:in-review，改为 status:blocked

返回结果给启动角色

• 不关闭 Issue（关闭决策权在用户）
• 将审查结果返回给启动你的角色，由该角色向用户汇报

---

四道质量门

质量门 1：执行案质量门

检查维度：

• 完整性：是否覆盖所有玩家可感知的行为？触发条件、表现和结束条件是否明确？
• 清晰性：有无模糊地带？程序拿到后能否不问策划就实现？
• 边界情况：异常/极端情况是否处理？
• 系统间关联：与其他系统的依赖关系是否记录？
• 技术越界检查：策划是否误入技术实现细节？参数应标注"建议值，可调"

关卡执行案附加检查（仅当执行案包含关卡文档时）：

• 关卡资产存在验证：关卡执行案中引用的 BSP 资产是否在 Content/BlockingStarterPack/ 中实际存在？逐项验证可行性

关卡执行案的质量门仅做资产存在验证。空间精度、比例、跨文档一致性等维度的准确性由程序在白模搭建过程中验证——如果程序在 Issue 中汇报了搭建异常，审查者将异常汇总并汇报给用户确认，不自行判断通过或不通过。

质量门 2：程序设计质量门

检查维度：

• 执行案覆盖度：是否逐条回应了执行案中每条行为规则？
• 美术资源需求：是否具体到尺寸、数量、触发时机？
• 架构清晰度：类/组件继承关系和挂载方式是否清晰？
• 数据流：是否明确定义？
• 技术风险：是否识别？
• 工作量与拆分建议：是否给出工作量估算？拆分方式是否合理，每个子任务可独立验证？拆分后的任务集合是否完整覆盖实现方案？

质量门 3：美术资产验收门

检查维度：

• 需求覆盖度：逐项对照美术资源需求清单
• 资产到位确认：资产文件是否在正确目录？
• 资产规格：尺寸和格式是否符合需求？
• 缺失项处理：未到位资产是否有明确处理方案？

质量门 4：程序实现验收门

检查维度：

• 设计一致性：实现是否与程序设计方案逐条一致？
• 执行案覆盖度：最终实现是否覆盖所有行为规则？
• 资产使用确认：美术资产是否正确集成？
• 偏差处理：
  • 轻微偏差（不影响核心行为）→ 记录，在复盘时同步文档
  • 重大偏差（影响核心行为）→ 建议回退或开启新版本，用户决定

---

判定规则

• 通过 → 发布通过评论 + 设置 review:pass 标签 + 返回结果（不关闭 Issue）
• 不通过 → 发布不通过评论（附问题清单）+ 设置 review:fail 标签 + 设置 status:blocked + 返回结果
• 争议 → 用户最终裁决；审查者提供明确证据和具体文档位置

---

审查后强制操作清单

审查完成后，必须逐项确认以下操作：

• 使用 --role reviewer 在对应 Issue 上发布了审查结论评论（标注审查者身份）
• 更新了 Issue 的标签（通过→review:pass，不通过→review:fail + status:blocked）
• 将审查结果返回给了启动你的角色
• 不关闭 Issue（关闭决策权在用户）
• 不通过时：评论中包含具体问题清单