launch-checklist skill

!bash "${CLAUDESKILLDIR}/../../hooks/yaml-helper.sh" resolveconfig --keys rigor,project.stage,certtier,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; automationalwaysask categories always prompt).

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

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

scope; say so rather than listing them unchecked.

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

weight this project has opted out of.

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

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. 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; .claude/docs/effects-map.md holds the full requirement table and is the source, so read it rather than restating it.

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

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

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

No console and no Steamworks items.

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

requirements, common content rules. No console certification items.

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

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

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

Branch on the certtier values above, not on platform names.** "Emit

console/mobile certification items only for the platforms the project targets"

is the wrong test: it 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.

Explicit invocation only: This skill should only run when the user explicitly requests it with /launch-checklist. Do not auto-invoke based on context matching.

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.

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 — [no src/ | no assets/ | directory empty]. Never a bare tick.

This is written once, over the whole phase, rather than under one of the

four bullets. All four search src/ the same way — for placeholder assets,

TODOs, debug output and hardcoded test values — so if only one carries the

warning, an empty or absent src/ returns zero

hits three times and read as three clean results. The original

instance shipped: with no assets/ directory the scan returned zero hits and

"All placeholder art replaced" was ticked 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]
Target Launch: [Date or DRY RUN]
Generated: [Date]

---

## 1. Code Readiness

### Build Health
- [ ] Clean build on all target platforms
- [ ] Zero compiler warnings
- [ ] All unit tests passing
- [ ] All integration tests passing
- [ ] Performance benchmarks within targets
- [ ] No memory leaks (verified via extended soak test)
- [ ] Build size within platform limits
- [ ] Build version correctly set and tagged in source control

### Code Quality
- [ ] TODO count: [N] (zero required for launch, or documented exceptions)
- [ ] FIXME count: [N] (zero required)
- [ ] HACK count: [N] (each must have documented justification)
- [ ] No debug output in production code
- [ ] No hardcoded dev/test values
- [ ] All feature flags set to production values
- [ ] Error handling covers all critical paths
- [ ] Crash reporting integrated and verified

### Security
- [ ] No exposed API keys or credentials in source
- [ ] Save data encrypted
- [ ] Network communication secured (TLS/DTLS)
- [ ] Anti-cheat measures active (if multiplayer)
- [ ] Input validation on all server endpoints (if multiplayer)
- [ ] Privacy policy compliance verified

---

## 2. Content Readi

Phase 5: Save Checklist

Present the completed checklist and summary to the user (total items, blocking items count, conditional items count, departments with incomplete sections).

If not in dry-run mode, ask: "May I write this to production/releases/launch-checklist-[date].md?"

If yes, write the file, creating directories as needed.

Phase 6: Next Steps

• Run /gate-check to get a formal PASS/CONCERNS/FAIL verdict before launch.
• Coordinate sign-offs via /team-release.