--- name: "quality-gate-review" description: "质量门审查技能 — 4 道质量门标准、阶段对应标准、审查流程、强制操作清单" --- # 质量门审查 > 本技能定义 4 道质量门的审查标准、阶段对应标准和审查后强制操作。 > 供 game-reviewer agent、game-pm agent 及各工种自审使用。 > 项目管理工具操作细节参见 `.claude/skills/gitea-collab.md`。 --- ## 审查流程 每次质量门审查必须严格按以下步骤执行: ### 1. 读取交付物 - 从对应 Issue 的评论中获取产出文件路径 - 阅读交付物内容 ### 2. 对照质量门标准检查 - 根据交付物类型选择对应质量门(见下方 4 道质量门) - 根据当前开发阶段选择对应标准(原型 vs 批量生产,见"阶段对应标准") ### 3. 写审查记录(本地文件) - 路径:`docs/plans/reviews/-审查记录.md` - 格式见下方"审查记录格式" ### 4. Issue 评论(强制) - **无论通过或不通过,都必须在对应 Issue 上发布审查结论评论** - 通过:摘要 + 通过结论 - 不通过:摘要 + 具体问题清单 ### 5. 更新标签 - 通过:设置 `gate:*-pass` 标签,移除 `gate:*-fail`(如有) - 不通过:设置 `gate:*-fail` 标签,移除 `gate:*-pass`(如有) ### 6. 通过时关闭 Issue(强制) - **审查通过时必须关闭 Issue**,附完成说明 - 不通过时 Issue 保持打开,等待修改 --- ## 四道质量门 ### 质量门 1:执行案质量门(③→④) 检查维度: - **完整性**:是否覆盖所有玩家可感知的行为?触发条件、表现和结束条件是否明确? - **清晰性**:有无模糊地带?程序拿到后能否不问策划就实现? - **边界情况**:异常/极端情况是否处理? - **系统间关联**:与其他系统的依赖关系是否记录? - **技术越界检查**:策划是否误入技术实现细节?参数应标注"建议值,可调" **关卡执行案附加检查**(仅当执行案包含关卡文档时): - **关卡资产存在验证**:关卡执行案中引用的 BSP 资产是否在 `Content/BlockingStarterPack/` 中实际存在?逐项验证可行性 > 关卡执行案的质量门**仅做资产存在验证**。空间精度、比例、跨文档一致性等维度的准确性由程序在白模搭建过程中验证——如果程序在 Issue 中汇报了搭建异常,审查者将异常汇总并汇报给用户确认,不自行判断通过或不通过。 标签:`gate:execution-pass` / `gate:execution-fail` ### 质量门 2:程序设计质量门(④→⑤) 检查维度: - **执行案覆盖度**:是否逐条回应了执行案中每条行为规则? - **美术资源需求**:是否具体到尺寸、数量、触发时机? - **架构清晰度**:类/组件继承关系和挂载方式是否清晰? - **数据流**:是否明确定义? - **技术风险**:是否识别? - **工作量与拆分建议**:是否给出工作量估算?拆分方式是否合理,每个子任务可独立验证?拆分后的任务集合是否完整覆盖实现方案? 标签:`gate:tech-pass` / `gate:tech-fail` ### 质量门 3:美术资产验收门(⑤→⑥) 检查维度: - **需求覆盖度**:逐项对照美术资源需求清单 - **资产到位确认**:资产文件是否在正确目录? - **资产规格**:尺寸和格式是否符合需求? - **缺失项处理**:未到位资产是否有明确处理方案? 标签:`gate:art-pass` / `gate:art-fail` ### 质量门 4:程序实现验收门(⑥→⑦) 检查维度: - **设计一致性**:实现是否与程序设计方案逐条一致? - **执行案覆盖度**:最终实现是否覆盖所有行为规则? - **资产使用确认**:美术资产是否正确集成? - **偏差处理**: - **轻微偏差**(不影响核心行为)→ 记录,在⑦复盘时同步文档 - **重大偏差**(影响核心行为)→ 建议回退到③或开启新版本,用户决定 标签:`gate:impl-pass` / `gate:impl-fail` --- ## 阶段对应标准 | 维度 | 原型阶段 | 批量生产阶段 | |------|---------|------------| | 完整性 | 核心行为必须完整,非核心可略过 | 全部必须完整 | | 边界情况 | 影响核心玩法的必须处理 | 全部必须处理 | | 美术资产 | 允许占位资源 | 正式资产,必须符合规格 | | 代码质量 | 允许硬编码,快速实现 | 不允许硬编码,数据驱动,发布标准 | --- ## 判定规则 - **通过** → 发布通过评论 + 设置 pass 标签 + **关闭 Issue** - **不通过** → 发布不通过评论(附问题清单)+ 设置 fail 标签 + Issue 保持打开 - **争议** → 用户最终裁决;审查者提供明确证据和具体文档位置 --- ## 审查记录格式 文件路径:`docs/plans/reviews/-审查记录.md` ```markdown # [任务 ID] 审查报告 **审查日期**:[日期] **审查对象**:[任务名] — [产出文档路径] **宏观阶段**:[原型 / 批量生产] **质量门类型**:[执行案 / 程序设计 / 美术资产 / 程序实现] ## 检查结果 | 检查项 | 结果 | 说明 | |--------|------|------| | [检查项] | ✅/❌ | [详情] | ## 判定 **通过 / 不通过** — [一句话总结] ## 问题清单(不通过时) 1. [具体问题,附文档位置引用] ``` --- ## 审查后强制操作清单 审查完成后,**必须**逐项确认以下操作: - [ ] 在 `docs/plans/reviews/-审查记录.md` 写了审查记录 - [ ] 在对应 Issue 上发布了审查结论评论(通过/不通过 + 摘要) - [ ] 更新了 Issue 的 gate:* 标签(通过→pass,不通过→fail) - [ ] **通过时**:关闭 Issue 并附完成说明 - [ ] **不通过时**:评论中包含具体问题清单,Issue 保持打开