/release-checklist

name: release-checklist
description: "Pre-release checklist — build verification, certification requirements, store metadata, launch readiness."
argument-hint: "[platform: pc|console|mobile|all]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, Bash(bash "*/.claude/skills/release-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`.

Release 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. 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 target platform (`pc`, `console`, `mobile`, or `all`). If no platform is specified, default to `all`.

**The argument selects DEVICE requirements. It never selects the certification track.** Certification is decided by `platform.cert_tier`, resolved in the resolved-config block at the top of this skill — see the `platform.cert_tier` rule above. The two axes are different lists that happen to share one word: `pc`/`console`/`mobile` are hardware shapes, while `none|itch|steam|console` are certification regimes. They agree on `console` and nowhere else — `itch` and `none` have no device block at all, and `mobile` is not a `cert_tier` value. So emitting a device block says nothing about which certification block to emit, and `all` is **not** a licence to emit every certification track.

---

Phase 2: Load Project Context

• Read `CLAUDE.md` for project context, version information, and platform targets.
• Read the current milestone from `production/milestones/` to understand what features and content should be included in this release.
• Read the open bugs from `production/qa/bugs/`: grep the `**Severity**` and `**Status**` lines of `production/qa/bugs/*.md`, as `/bug-triage` does. A bug is open unless its Status is `Closed` or `Verified Fixed`. The bug items use the thresholds `/gate-check release` applies for the resolved `workflow`: at `full` an open S1, S2 or S3 bug fails its item; at `standard` and `minimal` only an open S1 does, and an open S2 or S3 is listed in the Rationale as a risk. Each failing bug is named in the Rationale as a blocking item. **No bug files in `production/qa/bugs/`** → the bug items read `NOT ASSESSED — no bug records` — never zero and never ticked, since an absent record and a clean one must not produce the same checklist; bugs are filed with `/bug-report`.

---

Phase 3: Scan Codebase

> **State the denominator with every count.** These scans look for something bad, > so `0` means either "searched and found none" or "there was nothing to search", > and on a release gate those are opposite findings. Report > `scanned [N] source files: [M] TODO, [M] FIXME, [M] HACK` — or, when the code > root (`src/`, `Assets/` or `Source/`; resolve per > `.claude/docs/code-root-resolution.md`) is unresolved, > **`NOT ASSESSED — code root unresolved`**, and when it is absent or holds no > source files, **`NOT ASSESSED — no source files found to scan`**. A bare `0` is > not a result.

Scan for outstanding issues:

• Count `TODO` comments
• Count `FIXME` comments
• Count `HACK` comments
• Note their locati