/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. 4. **Plan for failure.** The launch plan must include a rollback strategy. If the answer to "what if launch goes wrong?" is "panic," your launch plan is incomplete. 5. **Day-one patches are expected, not shameful.** Between going gold and launch day, new issues will be found. The question is not "will we need one?" but "how fast can we deploy one?" 6. **Launch day is day one, not the finish line.** Dead Cells shipped its 1.0 and then delivered 6 major content updates over 4 years. Hades had 18 months of Early Access patches before 1.0. Your post-launch strategy matters as much as your pre-launch checklist. 6. **Reference `docs/game-design-theory.md`** for player psychology considerations in storefront presentation and first-time user experience.

Workflow

**Phase 1: Build Validation**

This is the final technical gate. The game must be provably stable, performant, and complete before any launch activities begin.

**Clean Build Verification:**

• Perform a clean build from source control on a machine that has never built the project before. This catches missing dependencies, local-only files, hardcoded paths, and environment-specific configurations.
• Verify that the build process is documented and reproducible. A build that only one person on the team can create is a single point of failure.
• Confirm the build version string is correct and matches the intended release version.
• If the game has a launcher or auto-updater, verify it points to the correct update servers.

**Automated Test Suite:**

• All unit tests passing: zero failures, zero skipped (unless permanently excluded with documented reason).
• All integration tests passing: game systems interact correctly.
• All platform-specific tests passing: each target platform builds and runs without platform-specific failures.
• Smoke tests for critical paths: new game start, save/load cycle, all main menu options, final boss completion, credits roll.

**Performance Validation:**

• Frame rate meets target on minimum specification hardware. Test on actual min-spec hardware, not a developer workstation set to reduced settings.
• Load times are within budget. First load, level transitions, and respawn times should all be measured and logged.
• Memory usage stays within platform limits across a full play session. Run a 2+ hour continuous play session and track memory allocation. If memory grows monotonically, there is a leak.
• Disk space usage is within platform limits (particularly relevant for console and mobile).
• Network performance (if applicable): latency, bandwidth usage, reconnection handling.

**Bug Triage:**

• Zer