Skip to main content Home Creators akillness jeo-skills steam-store-launch-ops
steam-store-launch-ops Turn Steam store-page, wishlist, demo, Next Fest, and launch-window ambiguity into one packet-first Steam launch brief. Use when an indie dev, small studio, founder-marketer, or publisher helper needs to decide whether the next move is a page-promise audit, wishlist-signal check, demo-readiness gate, event-timing workback, or launch-ops runbook โ especially when they say "help my Steam page", "wishlists are weak", "is our demo ready", "should we do Next Fest", or "give me a Steam launch checklist". Route broad non-game GTM work to `marketing-automation` and player-feedback/build-performance issues to the game specialist skills.
Jump to install Skills Marketplace Discover and explore AI skills built by the community.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Show prompt details A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/akillness/jeo-skills --skill steam-store-launch-opsThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Download Zip Downloading... More from this repository Drive Godogen (htdt/godogen), the MIT-licensed publish-time generator that turns a game description into an autonomous Claude Code or Codex build for Godot 4 C#, Bevy Rust, or Babylon.js TypeScript. Route one request to one mode: preflight the toolchain and API keys; publish a fresh game repository or safely refresh a matching existing runtime with `./publish.sh --engine ...`; run the build and prove it from the live game or a 15-20s recording; budget paid Gemini, Grok, and Tripo3D asset generation; apply engine-specific build and capture rules; troubleshoot rendering and capture failures; or contribute through the issue-first upstream process. Use when the user wants an agent to build a playable game end to end with Godogen. Triggers on: godogen, htdt/godogen, publish.sh --engine, autonomous game development, Godot C# agent build, Bevy agent build, Babylon.js agent game, asset-gen, Tripo3D rig, proof video.
Install, route, and operate zenstory-ai/drama-skills, the MIT-licensed 10-skill creator-first suite for Chinese short dramas and motion comics. Use when the user wants to import or troubleshoot the suite; initialize or resume a filesystem project; analyze a novel; develop an adaptation; write episodes; build visual assets; produce image prompts, storyboards, or video prompts; review a project; open its local Dashboard; or run confirm-gated image, video, TTS, or music production. Route each request to the correct `short-drama-*` owner while preserving the five-document episode contract. Triggers on: drama-skills, zenstory-ai/drama-skills, short-drama, Chinese short drama, motion comic, creator-first drama workflow, ๅงๆฌ, ่ง่ง่ฎพๅฎ, ๅ้, ๅพ็ๆ็คบ่ฏ, ่ง้ขๆ็คบ่ฏ. Route generic programmable-video work to `video-production`, webtoon panel production to `webtoon-harness`, and the OpenStory codebase to `openstory`.
Drive Mole (`mo`), tw93's GPL-3.0 macOS maintenance CLI that cleans caches and app leftovers, uninstalls apps with their remnants, purges rebuildable project artifacts, removes downloaded installers, explores disk usage, runs bounded system optimization, and reports live health. Routes one request to one mode: run a command safely (`--dry-run` first, the user runs the destructive step), consume the JSON/NDJSON agent surfaces (`mo analyze --json`, `mo status --json` / `--watch`, `mo history --json`, `~/.config/mole/clean-list.txt`), install/update/remove on the right channel, configure whitelists and scan paths, troubleshoot, or contribute to the repo. Use when a user wants to free Mac disk space or fully uninstall a Mac app. Triggers on: mole, `mo clean`, `mo uninstall`, `mo analyze`, `mo purge`, `mo status`, tw93/Mole, mole.fit, clean my Mac, what is eating my disk, CleanMyMac / AppCleaner / DaisyDisk alternative, brew install mole.
Related occupations SOC
Based on SOC occupation classification
name steam-store-launch-ops description Turn Steam store-page, wishlist, demo, Next Fest, and launch-window ambiguity into one packet-first Steam launch brief. Use when an indie dev, small studio, founder-marketer, or publisher helper needs to decide whether the next move is a page-promise audit, wishlist-signal check, demo-readiness gate, event-timing workback, or launch-ops runbook โ especially when they say "help my Steam page", "wishlists are weak", "is our demo ready", "should we do Next Fest", or "give me a Steam launch checklist". Route broad non-game GTM work to `marketing-automation` and player-feedback/build-performance issues to the game specialist skills.
allowed-tools Bash Read Write Edit Glob Grep compatibility Best for Steam page URLs or screenshots, trailer and tag packets, demo status, wishlist/traffic context, event timing notes, creator/outreach prep, and launch checklists. Works as a Steam-specific diagnosis and packet-selection workflow, not as a generic marketing strategist, PR CRM, or build-debugging system.
metadata {"tags":"steam, indie-games, game-marketing, launch-ops, next-fest, wishlists, store-page, demos","version":"1.2","source":"akillness/jeo-skills"}
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:
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.
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.
page-promise-audit โ the main risk is page conversion: capsule, screenshots, trailer, short description, tagswishlist-signal-check โ the user says wishlists are weak and you must separate traffic weakness from conversion weaknessdemo-readiness-gate โ the key question is whether the demo helps or hurts the current public beatevent-timing-workback โ the team needs a Next Fest / showcase / timing decision with readiness tradeoffslaunch-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.
visibility-acquisitionpromise-clarityproof-demo-readinesstiming-hook-fitlaunch-ops-readinessevidence-gap
"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-auditUse when the page package is the likely bottleneck.
capsule readability
screenshot ordering and gameplay proof
trailer opening
short-description specificity
tag coherence
page rewrite briefscreenshot reorder brieftrailer hook brieftag audit
wishlist-signal-checkUse when the team is overfitting to weak wishlist results.
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
wishlist signal memopage rewrite briefvisibility push checkdemo readiness checklist
demo-readiness-gateUse when the demo is the public proof question.
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
demo readiness checklistproof-gap notesevent timing memo
event-timing-workbackUse when the main decision is whether a public beat fits actual readiness.
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
Next Fest runbookevent timing decision memoasset lock checklist
launch-ops-runbookUse when the core page/demo are mostly acceptable, but launch execution is fragmented.
review/release timing
creator/press readiness and key/outreach packet hygiene
ownership gaps
launch-day checklist and contingency points
launch checklistlaunch-day runbookcreator/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
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 .
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
Our Steam page gets clicks from social posts, but wishlists are still weak. Review our capsule, screenshots, short description, and tags.
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
We want to do Next Fest. The page is up and the trailer is decent, but I am nervous the demo is still rough.
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
Give me a Steam launch checklist. We have a page, trailer, demo, and a small creator list.
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
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.
References 