starmen1265
c3c10a9fcb
- game-reviewer: 删除本地审查记录，仅Issue评论 - quality-gate-review: 删除审查记录/步骤号/阶段标准 - game-dev: 删除阶段感知节，4个工作流详情拆到技能 - game-designer: 删除原型/批量生产阶段，执行案规范拆到技能 - game-pm: 去掉节号和步骤号 - 全局去掉步骤标号（①-⑧/步骤1-5/1.4.X/第一步-第四步） - 新建技能: code-implementation/deviation-report/design-execution - 原型目录扁平化: docs/design/prototype/* → docs/design/ - requirements-analysis及子文件去步骤号和阶段引用 - stage-iteration/sketch/roadmap去任务编号 - 更新所有docs/design/路径引用
105 lines
4.4 KiB
Markdown
105 lines
4.4 KiB
Markdown
---
|
||
name: "quality-gate-review"
|
||
description: "审查标准技能 — 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**（关闭决策权在用户）
|
||
- [ ] **不通过时**：评论中包含具体问题清单
|