game-launch

name	game-launch
description	Invoke when the user is preparing for game release, needs a launch checklist, store submission guidance, go/no-go decision framework, or day-one patch planning. Covers Steam, itch.io, Epic, and console submission pipelines. Triggers on: "launch", "release", "store submission", "go/no-go", "day-one patch", "launch readiness". Do NOT invoke for sprint planning (use game-sprint-plan) or code review (use game-code-review). Part of the AlterLab GameForge collection.
argument-hint	[platform: steam|itch|epic|console]
model	opus
effort	high
disable-model-invocation	true
allowed-tools	Read, Glob, Grep, Write, AskUserQuestion
version	1.3.0

AlterLab GameForge -- Pre-Release Launch Pipeline

The distance between "done" and "launched" is longer than most teams expect. And the distance between "launched" and "sustained" is longer still. A game that is feature-complete, bug-free, and fun can still fail because the store page was not optimized, the press kit was missing, the age rating was not filed, or the day-one patch pipeline was not tested. Worse -- a game that launches perfectly can die in week two without a post-launch strategy.

Hades did not become a cultural phenomenon on launch day. It became one through 18 months of Early Access with a meticulously planned patch cadence. Stardew Valley did not stop at 1.0 -- ConcernedApe's free content updates built a community that still plays eight years later. This workflow covers both sides: the exhaustive pre-launch pipeline AND the post-launch operations that determine whether your game survives past the first week.

Purpose & Triggers

Invoke this workflow when:

• The game is entering the final milestone before release and a structured launch plan is needed
• A storefront submission deadline is approaching and the team needs to verify all requirements are met
• Marketing assets need to be prepared and coordinated across platforms
• Legal and compliance requirements (age ratings, privacy policies, licenses) need auditing
• The team needs a go/no-go framework for making the launch decision
• A soft launch or early access release is being planned (same process, adjusted scope)
• Post-launch support infrastructure needs to be established before launch day

Do NOT use this workflow when:

• The game is still in active development with significant features incomplete (finish building first)
• You are launching an internal playtest build (use game-playtest instead)
• The game is a game jam submission with no commercial intent (streamline to just build validation)

Critical Rules

1. Every phase is gated. Do not advance to the next phase until the current phase is signed off. Skipping a phase to save time is how launches implode. Vampire Survivors launched without a press kit and still succeeded -- but that was 2021 lightning in a bottle, not a replicable strategy.
2. Storefronts are not optional. A store page that is missing screenshots, has a vague description, or uses the wrong tags will kill discoverability. The store page IS the game's first impression. Treat it as a design deliverable, not a checkbox.
3. Legal compliance is not a suggestion. Missing an age rating or privacy policy can result in the game being pulled post-launch. This is a catastrophic outcome that is entirely preventable.