| name | launch-checklist |
| description | Full launch readiness across departments: code, content, store listings, marketing, community, infra, legal, privacy (ATT, Data Safety), accessibility, and sign-offs. Run before every public launch. |
| argument-hint | [--platform=ios|android|both] |
| user-invocable | true |
| allowed-tools | Read, Glob, Grep, Write, Edit, Bash, AskUserQuestion |
| model | sonnet |
Launch Checklist
The cross-functional readiness gate. /release-checklist covers code
and store metadata; this skill goes wider — marketing, legal, privacy,
support, community, infrastructure — so nothing important slips.
Phase 1: Resolve Platform Scope
Default to both. If the project targets only iOS or only Android,
consult .claude/docs/technical-preferences.md for Target Platforms.
Ask the user the launch date and any soft-launch geography.
Phase 2: Read Project Context
Read in parallel:
CLAUDE.md, .claude/docs/technical-preferences.md.
- Current milestone in
production/milestones/.
- Latest QA sign-off from
production/qa/qa-signoff-*.md.
- Latest perf profile from
production/perf/perf-profile-*.md.
- Latest security audit from
production/security/security-audit-*.md.
- Latest asset audit from
production/assets/asset-audit-*.md.
- Latest balance check from
production/balance/balance-check-*.md.
- Latest localization report from
production/localization/loc-report-*.md.
- Tech debt register from
docs/tech-debt.md.
Surface the freshness of each artifact ("QA sign-off is 11 days old —
re-run?").
Phase 3: Build the Master Checklist
Render a structured checklist. Each line is a checkbox the user can
work through. The skill is a generator; signing off is the user's job.
Code and Build
Content
Assets
Store Listings
App Store
Play Console
Marketing and Community
Infrastructure
Legal and Privacy
Accessibility
Support
Day-One Patch Plan
Sign-Offs
Phase 4: Review Each Section with the User
Walk section-by-section. Use AskUserQuestion per section:
question: "[Section] — overall status?"
options:
- "All checked — sign off"
- "Mostly done — list outstanding"
- "Major gaps — block until resolved"
- "Skip this section (with reason)"
For each "list outstanding", capture the items — these become the
Open Items list at the bottom of the document.
Phase 5: Compose the Document
# Launch Checklist — [version] — [platform]
Generated: [date]
Launch target: [date]
Prepared by: [user]
[Full checklist content from Phase 3]
## Open Items (Blockers and TODOs)
| Item | Owner | Due | Status |
## Sign-Off Status
| Role | Name | Status | Date |
## Verdict
[GO | NO-GO | CONDITIONAL with conditions list]
Ask before writing to production/releases/launch-checklist-[version].md.
Phase 6: Update State
Append to production/session-state/active.md:
## Launch Checklist — [date]
- Version: [version]
- Platform: [list]
- Open items: [count]
- Verdict: [GO / NO-GO / CONDITIONAL]
- Path: [path]
- Next: [/gate-check | resolve open items | /team-release]
Quality Gates / PASS-FAIL
- GO — every required section signed off, zero blocker items, all
upstream verdicts (QA, perf, security) green.
- CONDITIONAL — open items remain but each has an owner and a deadline
before the launch target.
- NO-GO — at least one section has unresolved blockers or an upstream
verdict is red.
Examples
Example 1 — public launch v1.0 on both stores:
Walks every section. Surface 4 open items: 2 marketing assets, 1 ATT
prompt timing question, 1 Data Safety form mismatch. Verdict:
CONDITIONAL with deadlines.
Example 2 — Android-only beta launch:
Subset of checklist (skip App Store sections). 6 sign-offs collected
in one walk. Verdict: GO.
Next Steps
- GO ->
/team-release to execute deployment.
- CONDITIONAL -> resolve open items, re-run.
- NO-GO -> address blockers, re-run.