Product Launch Checklist Skill

Never launch without checking everything. Generate a complete, role-assigned checklist covering pre-launch readiness, launch day execution, and post-launch monitoring.

Proposes Actions

Once the checklist is approved, it can be executed: hand the items to action-runner, which previews them (dry-run, risk-rated), runs only what you approve via the connected action MCP (GitHub/Linear/Slack), and records what was done back to the brain. Typical: open an issue per checklist item in the named repo/project (🟡), and post the launch summary to Slack (🔴 — approved individually). This skill proposes; action-runner gates and runs — never silently.

Required Inputs

Ask the user for these if not provided:

• Launch name and planned launch date
• Launch tier (1 = major product launch, 2 = significant feature release, 3 = incremental update)
• Team members and their roles (engineering lead, PM, marketing, support, etc.)
• Feature description (what is being launched)
• Rollback capability (can this be feature-flagged or reverted quickly?)

Reads from / Writes to the Brain

If a professional-brain (brain/) exists, use it before asking:

• Read first: the entities/ feature being launched and related decisions/ (scope, dates, owners).
• Write after: log launch decisions and owners to decisions/. This skill can also hand the checklist to action-runner to file the tickets — which records what was actually done back to the brain, closing the loop.

How to Use This Skill

Provide:

• Launch name and date
• Launch tier (1 = major, 2 = feature, 3 = incremental)
• Team members and their roles

The skill generates a tiered checklist. Tier 3 launches use only the Essentials section. Tier 2 adds Marketing & Comms. Tier 1 uses all sections.

Output Format

Launch Checklist — [Feature/Product Name] — Target Date: [Date]

Launch Tier: [1 / 2 / 3] Launch Owner: [PM Name] Engineering Lead: [Name] Go/No-Go Decision By: [Date and time — typically 24 hours before launch]

🔧 PRE-LAUNCH — Engineering & Product (T-2 weeks)

• Feature flag created and tested in staging
• All acceptance criteria signed off by PM
• Code reviewed and merged to main
• QA sign-off completed (regression + new feature)
• Performance testing completed (load, latency)
• Security review completed (if data or auth changes)
• Rollback procedure documented and tested
• Monitoring and alerting configured
• Error logging in place with correct severity levels
• Database migrations tested on staging with production data volume

📢 PRE-LAUNCH — Marketing & Comms (T-1 week)

• Blog post written, reviewed, and scheduled
• In-app announcement or tooltip configured
• Email campaign drafted and QA'd
• Social media posts drafted and scheduled
• Landing page or feature page live in staging
• Press outreach sent (Tier 1 only)
• Product Hunt / community posts prepared (Tier 1 only)

🎓 PRE-LAUNCH — Sales & Support (T-1 week)

• Sales enablement one-pager completed
• FAQ document shared with sales and support teams
• Help centre articles written and published
• Support team demo / training completed
• Customer success team briefed on top accounts
• Pricing updated (if applicable)
• Contracts / ToS updated (if applicable)

📊 PRE-LAUNCH — Analytics (T-1 week)

• Analytics events firing correctly in staging
• Dashboard configured for launch metrics
• Baseline metrics documented
• Success criteria documented and shared with team
• A/B test configured (if applicable)

✅ GO / NO-GO DECISION — T-24 hours

Go / No-Go Decision: [GO / NO-GO] Decision Owner: [PM + Eng Lead jointly]

🚀 LAUNCH DAY

• Feature flag enabled for [X%] of users (start low — 5–10%)
• Launch confirmed in team Slack/channel
• Metrics dashboard open and being monitored
• Error rate checked at T+15 min, T+1 hr, T+4 hr
• Blog post published / email sent
• Social posts live
• Support team on standby for first 4 hours
• PM available and reachable all day
• Feature flag expanded to 50% if T+2hr checks pass
• Feature flag expanded to 100% if T+4hr checks pass

📈 POST-LAUNCH (D+7, D+30)

• D+7 metrics review: adoption, errors, support tickets
• D+7 customer feedback synthesised
• Retrospective scheduled
• Learnings documented
• D+30 success metrics reviewed against targets
• Feature flag removed from codebase (clean up)
• Follow-up features added to backlog based on feedback

Deeper Materials

This skill ships with support files — use them when they are available:

• references/launch-tiering.md — Launch Tiering: Matching Ceremony to Stakes. Apply it while producing the output; it carries the calibration and judgment calls the method summary above compresses.
• templates/launch-plan.md — a fill-in version of the deliverable with the quality gates inline. Offer it when the user wants to work the document themselves rather than have it generated.

Scoring Rubric (0–40)

Score any output of this skill before handing it over; 32+ is ship-quality.

Quality Checks

• Launch tier confirmed before generating checklist (scope determines depth)
• Go/No-Go decision has a named owner and a specific decision time
• Rollback procedure is documented and tested (not just planned)
• Feature flag expansion is staged (5% → 50% → 100%), not all-at-once
• Post-launch retrospective is scheduled at launch time

Anti-Patterns

• Do not apply a Tier 1 checklist to an incremental update — tier the launch appropriately before generating the checklist
• Do not launch on a Friday without confirmed weekend engineering coverage
• Do not leave the Go/No-Go decision owner as "the team" — it must be a named individual
• Do not skip the rollback plan for Tier 1 and 2 launches — know the revert time before going live
• Do not close the launch without scheduling the post-launch retrospective — it must be booked at launch time, not after

Guidelines

• The Go/No-Go decision must have a named owner — "the team" is not an owner
• Never launch on a Friday unless you have weekend engineering coverage
• Recommend starting all launches at <10% traffic — even for simple features
• Document rollback time: "We can revert this in X minutes" should be known before launch