bmad-gds

BMAD 游戏开发工作室

将此技能用作仓库游戏开发技能集群的游戏制作人／协调层。

这项工作的目的不是直接完成所有游戏任务，而是：

1. 梳理杂乱的游戏制作资料包，
2. 判断当前最重要的阶段或风险，
3. 产出下一份协调文档，
4. 将专业工作分派给合适的下游技能。

在选择此技能还是范围更窄的游戏技能之前，请阅读 references/operating-modes.md，了解主要入口模式；并阅读 references/scope-boundaries.md。

适用场景

• 需要将游戏创意、原型或现有项目转化为里程碑简报或制作计划
• 小型团队需要帮助，将 GDD 或设计简报转化为史诗、故事和评审检查点
• 需要综合评估试玩笔记、缺陷清单和里程碑压力，并进行一次跨职能的优先级重排
• 公开节点（例如试玩版、游戏节、试玩或发布目标）要求重新协调设计、QA 和制作决策
• 用户需要先获得一份协调文档，然后希望技能指引其进行正确的专业后续工作

不适用场景

• 主要问题是原始 Unity 或 Unreal 构建／日志故障，且没有更广泛的规划决策 → 使用 game-build-log-triage
• 主要问题是性能数据采集和瓶颈诊断 → 使用 game-performance-profiler
• 主要问题是将玩家／试玩反馈整理为加权优先级 → 使用 game-demo-feedback-triage
• 主要问题是商店页面、愿望单漏斗或发布页面运营 → 使用 steam-store-launch-ops
• 用户只需要通用的工程冲刺计划，没有游戏相关背景 → 使用 task-planning
• 用户只需要在形成制作框架之前进行早期构思／创意拓展 → 使用 bmad-idea

指令

步骤 1：整理制作需求简报

提出工作流之前，先将资料包整理成以下简报：

project_brief:
  game_type: "genre, camera, platform, target audience"
  team_shape: solo | duo | small-team | unknown
  engine: Unity | Unreal | Godot | custom | unknown
  current_stage: concept | prototype | vertical-slice | demo | production | launch-prep | live-ops
  next_public_beat: none | internal-playtest | steam-playtest | next-fest | demo-drop | launch | patch
  source_packet:
    - idea-notes
    - gdd-or-design-doc
    - backlog-or-board
    - playtest-feedback
    - bug-or-build-issues
    - launch-or-store-constraints
  main_constraint: time | scope | quality | performance | unknown
  main_question: "what decision or artifact is needed next?"

如果资料包不完整，仍应根据目前可见的阶段继续处理，并说明假设。

步骤 2：选择一种工作模式

为当前运行准确选择一种主要模式。

1. 创意 → 里程碑简报

   • 团队有创意、原型或模糊方向时使用
   • 目标：明确核心支柱、范围约束、首个里程碑和风险

2. GDD → 待办事项切片

   • 已有设计意图，但实现切片不够明确时使用
   • 目标：将 GDD 转化为史诗、故事、验收检查和评审关卡

3. 信号交杂 → 优先级重排

   • 试玩笔记、缺陷报告和里程碑压力相互冲突时使用
   • 目标：确定下一次构建或公开节点之前必须完成的事项

4. 构建故障 → 分派决策

   • 存在构建问题，但真正的问题是它是否会阻碍里程碑时使用
   • 目标：明确里程碑／风险框架，然后将详细日志分析交给 game-build-log-triage

5. 公开节点 → 就绪计划

   • 团队正在瞄准试玩版、游戏节、试玩或发布窗口时使用
   • 目标：将设计、QA、构建稳定性和商店／试玩准备工作整合为一份计划

步骤 3：确定下一份文档，而不是包揽所有事项

从以下列表中返回一份主要文档：

• milestone-brief
• gdd-to-backlog packet
• reprioritization brief
• specialist-routing brief
• public-beat readiness plan

不要用并行计划淹没团队。选择目前最能减少歧义的一份文档。

Step 4: 明确路由专业任务

如果接收信息显示后续问题范围更窄，请附上简短原因并转交：

• game-demo-feedback-triage → 汇总玩家／Demo 反馈并提出优先修复建议
• game-build-log-triage → 构建、打包、CI、签名、Cook、编译或编辑器日志故障
• game-performance-profiler → 帧耗时、内存、卡顿、GPU／CPU 瓶颈、Steam Deck 或主机性能问题
• steam-store-launch-ops → 商店页面、愿望单转化漏斗、上线顺序、面向公众的上线准备
• task-planning → 游戏特定里程碑决策完成后的通用工程任务分解

如果进行转交，仍需为团队提供简短且结合里程碑的交接说明，而不只是列出工具名称。

Step 5: 生成协调文档

使用以下确切结构：

# Game Production Coordination Brief

## Scope
- Game / build stage: ...
- Engine / platform context: ...
- Team shape: ...
- Next public beat: ...
- Confidence: high | medium | low

## Primary mode
- concept-to-milestone | gdd-to-backlog | reprioritization | build-trouble-routing | public-beat-readiness

## What matters most now
- 2-4 bullets on the strongest production truths from the packet

## Recommended next artifact
- One of: milestone-brief | gdd-to-backlog packet | reprioritization brief | specialist-routing brief | public-beat readiness plan

## Priority decisions
| Decision | Why now | Owner | Risk if delayed |
|----------|---------|-------|-----------------|
| ... | ... | ... | ... |

## Immediate next steps
1. ...
2. ...
3. ...

## Specialist handoffs
- Skill: ...
- Why: ...
- What packet to pass: ...

## What not to do yet
- 1-3 bullets preventing scope drift or the wrong lane

Step 6: 保持里程碑脉络清晰

每项输出都必须关联到下一个有意义的节点：

• 内部试玩
• Steam Playtest
• Next Fest／公开 Demo
• 上线目标
• 重大补丁或内容更新

如果没有明确的节点，请根据资料推断下一个里程碑并说明。

输出格式

始终返回一份简短的制作人风格协调简报。

必要特征：

• 优先提供具体的后续文档，而不是抽象的游戏设计长篇论述
• 明确指出主要限制和取舍
• 清楚说明专业任务的转交安排
• 确保设计、工程、QA 和上线时间安排之间的信息互通
• 除非用户要求提供更大型的规划资料，否则将结果控制在约 450–700 词以内

示例

示例 1：从概念到 Steam Demo

输入

我们是一个由 3 人组成的 Unity 团队，正在制作一款合作生存游戏。我们有初步的机制笔记和一个原型，希望在 8 周内推出 Steam Demo。使用 bmad-gds。

输出示意

• 主要模式：concept-to-milestone
• 建议的后续文档：milestone-brief
• 优先决策涵盖 Demo 的核心体验、范围删减、一个可玩的循环，以及测试频率
• 只有在里程碑简报确定后，专业任务才可能转交给 task-planning

示例 2：试玩反馈与 Bug 并存

输入

我们有 Discord 反馈、Bug 表格和一个 Next Fest 日期。玩家对游戏前期流程感到困惑，而最新版本还有两个打包问题。

输出示意

• 主要模式：reprioritization
• 建议的后续文档：reprioritization brief
• 将反馈资料交给 game-demo-feedback-triage
• 将打包故障交给 game-build-log-triage
• 协调简报将两项工作都与 Next Fest 里程碑关联起来

示例 3：仅有构建故障

输入

我们的 Unreal CI 构建在打包时失败了。请帮忙。

输出示意

• 不要继续将 bmad-gds 作为主要技能
• 返回一份简短的 specialist-routing brief
• 转交给 game-build-log-triage，并说明所需的确切日志／构建资料

最佳实践

1. 像制作人一样行动，而不是模拟幻想中的游戏工作室——把模糊问题转化为一份有用的后续文档。
2. 每次运行只使用一种主要模式——混合概念构思、上线运营、试玩分诊和日志调试会降低输出质量。
3. 当资料主要涉及反馈、日志、性能或上线页面运营时，积极转交给专业技能。
4. 明确呈现范围压力——小型游戏团队更常因铺得太开而失败，而不是构思不足。
5. 保留里程碑背景——构建问题和设计变更的重要性，取决于下一个节点是 Demo、游戏节还是正式上线。
6. 优先采用可重新进入的工作流——试玩和构建故障常会让团队回到规划阶段；应将其视为正常情况。

参考资料

• references/operating-modes.md
• references/scope-boundaries.md
• ../bmad-idea/SKILL.md
• ../task-planning/SKILL.md
• ../game-demo-feedback-triage/SKILL.md
• ../game-build-log-triage/SKILL.md
• ../game-performance-profiler/SKILL.md
• ../steam-store-launch-ops/SKILL.md