steam-store-launch-ops

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Steam Store Launch Ops

Steam商店发布运营

Use this skill as a packet-first Steam launch router.

The job is not to dump generic marketing advice. The job is to:

identify the current Steam hook,
choose the single best packet,
separate visibility, promise, proof, timing, and ops honestly,
make one-shot Steam constraints explicit,
route broader marketing, player-feedback, build, or performance work outward when those are the real problems.

Read these when needed:

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

将本技能用作以数据包为核心的Steam发布路由工具。

核心任务并非提供泛泛的营销建议，而是：

识别当前Steam运营切入点，
选择最适合的单一数据包，
清晰区分曝光度、承诺可信度、产品证明、时间规划和运营工作，
明确Steam一次性运营约束条件，
当核心问题属于更广域的营销、玩家反馈、构建或性能问题时，将工作转交给对应工具处理。

必要时可参考以下文档：

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

When to use this skill

适用场景

Review a Steam Coming Soon or live store page before a meaningful public beat
Diagnose weak wishlist complaints without confusing traffic, conversion, proof, and timing
Decide whether a demo is ready for public exposure or likely to weaken trust
Decide whether a Steam Next Fest or similar public beat fits actual readiness
Turn late-stage Steam launch stress into one checklist/runbook packet instead of a giant marketing rewrite
Triage Steam-facing creator/outreach readiness only far enough to choose the right next packet

在重要公开节点前审核Steam即将推出或已上线的商店页面
诊断愿望单数据不佳问题，区分流量不足与转化不足的原因
判断Demo是否准备好面向公众，或是可能损害用户信任
判断Steam Next Fest或类似公开活动是否符合当前项目就绪状态
将后期Steam发布压力转化为单一清单/运营手册数据包，而非大规模重写营销方案
仅针对Steam相关的创作者/推广就绪状态进行初步分类，以选择合适的下一个数据包

When not to use this skill

不适用场景

The main job is broad non-game launch/GTM/lifecycle/acquisition work →
```
marketing-automation
```
The main job is prioritizing player/demo feedback, confusion, bugs, or playtest notes →
```
game-demo-feedback-triage
```
The main job is a red build, packaging failure, or CI/editor log →
```
game-build-log-triage
```
The main job is runtime profiling, frame-time diagnosis, Steam Deck perf, or platform bottlenecks →
```
game-performance-profiler
```
The main job is milestone coordination across the whole game project rather than Steam-facing launch/store work →
```
bmad-gds
```

核心工作是广义的非游戏发布/GTM/生命周期/用户获取工作 → 转交给
```
marketing-automation
```
核心工作是优先处理玩家/Demo反馈、用户困惑、Bug或测试笔记 → 转交给
```
game-demo-feedback-triage
```
核心工作是构建失败、打包错误或CI/编辑器日志问题 → 转交给
```
game-build-log-triage
```
核心工作是运行时性能分析、帧时间诊断、Steam Deck性能或平台瓶颈问题 → 转交给
```
game-performance-profiler
```
核心工作是整个游戏项目的里程碑协调，而非Steam相关的发布/商店工作 → 转交给
```
bmad-gds
```

Instructions

操作步骤

Step 1: Classify the request into one packet

步骤1：将请求归类到单一数据包

Choose the single best packet before giving advice.

Packets

```
page-promise-audit
```
— the main risk is page conversion: capsule, screenshots, trailer, short description, tags
```
wishlist-signal-check
```
— the user says wishlists are weak and you must separate traffic weakness from conversion weakness
```
demo-readiness-gate
```
— the key question is whether the demo helps or hurts the current public beat
```
event-timing-workback
```
— the team needs a Next Fest / showcase / timing decision with readiness tradeoffs
```
launch-ops-runbook
```
— the page is mostly set, but release timing, creator readiness, review/release controls, or ownership are scattered

If the request mixes several concerns, still choose one primary packet and name one secondary concern.

在给出建议前，选择最适合的单一数据包。

数据包类型

```
page-promise-audit
```
— 核心风险为页面转化率：胶囊图、截图、预告片、简短描述、标签
```
wishlist-signal-check
```
— 用户反馈愿望单数据不佳，需区分流量不足与转化不足
```
demo-readiness-gate
```
— 核心问题是Demo对当前公开节点的利弊影响
```
event-timing-workback
```
— 团队需要针对Next Fest/展示活动/时间规划做出决策，并权衡就绪状态
```
launch-ops-runbook
```
— 页面基本就绪，但发布时间、创作者准备情况、审核/发布控制或所有权问题较为分散

若请求包含多个关注点，仍需选择一个主数据包，并注明一个次要关注点。

Step 2: Capture the smallest credible Steam packet

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

Pull only the minimum evidence that supports a real decision:

current hook: Coming Soon, weak wishlists, demo publish/update, Next Fest, launch window, or unknown
page evidence: URL or screenshots, capsule, first screenshots, short description, tags
proof evidence: trailer link/opening notes, demo status, public-build confidence
signal context: traffic weak, conversion weak, both unclear, or unknown
timing context: festival deadline, launch target, demo timing, review/release constraints
ops context: creator/press materials, keys/outreach, ownership gaps, launch checklist gaps

If the evidence is thin, keep confidence low and choose the smallest safe packet.

仅收集支持实际决策的最少证据：

当前切入点：即将推出、愿望单数据不佳、Demo发布/更新、Next Fest、发布窗口期或未知
页面证据：URL或截图、胶囊图、首屏截图、简短描述、标签
产品证明证据：预告片链接/开场说明、Demo状态、公开版本可信度
信号背景：流量不足、转化不足、两者不明或未知
时间背景：活动截止日期、发布目标、Demo时间、审核/发布约束
运营背景：创作者/媒体素材、激活码/推广资源、所有权缺口、发布清单缺口

若证据不足，需降低可信度，并选择最稳妥的最小数据包。

Step 3: Name the primary bottleneck

步骤3：确定核心瓶颈

Use the existing diagnostic model, but keep one primary bottleneck.

Primary bottlenecks

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

Typical mappings:

"Wishlists are weak and traffic is weak too" →
```
visibility-acquisition
```
"Some people click through but do not wishlist" →
```
promise-clarity
```
"The page is okay but the demo may be rough" →
```
proof-demo-readiness
```
"Should we do Next Fest now or wait?" →
```
timing-hook-fit
```
"We are near launch and materials/checklists feel scattered" →
```
launch-ops-readiness
```
"We barely have evidence" →
```
evidence-gap
```

使用现有诊断模型，但仅明确一个核心瓶颈。

核心瓶颈类型

```
visibility-acquisition
```
（曝光度获取）
```
promise-clarity
```
（承诺清晰度）
```
proof-demo-readiness
```
（产品证明-Demo就绪度）
```
timing-hook-fit
```
（时间-切入点匹配度）
```
launch-ops-readiness
```
（发布运营就绪度）
```
evidence-gap
```
（证据缺口）

典型对应关系：

“愿望单数据不佳且流量也不足” →
```
visibility-acquisition
```
“有用户点击但未添加愿望单” →
```
promise-clarity
```
“页面没问题但Demo可能不够完善” →
```
proof-demo-readiness
```
“我们现在应该参加Next Fest还是再等等？” →
```
timing-hook-fit
```
“临近发布，但素材/清单较为零散” →
```
launch-ops-readiness
```
“我们几乎没有相关证据” →
```
evidence-gap
```

Step 4: Apply the one-shot Steam rules

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

Before recommending anything, check the constraints that are easy to miss:

a pre-release public demo depends on the base game page already being visible as Coming Soon
the first public demo release gets a limited one-shot notify window to wishlisters/followers
Next Fest requires a public page, a publicly playable demo by the event start, and current store assets
Steam review and release still carry manual timing/risk; do not assume everything is automatic

If the recommendation would spend one of these beats on a weak package, say so directly.

在给出任何建议前，检查容易被忽略的约束条件：

预发布公开Demo依赖于“即将推出”状态的游戏主页面已具备曝光度
首次公开Demo发布仅能获得一次向愿望单用户/关注者推送通知的窗口期
参加Next Fest需要公开页面、活动开始前可公开游玩的Demo，以及当前商店素材
Steam审核和发布仍存在手动时间安排/风险，不要假设一切都是自动完成的

若建议会在准备不足的情况下消耗上述节点资源，需直接说明。

Step 5: Choose the packet-specific intervention

步骤5：选择数据包对应的干预措施

Use one packet and one intervention.

使用单一数据包和单一干预措施。

page-promise-audit

page-promise-audit

Use when the page package is the likely bottleneck.

Focus on:

capsule readability
screenshot ordering and gameplay proof
trailer opening
short-description specificity
tag coherence

Good next artifacts:

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

当页面内容是核心瓶颈时使用。

重点关注：

胶囊图可读性
截图排序与游戏玩法展示
预告片开场
简短描述的明确性
标签一致性

推荐产出物：

```
page rewrite brief
```
（页面重写简报）
```
screenshot reorder brief
```
（截图重排简报）
```
trailer hook brief
```
（预告片开场简报）
```
tag audit
```
（标签审核）

wishlist-signal-check

wishlist-signal-check

Use when the team is overfitting to weak wishlist results.

Focus on:

low traffic vs weak conversion
whether the page package actually matches the audience promise
whether the demo/proof is missing or weak
whether a timing/event problem is hiding inside the wishlist complaint

Good next artifacts:

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

当团队过度关注愿望单数据不佳问题时使用。

重点关注：

流量不足 vs 转化不足
页面内容是否与目标受众的期望匹配
Demo/产品证明是否缺失或不足
愿望单数据问题是否隐藏着时间/活动安排问题

推荐产出物：

```
wishlist signal memo
```
（愿望单信号备忘录）
```
page rewrite brief
```
（页面重写简报）
```
visibility push check
```
（曝光度提升检查）
```
demo readiness checklist
```
（Demo就绪清单）

demo-readiness-gate

demo-readiness-gate

Use when the demo is the public proof question.

Focus on:

whether the demo strengthens trust
whether first-session quality matches the current page promise
whether the notify/event timing is being spent too early
whether the better move is polish, delay, narrow the beat, or proceed

Good next artifacts:

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

当Demo是核心产品证明问题时使用。

重点关注：

Demo是否能增强用户信任
首次体验质量是否与当前页面承诺一致
通知/活动时间是否过早
更优方案是打磨、推迟、缩小节点范围还是继续推进

推荐产出物：

```
demo readiness checklist
```
（Demo就绪清单）
```
proof-gap notes
```
（产品证明缺口记录）
```
event timing memo
```
（活动时间备忘录）

event-timing-workback

event-timing-workback

Use when the main decision is whether a public beat fits actual readiness.

Focus on:

Next Fest or showcase fit
page/trailer/tag/demo readiness as a set
whether the event is being treated as a readiness gate or wishful discovery play
immediate workback tasks before the deadline

Good next artifacts:

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

当核心决策是公开节点是否符合实际就绪状态时使用。

重点关注：

Next Fest或展示活动的适配性
页面/预告片/标签/Demo的整体就绪状态
活动是否被视为就绪验证节点还是盲目曝光尝试
截止日期前的紧急倒推任务

推荐产出物：

```
Next Fest runbook
```
（Next Fest运营手册）
```
event timing decision memo
```
（活动时间决策备忘录）
```
asset lock checklist
```
（素材锁定清单）

launch-ops-runbook

launch-ops-runbook

Use when the core page/demo are mostly acceptable, but launch execution is fragmented.

Focus on:

review/release timing
creator/press readiness and key/outreach packet hygiene
ownership gaps
launch-day checklist and contingency points

Good next artifacts:

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

当核心页面/Demo基本就绪，但发布执行工作较为零散时使用。

重点关注：

审核/发布时间安排
创作者/媒体准备情况及激活码/推广资源的规范性
所有权缺口
发布当日清单及应急要点

推荐产出物：

```
launch checklist
```
（发布清单）
```
launch-day runbook
```
（发布当日运营手册）
```
creator/outreach prep packet
```
（创作者/推广准备数据包）

Step 6: Add route-outs before scope drifts

步骤6：在范围扩大前转交给对应工具

Route out instead of absorbing adjacent work when:

the user needs broad acquisition/content/lifecycle/measurement strategy beyond Steam-facing launch/store work →
```
marketing-automation
```
the evidence is mostly playtest quotes, user confusion, or mixed demo feedback →
```
game-demo-feedback-triage
```
the issue is one broken build, packaging failure, or CI/editor log →
```
game-build-log-triage
```
the real blocker is runtime perf, Steam Deck, frame-time, or platform bottlenecks →
```
game-performance-profiler
```
the work is broader milestone coordination, milestone risk, or producer-style sequencing →
```
bmad-gds
```

A trustworthy front door narrows the next move. It does not claim every neighboring game-marketing job.

当出现以下情况时，应转交工作而非纳入当前范围：

用户需要Steam发布/商店工作之外的广义用户获取/内容/生命周期/数据策略 → 转交给
```
marketing-automation
```
证据主要为测试反馈、用户困惑或Demo混合反馈 → 转交给
```
game-demo-feedback-triage
```
问题为构建失败、打包错误或CI/编辑器日志 → 转交给
```
game-build-log-triage
```
核心障碍为运行时性能、Steam Deck性能、帧时间或平台瓶颈 → 转交给
```
game-performance-profiler
```
工作为更广域的里程碑协调、里程碑风险或制作人式任务排序 → 转交给
```
bmad-gds
```

可靠的入口工具应缩小下一步工作范围，而非包揽所有相关游戏营销工作。

Step 7: Return one Steam launch packet

步骤7：返回一份Steam发布数据包

Return one concise packet, not a giant essay.

markdown

undefined

返回一份简洁的数据包，而非长篇大论。

markdown

undefined

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

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: ...

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: ...

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: ...

One intervention: ...
Why this is the shortest credible move: ...

Priority checks

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

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: ...

Skill: ...
Why: ...
Packet to pass: ...

What not to do yet

1-3 bullets that prevent folklore, wasted spend, or premature scope drift

undefined

1-3 bullets that prevent folklore, wasted spend, or premature scope drift

undefined

Step 8: Verify the boundary before finalizing

步骤8：最终确认前验证边界

Check:

did you pick one packet instead of mixing page audit, demo QA, outreach CRM, and broad GTM strategy together?
did you separate traffic weakness from conversion weakness before prescribing page changes?
did you treat demos and Next Fest as readiness gates rather than generic visibility freebies?
did you make one-shot timing/review constraints visible when they matter?
did you route feedback/build/perf work outward instead of stretching this skill?

检查以下内容：

是否选择了单一数据包，而非混合页面审核、Demo测试、推广CRM和广义GTM策略？
是否在提出页面修改建议前区分了流量不足与转化不足？
是否将Demo和Next Fest视为就绪验证节点，而非泛泛的免费曝光机会？
是否在关键节点明确了一次性时间/审核约束？
是否将反馈/构建/性能工作转交给对应工具，而非扩大本技能的范围？

Output format

输出格式

Always return a short Steam Launch Packet.

Required qualities:

one primary packet
one primary bottleneck
one next artifact
explicit uncertainty when evidence is thin
route-outs when the real job belongs elsewhere
no giant generic marketing sermon

始终返回一份简洁的Steam发布数据包。

必备特性：

一个主数据包
一个核心瓶颈
一个下阶段产出物
证据不足时明确标注不确定性
核心工作归属其他工具时注明转交方向
无冗长的泛泛营销说教

Examples

示例

Example 1: weak wishlists with some traffic

示例1：有流量但愿望单数据不佳

Input

Our Steam page gets clicks from social posts, but wishlists are still weak. Review our capsule, screenshots, short description, and tags.

Good response direction

packet:
```
wishlist-signal-check
```
bottleneck: likely
```
promise-clarity
```

next artifact:

page rewrite brief

screenshot reorder brief

avoids pretending traffic is the only issue

输入

我们的Steam页面从社交帖子获得点击，但愿望单数据仍然不佳。请审核我们的胶囊图、截图、简短描述和标签。

推荐响应方向

数据包：
```
wishlist-signal-check
```
瓶颈：可能为
```
promise-clarity
```

下阶段产出物：

page rewrite brief

或

screenshot reorder brief

避免假设流量是唯一问题

Example 2: Next Fest decision

示例2：Next Fest决策

Input

We want to do Next Fest. The page is up and the trailer is decent, but I am nervous the demo is still rough.

Good response direction

packet:

event-timing-workback

demo-readiness-gate

bottleneck:
```
proof-demo-readiness
```
calls out that Next Fest is a readiness gate

next artifact:

demo readiness checklist

Next Fest runbook

输入

我们想参加Next Fest。页面已上线，预告片质量尚可，但我担心Demo仍不够完善。

推荐响应方向

数据包：

event-timing-workback

或

demo-readiness-gate

瓶颈：
```
proof-demo-readiness
```
明确指出Next Fest是就绪验证节点

下阶段产出物：

demo readiness checklist

或

Next Fest runbook

Example 3: launch checklist ask

示例3：请求发布清单

Input

Give me a Steam launch checklist. We have a page, trailer, demo, and a small creator list.

Good response direction

packet:
```
launch-ops-runbook
```
bottleneck:
```
launch-ops-readiness
```
next artifact:
```
launch checklist
```
or
```
launch-day runbook
```
keeps page conversion and creator prep in scope only as launch ops, not a full GTM rewrite

输入

给我一份Steam发布清单。我们已有页面、预告片、Demo和少量创作者名单。

推荐响应方向

数据包：
```
launch-ops-runbook
```
瓶颈：
```
launch-ops-readiness
```
下阶段产出物：
```
launch checklist
```
或
```
launch-day runbook
```
仅将页面转化和创作者准备作为发布运营工作纳入范围，而非全面重写GTM方案

Best practices

最佳实践

Choose the packet first — the front door should narrow the task immediately.
Separate signal from folklore — wishlists, demos, and Next Fest all attract bad default advice.
Treat the demo as public proof — not just another asset.
Treat Steam timing as a constraint system — Coming Soon, demo notify timing, review/release, and Next Fest all matter.
Prefer one next artifact over a giant launch theory dump.
Stay Steam-specific — this is the repo’s game-launch exception, not a generic marketing wrapper.

先选择数据包 — 入口工具应立即缩小任务范围。
区分信号与固有认知 — 愿望单、Demo和Next Fest常伴随错误的默认建议。
将Demo视为公开产品证明 — 而非仅仅是另一项素材。
将Steam时间规划视为约束系统 — 即将推出、Demo通知时间、审核/发布和Next Fest都至关重要。
优先选择单一下阶段产出物 — 而非输出冗长的发布理论。
专注Steam相关工作 — 这是本仓库中游戏发布的专项工具，而非泛泛的营销包装。

steam-store-launch-ops

Original

Translation

Steam Store Launch Ops

Steam商店发布运营

When to use this skill

适用场景

When not to use this skill

不适用场景

Instructions

操作步骤

Step 1: Classify the request into one packet

步骤1：将请求归类到单一数据包

Step 2: Capture the smallest credible Steam packet

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

Step 3: Name the primary bottleneck

步骤3：确定核心瓶颈

Step 4: Apply the one-shot Steam rules

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

Step 5: Choose the packet-specific intervention

步骤5：选择数据包对应的干预措施

page-promise-audit

page-promise-audit

wishlist-signal-check

wishlist-signal-check

demo-readiness-gate

demo-readiness-gate

event-timing-workback

event-timing-workback

launch-ops-runbook

launch-ops-runbook

Step 6: Add route-outs before scope drifts

步骤6：在范围扩大前转交给对应工具

Step 7: Return one Steam launch packet

步骤7：返回一份Steam发布数据包

Steam Launch Packet

Steam Launch Packet

Packet choice

Packet choice

Evidence used

Evidence used

Primary bottleneck

Primary bottleneck

Recommended intervention

Recommended intervention

Priority checks

Priority checks

Recommended next artifact

Recommended next artifact

Route-outs

Route-outs

What not to do yet

What not to do yet

Step 8: Verify the boundary before finalizing

步骤8：最终确认前验证边界

Output format

输出格式

Examples

示例

Example 1: weak wishlists with some traffic

示例1：有流量但愿望单数据不佳

Example 2: Next Fest decision

示例2：Next Fest决策

Example 3: launch checklist ask

示例3：请求发布清单

Best practices

最佳实践

References

参考资料

`page-promise-audit`

`page-promise-audit`

`wishlist-signal-check`

`wishlist-signal-check`

`demo-readiness-gate`

`demo-readiness-gate`

`event-timing-workback`

`event-timing-workback`

`launch-ops-runbook`

`launch-ops-runbook`