steam-store-launch-ops

Steam 商店上线运营

将此技能用作优先处理数据包的 Steam 上线路由器。

工作不是泛泛地提供营销建议，而是：

1. 识别当前的 Steam 关注点，
2. 选择最佳的单一数据包，
3. 如实区分曝光度、承诺、证明、时机和运营，
4. 明确说明一次性 Steam 限制，
5. 如果真正的问题属于更广泛的营销、玩家反馈、构建或性能工作，则将其转交出去。

需要时阅读以下内容：

• references/intake-packets-and-route-outs.md
• references/diagnostic-model.md
• references/event-hooks.md
• references/checklists.md

何时使用此技能

• 在重要的公开节点前，审核 Steam 即将推出或已上线的商店页面
• 诊断愿望单表现不佳的问题，避免混淆流量、转化、证明和时机
• 判断演示版是否已准备好公开，或是否可能削弱信任
• 判断 Steam Next Fest 或类似公开节点是否符合实际准备情况
• 将 Steam 上线后期的压力转化为一份清单／运行手册数据包，而不是大规模重写营销内容
• 对面向 Steam 的创作者／推广准备情况进行分诊，判断下一步该采用哪个数据包

何时不使用此技能

• 主要工作是范围广泛的非游戏上线／GTM／生命周期／获客工作 → marketing-automation
• 主要工作是对玩家／演示版反馈、困惑、错误或游戏测试记录进行优先级排序 → game-demo-feedback-triage
• 主要工作是构建失败、打包失败或 CI／编辑器日志 → game-build-log-triage
• 主要工作是运行时分析、帧耗时诊断、Steam Deck 性能或平台瓶颈 → game-performance-profiler
• 主要工作是协调整个游戏项目的里程碑，而非面向 Steam 的上线／商店工作 → bmad-gds

说明

第 1 步：将请求归类为一个数据包

给出建议前，先选择最佳的单一数据包。

数据包

• page-promise-audit — 主要风险在页面转化：胶囊图、截图、预告片、简短描述、标签
• wishlist-signal-check — 用户表示愿望单表现不佳，你必须区分流量不足和转化不足
• demo-readiness-gate — 关键问题是演示版会助力还是损害当前公开节点
• event-timing-workback — 团队需要决定 Next Fest／展会／时机，并权衡准备情况
• launch-ops-runbook — 页面基本就绪，但发布时间、创作者准备情况、评测／发布控制或负责人分工仍较分散

如果请求涉及多个问题，仍要选择一个主要数据包，并指出一个次要问题。

第 2 步：收集最精简且可信的 Steam 数据包

只获取支持实际决策所需的最低限度证据：

• 当前关注点：即将推出、愿望单表现不佳、发布／更新演示版、Next Fest、上线窗口或未知
• 页面证据：URL 或截图、胶囊图、首批截图、简短描述、标签
• 证明证据：预告片链接／开场说明、演示版状态、公开构建的可信度
• 信号背景：流量不足、转化不足、两者都不明确或未知
• 时机背景：节日截止日期、上线目标、演示版时间、评测／发布限制
• 运营背景：创作者／媒体资料、密钥／推广、负责人缺失、上线清单缺项

如果证据有限，保持较低置信度，并选择风险最低且范围最小的数据包。

第 3 步：确定主要瓶颈

使用现有的诊断模型，但只保留一个主要瓶颈。

主要瓶颈

• visibility-acquisition
• promise-clarity
• proof-demo-readiness
• timing-hook-fit
• launch-ops-readiness
• evidence-gap

典型对应关系：

• “愿望单数量和流量都很低” → visibility-acquisition
• “有些人点进页面，但没有加入愿望单” → promise-clarity
• “页面还可以，但演示可能不够完善” → proof-demo-readiness
• “我们应该现在参加 Next Fest，还是再等等？” → timing-hook-fit
• “我们快要发布了，但素材和清单显得杂乱无章” → launch-ops-readiness
• “我们几乎没有证据” → evidence-gap

第 4 步：应用 Steam 一次性规则

在提出任何建议之前，先检查容易忽略的限制：

• 发布前公开演示版的前提是基础游戏页面已设为“即将推出”并公开可见
• 首次公开发布演示版时，向愿望单用户和关注者发送通知的机会有限，且只有一次
• 参加 Next Fest 需要有公开页面、在活动开始前已公开推出可游玩的演示版，以及当前有效的商店素材
• Steam 的审核和发布仍涉及人工安排和风险；不要假设一切都会自动完成

如果建议会把这些关键机会之一用在准备不足的内容上，请直接说明。

第 5 步：选择对应方案的干预措施

选用一个方案和一项干预措施。

page-promise-audit

当页面内容可能是瓶颈时使用。

重点关注：

• 胶囊图是否清晰易读
• 截图的排列顺序和玩法证明
• 预告片的开场
• 简短描述是否具体
• 标签是否一致

合适的后续交付物：

• page rewrite brief
• screenshot reorder brief
• trailer hook brief
• tag audit

wishlist-signal-check

当团队对不理想的愿望单结果过度拟合时使用。

重点关注：

• 流量低，还是转化率低
• 页面内容是否真正符合对目标受众的承诺
• 演示或证明是否缺失或薄弱
• 愿望单问题背后是否隐藏着时机或活动问题

合适的后续交付物：

• wishlist signal memo
• page rewrite brief
• visibility push check
• demo readiness checklist

demo-readiness-gate

当演示版是公开证明的关键问题时使用。

重点关注：

• 演示版能否增强信任
• 首次游玩体验是否符合页面当前的承诺
• 通知或活动机会是否用得过早
• 更好的做法是打磨、延期、缩小本次重点，还是继续推进

合适的后续交付物：

• demo readiness checklist
• proof-gap notes
• event timing memo

event-timing-workback

当主要决策是某个公开活动节点是否符合实际准备情况时使用。

重点关注：

• 是否适合参加 Next Fest 或其他展示活动
• 页面、预告片、标签和演示版整体是否准备就绪
• 是否把活动当作准备度门槛，还是一厢情愿地指望借此获得曝光
• 截止日期前需要立即完成的倒排计划任务

合适的后续交付物：

• Next Fest runbook
• event timing decision memo
• asset lock checklist

launch-ops-runbook

当核心页面和演示版基本可接受，但发布执行工作仍然零散时使用。

重点关注：

• 审核和发布时间安排
• 创作者和媒体准备情况，以及密钥和外联资料包的管理
• 职责分配缺口
• 发布日清单和应急方案

合适的后续交付物：

• launch checklist
• launch-day runbook
• creator/outreach prep packet

第 6 步：在范围偏移前转交

遇到以下情况时，应转交，而不是接手相邻工作：

• 用户需要的是超出 Steam 上线／商店页面工作的广泛获客、内容、生命周期或衡量策略 → marketing-automation
• 证据主要是试玩反馈、用户困惑或褒贬不一的 Demo 反馈 → game-demo-feedback-triage
• 问题是单个构建损坏、打包失败或 CI／编辑器日志 → game-build-log-triage
• 真正的阻碍是运行时性能、Steam Deck、帧耗时或平台瓶颈 → game-performance-profiler
• 工作涉及更广泛的里程碑协调、里程碑风险或制作人式的排期 → bmad-gds

值得信赖的入口会缩小下一步行动的范围，而不会声称能处理所有相邻的游戏营销工作。

第 7 步：交付一份 Steam 上线方案包

交付一份简洁的方案包，而不是长篇大论。

# Steam Launch Packet

## Packet choice
- Primary packet: page-promise-audit | wishlist-signal-check | demo-readiness-gate | event-timing-workback | launch-ops-runbook
- Secondary concern: optional
- Current hook: ...
- Confidence: high | medium | low

## Evidence used
- Page / asset evidence: ...
- Demo / proof evidence: ...
- Signal context: ...
- Timing / ops context: ...
- Missing but important: ...

## Primary bottleneck
- Bucket: visibility-acquisition | promise-clarity | proof-demo-readiness | timing-hook-fit | launch-ops-readiness | evidence-gap
- Why it matters now: ...
- Evidence: ...

## Recommended intervention
- One intervention: ...
- Why this is the shortest credible move: ...

## Priority checks
1. ...
2. ...
3. ...

## Recommended next artifact
- Choose one: page rewrite brief | screenshot reorder brief | trailer hook brief | tag audit | wishlist signal memo | visibility push check | demo readiness checklist | event timing decision memo | Next Fest runbook | asset lock checklist | launch checklist | launch-day runbook | creator/outreach prep packet

## Route-outs
- Skill: ...
- Why: ...
- Packet to pass: ...

## What not to do yet
- 1-3 bullets that prevent folklore, wasted spend, or premature scope drift

第 8 步：定稿前确认边界

检查：

• 你是否选择了一种方案包，而不是把页面审查、Demo QA、外联 CRM 和广泛的 GTM 策略混在一起？
• 你是否在提出页面修改建议前，区分了流量不足与转化不足？
• 你是否将 Demo 和 Next Fest 视为就绪度门槛，而非免费的通用曝光机会？
• 在需要时，你是否明确说明了单次机会的时间安排／评审限制？
• 你是否将反馈、构建或性能相关工作转交出去，而不是扩大本技能的范围？

输出格式

始终返回一份简短的 Steam 上线方案包。

必须满足以下要求：

• 一份主要方案包
• 一个主要瓶颈
• 一份下一步产出物
• 证据不足时明确说明不确定性
• 真正的工作属于其他领域时进行转交
• 不要写冗长、泛泛而谈的营销说教

示例

示例 1：愿望单数量偏低，但有一定流量

输入

我们的 Steam 页面能从社交媒体帖子获得点击，但愿望单数量仍然不理想。请审查我们的胶囊图、截图、简短描述和标签。

理想的回复方向

• 方案包：wishlist-signal-check
• 瓶颈：可能是 promise-clarity
• 下一步产出物：page rewrite brief 或 screenshot reorder brief
• 不要假定问题只在流量

示例 2：是否参加 Next Fest

输入

我们想参加 Next Fest。页面已经上线，预告片也还不错，但我担心 Demo 还有些粗糙。

理想的回复方向

• 方案包：event-timing-workback 或 demo-readiness-gate
• 瓶颈：proof-demo-readiness
• 指出 Next Fest 是就绪度门槛
• 下一步产出物：demo readiness checklist 或 Next Fest runbook

示例 3：索要上线清单

输入

给我一份 Steam 上线清单。我们已经有页面、预告片、Demo 和一份规模不大的创作者名单。

理想的回复方向

• 方案包：launch-ops-runbook
• 瓶颈：launch-ops-readiness
• 下一步产出物：launch checklist 或 launch-day runbook
• 仅在上线运营范围内涉及页面转化和创作者准备工作，不要扩展成完整的 GTM 改写

最佳实践

1. 先选择方案包——入口应立即缩小任务范围。
2. 区分有效信号与不实之谈——愿望单、Demo 和 Next Fest 都容易招来错误的默认建议。
3. 将 Demo 视为面向公众的证明——而不只是另一项素材。
4. 将 Steam 的时间安排视为约束系统——Coming Soon、Demo 通知时间、评审／发布和 Next Fest 都很重要。
5. 优先提供一份下一步产出物，而不是倾倒冗长的上线理论。
6. 聚焦 Steam——这是仓库中针对游戏上线的例外，不是通用营销包装。

参考资料

• Steamworks 文档 — Steam 上的曝光度
• Steamworks 文档 — Coming Soon
• Steamworks 文档 — Demo
• Steamworks 文档 — Steam Next Fest
• Steamworks 文档 — 发布流程