Steam Store Launch Ops

Steam Store Launch Ops

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

The job is not to dump generic marketing advice. The job is to: 1. identify the current Steam hook, 2. choose the single best packet, 3. separate visibility, promise, proof, timing, and ops honestly, 4. make one-shot Steam constraints explicit, 5. 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

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

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

Instructions

Step 1: Classify the request into one packet

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.

Step 2: Capture the smallest credible Steam packet

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.

Step 3: Name the primary bottleneck

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

Step 4: Apply the one-shot Steam rules

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.

Step 5: Choose the packet-specific intervention

Use one packet and one intervention.

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

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

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

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

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

Step 6: Add route-outs before scope drifts

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.

Step 7: Return one Steam launch packet

Return one concise packet, not a giant essay.

# 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

Step 8: Verify the boundary before finalizing

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?

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

Examples

Example 1: weak wishlists with some traffic

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 or screenshot reorder brief
• avoids pretending traffic is the only issue

Example 2: Next Fest decision

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 or demo-readiness-gate
• bottleneck: proof-demo-readiness
• calls out that Next Fest is a readiness gate
• next artifact: demo readiness checklist or Next Fest runbook

Example 3: launch checklist ask

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

Best practices

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

References

• Steamworks Documentation — Visibility on Steam
• Steamworks Documentation — Coming Soon
• Steamworks Documentation — Demos
• Steamworks Documentation — Steam Next Fest
• Steamworks Documentation — Release Process

Steam Store Launch Ops Checklists

Use this reference when the user asks for a more concrete checklist than the main skill body should hold.

Fast audit order

1. Can I tell what the game is in 5 seconds?

• Capsule readable at thumbnail size
• Clear genre / fantasy signal
• No vague slogan replacing the hook

2. Do the first screenshots show real gameplay?

• Avoid lore-only or UI-confusing openers
• Show verbs, perspective, and encounter structure early

3. Does the trailer prove the promise fast?

• First seconds show the actual loop
• Avoid long logo / mood-only openings

4. Do the tags reinforce the same positioning?

• Specific tags beat generic stuffing
• Tags, description, and screenshots should describe the same game

5. Is the demo polished enough for public exposure?

• Representative quality
• Stable first-session experience
• Not obviously a placeholder build

Wishlist funnel triage

Use when the user says traffic exists but wishlists are weak.

Likely page-side causes

• hook is visible only below the fold
• short description is thematic but not specific
• capsule does not read well in tiny placement
• screenshots explain slowly
• trailer opens too late
• tags misplace the page in the wrong discovery neighborhood

Likely traffic-side causes

• almost no qualified visits
• outreach has not started
• launch beat / festival / streamer timing is weak
• page exists but there is no meaningful awareness loop yet

Next Fest readiness questions

• Is the demo already strong enough to create a good first impression?
• Does the event timing fit the launch plan?
• Are the page, trailer, screenshots, and tags polished before the event burst?
• Is livestream / broadcast setup ready?
• Is creator follow-up ready after the festival instead of ending at submission?

Launch-ops hygiene checks

• short description, screenshots, trailer, and tags are mutually consistent
• page links work
• contact / press / creator materials are easy to send
• the team knows the next artifact to produce instead of juggling everything at once
• no obvious last-minute blockers on demo availability or asset quality

Recommended follow-up artifacts

Choose one based on the blocker:

• page rewrite brief — when positioning is fuzzy
• screenshot reorder brief — when the page explains too slowly
• trailer hook brief — when the trailer fails to prove the game quickly
• tag audit — when discovery fit looks wrong
• demo readiness checklist — when event timing depends on demo quality
• launch checklist — when materials are scattered and ops hygiene is the blocker

Steam Store Launch Ops Diagnostic Model

Use this reference when the main skill needs a little more structure without bloating the front door.

The five bottleneck buckets

1. Visibility acquisition

Use when the real problem is that the right players are not reaching the page in the first place.

Signals:

• low traffic or very weak awareness context
• few qualified clicks from announcements, creators, festivals, or communities
• the team wants more wishlists but has not created real discovery loops yet

Good next artifacts:

• visibility push check
• creator/outreach list
• wishlist spike log

2. Promise clarity

Use when people reach the page but the package does not sell the game clearly enough.

Signals:

• weak wishlists despite some traffic
• capsule or screenshots do not communicate genre / fantasy quickly
• trailer opening is too slow or mood-only
• short description and tags describe a different game than the visuals imply

Good next artifacts:

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

3. Proof / demo readiness

Use when the page alone cannot carry the current beat and the demo/public build becomes the decisive trust signal.

Signals:

• the team asks whether the demo is ready for public exposure
• festival or creator beats depend on a polished first session
• the page is acceptable but the demo would likely undermine confidence

Good next artifacts:

• demo readiness checklist
• proof-gap notes
• build polish punchlist

4. Timing / hook fit

Use when the question is really whether the team should use a specific event or release moment now.

Signals:

• Next Fest timing uncertainty
• launch date pressure with thin readiness
• a visibility beat is about to be spent on a weak package

Good next artifacts:

• event timing decision memo
• Next Fest runbook
• launch timing risk list

5. Launch-ops readiness

Use when the page and demo are not the only issue; the team mostly lacks a clean runbook.

Signals:

• assets, links, creator materials, and checklists are scattered
• unclear ownership
• late-stage stress about missed steps
• launch confidence depends on coordination, not just persuasion

Good next artifacts:

• launch checklist
• launch-day runbook
• owner/dependency tracker

Evidence quality ladder

• High: page screenshots or URL, trailer, tags, demo status, and timing context are all present
• Medium: page assets plus partial traffic/event context
• Low: vague complaint with little or no page/proof/timing evidence

Do not over-diagnose from weak evidence.

Common mistakes

• Recommending more promotion before deciding whether the page converts.
• Rewriting the page when the real issue is a weak or mistimed demo.
• Treating Next Fest as generic visibility rather than a readiness gate.
• Dumping a giant marketing plan instead of one next artifact.

Steam Event and Launch Hooks

Use this reference to normalize the timeline. Steam teams usually ask for page help, but the better answer often depends on the current hook.

1. Coming Soon page goes live

Use when the team has just published the page or is about to.

Focus on:

• baseline page promise
• capsule readability
• first screenshots
• trailer opening
• tags matching the same genre promise
• whether the page is ready to collect qualified wishlists

2. Traffic spike or weak wishlist conversion

Use when the page is seeing some visitors but wishlist results feel disappointing.

Focus on:

• whether the issue is traffic quantity or page promise
• what changed recently
• whether the team has enough proof (demo, trailer, screenshots) for the current ask
• whether a wishlist spike log or page rewrite brief is the right next artifact

3. Demo ship / update decision

Use when the user is deciding whether to expose a demo publicly.

Focus on:

• whether the demo strengthens trust
• whether first-session clarity is good enough
• whether the demo matches the current page promise
• whether the team should polish, delay, or narrowly scope the beat

4. Steam Next Fest or similar public beat

Use when a visibility event is the immediate pressure.

Focus on:

• demo readiness
• page / trailer / screenshot lock quality
• livestream or creator readiness
• event-week support and hotfix expectations
• whether the event timing is actually right

5. Final launch window

Use when the user wants confidence before release.

Focus on:

• checklist completeness
• asset consistency across store surface and outreach packets
• creator / press readiness
• review and launch sequencing
• launch-day ownership and contingency notes

Hook-first shortcut

• If the hook is traffic → decide traffic vs conversion first
• If the hook is demo exposure → decide proof readiness first
• If the hook is Next Fest → treat it as a readiness gate
• If the hook is launch → prioritize the runbook/checklist gap

Steam Intake Packets and Route-Outs

Use this reference when the front door needs a sharper packet choice or when the ask is drifting into a neighboring skill.

Packet chooser

1) page-promise-audit

Choose this when:

• the page is live or about to go live
• the team wants a store-page review
• the visible package is probably the bottleneck
• you have enough page assets to evaluate capsule, screenshots, trailer, short description, and tags

Best when the next artifact should be:

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

2) wishlist-signal-check

Choose this when:

• the user says wishlists are weak
• traffic versus conversion is unclear
• the team might be overreacting to a signal without enough diagnosis
• wishlist tools or dashboards are being treated as answers instead of evidence

Best when the next artifact should be:

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

3) demo-readiness-gate

Choose this when:

• a demo is the real trust question
• the current beat depends on public proof
• the team worries the demo may damage confidence
• the one-shot demo notify timing matters

Best when the next artifact should be:

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

4) event-timing-workback

Choose this when:

• Next Fest or another public beat is the immediate pressure
• the team must decide whether to spend visibility now or wait
• the issue is not just page quality or just demo quality, but timing and readiness together

Best when the next artifact should be:

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

5) launch-ops-runbook

Choose this when:

• the page and demo are mostly acceptable
• launch timing, review, keys, creators, or ownership are scattered
• the team needs an execution packet rather than more diagnosis

Best when the next artifact should be:

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

Fast boundary checks

Route to marketing-automation

When:

• the request is broader non-game GTM, lifecycle, acquisition/content, or measurement strategy
• the user wants a full marketing plan rather than a Steam-specific packet
• the work is no longer mostly about Steam page, demo, Next Fest, or launch-window execution

Route to game-demo-feedback-triage

When:

• the evidence is mostly playtest notes, streamer reactions, bug lists, or player confusion
• the team needs fix-first prioritization inside the build
• store-page questions are secondary to demo/player experience evidence

Route to game-build-log-triage

When:

• the issue is one broken build, packaging failure, signing problem, or CI/editor log
• the team needs the first actionable failure, not launch-store diagnosis

Route to game-performance-profiler

When:

• the real blocker is frame time, stutter, Steam Deck, console, or device-specific perf
• a weak demo is weak mainly because of runtime bottlenecks

Route to bmad-gds

When:

• the main job is milestone sequencing, producer-style coordination, or mixed game-production planning
• Steam launch work is only one lane inside a larger project coordination problem

One-shot Steam warnings

Keep these visible whenever they affect the packet choice:

• a public pre-release demo depends on a visible base-game Coming Soon page
• the first public demo release gets a limited notify window; do not spend it casually
• Next Fest needs a public playable demo and current public-facing assets
• Steam review and release still involve timing and manual control, so launch ops need real workback planning

Anti-folklore reminders

• weak wishlists do not automatically mean the page copy is the problem
• a demo is not always a free visibility win; it can be a liability if it weakens trust
• Next Fest is not automatically worth spending on a rough build
• page analyzers, wishlist tools, and creator stacks are evidence aids or route-outs, not replacements for diagnosis