/launch-checklist

name: launch-checklist
description: "Launch readiness across every department: code, content, store, marketing, community, infrastructure, legal, go/no-go sign-offs."
argument-hint: "[launch-date or 'dry-run']"
user-invocable: true
disable-model-invocation: true
allowed-tools: Read, Glob, Grep, Write, AskUserQuestion, Bash(bash "*/.claude/skills/launch-checklist/../../hooks/yaml-helper.sh" resolve_config *)
model: sonnet

!`bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys rigor,workflow,project.stage,cert_tier,automation`

**Automation mode**: Resolve `modes.automation` (`project.local.yaml` → `project.yaml` → default `collaborative`). Every `AskUserQuestion` call and every file write follows `.claude/docs/automation-modes.md` (collaborative asks always · guided major-only · autonomous logs and proceeds; `automation_always_ask` categories always prompt).

Resolved above — use as-is. No block → defaults in `.claude/docs/config-resolution.md`.

Launch Checklist

**Scope this checklist to the project.** Emitting every item for every platform trains the reader to skip the list, which defeats the gate:

• **`project.stage`** — items for phases this project has not reached are out of

scope; say so rather than listing them unchecked.

• **`modes.rigor`** — at `minimal`, drop items whose only justification is process

weight this project has opted out of.

• **`platform.cert_tier`** — emit certification items **only** for the tier the

project targets. If it is **unset**, **ask which platforms are in scope** rather than emitting all of them — an unset value is a question, not a licence to emit every certification track. The answer, mapped onto the four values below, is the tier for this run. If it cannot be determined, mark the section **`NOT ASSESSED — cert tier unknown`**. **Unset is not `none`:** `none` is a decision, unset is a missing one, and they must not produce the same output. Branch on the **four values this key takes** — `none | itch | steam | console` — and not on platform names. The full requirement table is the `## platform.cert_tier` section of `.claude/docs/effects-map.md` — read **only that section** (Grep its heading, then a bounded Read); the file as a whole is not a runtime input.

• `none` — **emit no certification section at all.** Internal release, alpha or

jam game. Say the section was omitted and why; do not leave it blank.

• `itch` — itch.io upload requirements only: build size, page setup, age tags.

**No console and no Steamworks items.**

• `steam` — Steamworks: store page, depot build, achievements, system

requirements, common content rules. **No console certification items.**

• `console` — full platform certification (TRC / XR / Lotcheck), save-data

rules, controller-mapping rules, age-rating boards. The heaviest tier.

> **Branch on the `cert_tier` values above, not on platform names.** A test on > target platforms treats an `itch` project and a `steam` project identically, > conflates `none` with unset, and keys on `mobile`, which is not a `cert_tier` > value at all. Use the vocabulary the config defines.

If an item cannot be scoped because the config is absent, mark it **`NOT ASSESSED — platform/stage unknown`**. Do not silently include it: a `rigor: standard`, single-platform project would otherwise receive a ~150-item checklist demanding PC **and** console **and** mobile certification plus age ratings, of which ~140 are unassessable.

---

Phase 1: Parse Arguments

Read the argument for the launch date or `dry-run` mode. Dry-run mode generates the checklist without creating sign-off entries or writing files. With no argument the run is a normal one with the target date unset (`Target Launch: not set`) — dry-run only when the argument says `dry-run`.

---

Phase 2: Gather Project Context

• Read `CLAUDE.md` for tech stack, target platforms, and team structure
• Read the latest milestone in `production/milestones/`
• Read any existing release checklist in `production/releases/`
• Read the content calendar in `design/live-ops/content-calendar.md` if it exists

---

Phase 3: Scan Codebase Health

> **Every scan in this phase is a search for something bad, so a zero-hit result > is ambiguous by construction: it means either "searched and found none" or > "there was nothing to search". On a launch gate those are opposite findings, > and a green checkbox renders them identically.** > > **Establish the denominator before every scan below, and report it.** Each line > reads either `scanned [N] files, [M] hits` or > `NOT ASSESSED — [code root unresolved | no source files | no asset folder | directory empty]`. > Never a bare tick. The code root is `src/`, `Assets/` or `Source/` by engine > (resolve per `.claude/docs/code-root-resolution.md`); assets live in > `assets/`, `Assets/` or `Content/`. > > This applies to all four bullets below: each searches the same way, for > placeholder assets, TODOs, debug output and hardcoded test values, and each > returns zero hits on an empty or absent root. With no `assets/` directory, for > example, the placeholder scan returns zero hits, and a bare tick would mark > "All placeholder art replaced" green.

• Count `TODO`, `FIXME`, `HACK` comments and their locations
• Check for any `console.log`, `print()`, or debug output left in production code
• Check for placeholder assets (search for `placeholder`, `temp_`, `WIP_`)
• Check for hardcoded test/dev values (localhost, test credentials, debug flags)

**Carry the distinction into the checklist itself.** An item whose scan returned `NOT ASSESSED` is written `- [?]`, not `- [ ]`. An unticked box says *work remains*; a `[?]` says *nobody could check*, and only one of those is closed by doing the work. Include the legend wherever a `[?]` appears: `[?] = not assessed — the input to this check was absent`.

---

Phase 4: Generate the Launch Checklist

# Launch Checklist: [Game Title