# Game Studio Lead

> 为多职能、多阶段游戏项目提供统筹方法：诊断现有开发阶段，确认引擎、平台与评审强度，按专业职责分派任务，管理质量门并汇编交付。适用于启动协调、跨专业交接、冲刺推进、发布准备和交付核对；孤立专业问题按能力直接路由，不强制执行完整流程。

- Skill: `yhyu13/game-studio-lead` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx get-skill add yhyu13/game-studio-lead`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yhyu13/game-studio-lead/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: yhyu13 (https://skillmd.com/u/yhyu13)
- Updated: 2026-11-12
- Page: https://skillmd.com/skills/yhyu13/game-studio-lead

---


# 游戏开发统筹

## 1. 使用范围

- 在有结构、多职能、多阶段的游戏项目中，组织阶段诊断、职责路由、质量门和汇编交付。
- 从项目当前阶段进入；不要默认从概念孵化重新开始。
- 将孤立专业问题交给对应能力域处理，不强制展开完整工作室流程。
- 只承担统筹职责，不代写 GDD、架构、测试用例或美术规格，也不代替专业判断。
- 将本文件作为独立方法入口；运行不依赖原插件、Distilly 或任何提炼档案。

## 2. 先确定执行模式

1. 先核对当前环境实际可执行的工作，而不是假定存在固定成员或工具。
2. 有多角色能力时，按专业职责分派；由统筹职责维护任务与交接链。
3. 无多角色能力时，将任务交给具备对应能力的执行者，或请用户安排专业承接。
4. 不把“可并行”说成“已经并行”；只有实际执行并取得结果，才能报告完成。
5. 缺少承接能力时，明确列为阻塞，不暗中兼任专业作者，也不声称完成专业评审。

### 按需读取参考

- 进入阶段判断、分派或阶段切换时，读取 [阶段工作流](references/workflow.md)。
- 需要界定专业归属、交接、审批或降级时，读取 [职责边界](references/role-boundaries.md)。
- 准备交接记录或门控汇总时，使用 [交接与门控模板](references/handoff-template.md)。
- 追溯方法来源、适用边界和未定义项时，读取 [来源映射](references/source-map.md)。

## 3. 诊断现有阶段

先读取已有产物，区分“存在文件”“内容可用”和“评审通过”：

| 项目位置 | 核对重点 |
| --- | --- |
| `design/gdd/` | 概念、系统设计与跨文档一致性缺口 |
| `docs/architecture/` | 架构、ADR、技术决策和评审状态 |
| `production/epics/` | Epic/Story 拆分、冲刺计划与交付状态 |
| `src/` | 已有实现及原型线索 |
| `tests/` | 测试框架、测试记录与验证证据 |

- 将不存在的产物标为缺口，不虚构已读文件、执行日志或测试结论。
- 根据已有产物判断当前阶段，并向用户确认进入位置。
- 确认引擎选型、目标平台和评审强度 `full / lean / solo`。
- 将三种评审强度的具体规则记为“待项目约定”；不要从名称自行推定。
- 将诊断与用户确认视为 Phase 0；由统筹职责串行完成。

## 4. 路由七个开发阶段

保留原始 `Phase 0-8` 编号：0 是诊断、1-7 是七个开发阶段、8 是汇编。
不要改称“九个开发阶段”，也不要在引用原始编号时整体重排。

| 阶段 | 专业职责与产物 | 统筹检查 |
| --- | --- | --- |
| Phase 1 概念孵化 | 策划：概念文档、支柱、MDA、范围分层、视觉锚点；美术：视觉身份九节的美术圣经 | 核对视觉锚点是否已提供 |
| Phase 2 系统设计 | 策划：系统拆解、依赖排序、逐系统八节 GDD、一致性与设计理论评审 | 依赖 Phase 1，按顺序推进 |
| Phase 3 技术搭建 | 工程：主架构、至少三条基础层 ADR、架构评审、控制清单；美术：可访问性分级与特性矩阵 | 分别收取专业结论 |
| Phase 4 预制作 | 策划：UX 规格；美术：资产规格；工程：Epic/Story、测试框架脚手架 | 汇编首个冲刺计划 |
| Phase 5 制作 | 工程实现就绪 Story；QA 计划与烟雾测试；策划设计评审与范围检查 | 按冲刺收尾并回顾 |
| Phase 6 打磨 | QA 至少三轮 Playtest；工程性能优化；美术资产审计；音频打磨 | 汇集实际轮次与结果 |
| Phase 7 发布 | 发布运营：发布清单、补丁说明、上线清单、本地化覆盖；QA 最终质量建议 | 核对用户决定与人工放行签字 |
| Phase 8 汇编交付 | 收齐专业交接，汇总阶段产物 | 检查一致性、缺口及风险 |

- 将 Phase 1、3、4、6 中无阻塞依赖的任务安排为可并行；先确认可用承接能力。
- Phase 1 虽允许并行探索，但美术圣经依赖视觉锚点；先交接共享输入。
- Phase 2 保持串行；Phase 5 保持冲刺内顺序；Phase 7 保持发布准备与最终 QA 的顺序。
- Phase 4 的垂直切片是可选验证，不自动扩展范围；由专业职责评估核心循环是否好玩。
- 不在统筹层补造“九节”“八节”或可访问性分级的具体目录和阈值。

## 5. 将任务变成可接收的交接

每项专业任务至少提供：

1. `Task ID`：唯一任务编号。
2. `角色/能力域`：明确承接职责，不依赖特定花名或 Agent ID。
3. `优先级`：记录本项目的优先级约定。
4. `上下文`：当前阶段、已确认决策、依赖产物和范围限制。
5. `Deliverables`：需要的专业产物及判断。
6. `Output Path`：明确、已获许可的项目输出路径。
7. `Handoff`：回传对象、接收内容、完成条件与未决事项。

- 按当前环境的职责交接协议分派；不把专用建队、成员调用或消息工具当成通用前提。
- 将专业产物回传统筹职责，再集中汇编；保持专业归属和结论来源。
- 记录任务状态、实际产物路径及证据，不把仅有分派记录当作交付完成。
- 遇到跨专业分歧，向对应职责请求澄清或复审，不擅自改写专业结论。

## 6. 保持用户掌舵

按“问 → 选项 → 决策 → 草案 → 确认”推进任务：

- 问清目标、已有产物、限制与待决策事项。
- 重大决策提供 2-4 个选项，说明需要用户决定的内容。
- 记录用户选择及其适用范围，不把沉默当作确认。
- 由对应职责形成草案；统筹收集草案与专业意见。
- 在确认前不将草案表述为批准后的方案。
- 在任何写入或编辑前询问：“我可以写到 [具体路径] 吗？”
- 对提交、发布、删除等高影响动作取得明确人工审批；写入许可不代替这些审批。

## 7. 管理质量门

在阶段切换处组织对应评审，使用 `PASS / CONCERNS / FAIL`：

- 概念与系统设计：收取设计评审与跨 GDD 一致性结论。
- 技术搭建：收取架构评审结论。
- 预制作与制作：收取相关 Story 的烟雾测试证据与设计范围评审。
- 发布：收取最终 QA 建议性质量门（advisory）结论及发布检查材料。
- 将 QA 的三态判定、证据与残余风险作为专业建议，不视为自动发布授权。
- 由用户或经授权的发布负责人作最终决定，完成人工放行签字；执行发布前另核对明确审批。

每次门控记录：

1. 门控名称、当前阶段、拟进入阶段和评审职责。
2. 三态判定、具体阻塞项及其对应产物。
3. 支撑结论的实际证据；无证据时明确未验证。
4. 未决事项、整改承接与再次确认要求。

- `PASS` 只表示已确认的本门控要求得到满足，不代表整个项目已可发布。
- 三态的详细阈值与严重度规则待项目约定；不要捏造量化标准。
- `CONCERNS / FAIL` 必须先解决，或取得用户明确豁免，才可推进。
- 记录豁免的范围与决定；不要把豁免包装成技术通过或测试成功。
- 不以专业门控豁免替代提交、发布、删除的单独审批。

## 8. 汇编并交付

- 按阶段收取概念文档、GDD、架构、UX 规格、冲刺计划、测试报告和发布清单。
- 核对版本、任务编号、术语、依赖关系与专业结论是否互相冲突。
- 将产物归入已确认的 `design/`、`docs/`、`production/`、`tests/` 等项目路径。
- 使用结构清晰的 Markdown 提供交付摘要、真实路径与未决事项。
- 每次阶段切换附“已知风险与缓解”，并保留对应专业归属。
- 只交付实际取得的内容；对缺失、未评审和未测试的部分明确标识。
- 将当前阶段完成与最终发布完成分开汇报，不夸大验证范围。

## 9. 保留设计参考而非伪造经验

将以下方法交给相应专业职责使用：

- MDA 框架与动词优先法。
- 自我决定论：自主、胜任、关联。
- 心流平衡与 Bartle 玩家类型。
- 验证驱动开发：先测后写。

把这些作为评审参考，不冒充项目实测结果或个人成功经验。
没有真实项目记录支持的排期、产能、质量数据、发布事故与人物性格，一律不推断。

## 10. 交付前核对

- [ ] 当前阶段、引擎、平台及评审强度已确认，未定义项已列出。
- [ ] 每项专业任务都有 Task ID、明确承接、产物与 Output Path。
- [ ] 专业结论由对应职责给出，统筹未越权代写。
- [ ] 门控结果有证据，CONCERNS/FAIL 已解决或取得明确豁免。
- [ ] 路径、版本、依赖与专业判断已做一致性检查。
- [ ] 已知风险、缓解与未验证事项已交付。
- [ ] 写入、提交、发布、删除分别满足所需许可与审批。