Start a fresh conversation. Replace the highlighted placeholders.
Use deliver-launch-checklist to create a cross-functional pre-launch checklist for [launch], with [launch date], named owners, dependencies, rollback steps, and explicit go/no-go criteria.
Required inputs
[launch]
[launch date]
User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗
SKILL.md
name: deliver-launch-checklistdescription: Creates a cross-functional pre-launch checklist covering engineering, design, marketing, support, legal, and operations readiness, with owners, dates, and go/no-go criteria so nothing is missed before release. Use for significant or cross-team launches, not a small single-team change. For the customer-facing announcement of what shipped, use deliver-release-notes instead.license: Apache-2.0metadata: phase: deliver version: "2.2.0" updated: 2026-07-04 category: coordination frameworks: [triple-diamond, lean-startup, design-thinking] author: product-on-purpose
Launch Checklist
A launch checklist is a comprehensive verification document that ensures all functions are ready before releasing a feature or product. It coordinates across engineering, QA, design, marketing, support, legal, and operations to prevent launch-day surprises. Good launch checklists surface blockers early and create shared accountability for launch readiness.
When to Use
1-2 weeks before any significant launch
During launch planning kickoff meetings
When coordinating cross-functional releases
Before major version releases or feature rollouts
After incidents to improve launch processes
When NOT to Use
You are validating whether to ship at all via an experiment -> use measure-experiment-design
You need the customer-facing announcement of what shipped -> use deliver-release-notes
The launch already happened and you want results or reflection -> use measure-experiment-results or iterate-retrospective
The change is small and single-team with no cross-functional surface: a launch checklist adds ceremony without value; track it in the sprint instead
Instructions
When asked to create a launch checklist, follow these steps:
Define Launch Context
Document what is launching, when, and who the key stakeholders are. Establish the launch tier (major release, minor feature, experiment) as this affects checklist scope.
Gather Functional Requirements
For each function (engineering, QA, marketing, etc.), identify what must be complete, verified, or in place before launch. Distinguish between blockers (must-have) and nice-to-haves.
Assign Owners and Dates
Every checklist item needs an owner and a target completion date. Ownership creates accountability; dates enable tracking.
Identify Dependencies and Blockers
Flag items that block other work or are blocked by external factors. Surface these early so teams can unblock.
Define Go/No-Go Criteria
Establish clear criteria for making the launch decision. What conditions must be met? Who makes the final call?
Document Rollback Plan
Every launch should have a rollback strategy. Document how to revert if critical issues emerge post-launch.
Schedule Check-in Cadence
Establish when the team will review checklist progress (daily standups, T-2 days review, launch day sync).
Output Format
Use the template in references/TEMPLATE.md to structure the output. A complete checklist fills every template section: Launch Overview; Engineering Readiness; QA & Testing; Design & UX; Marketing & Communications; Customer Support; Legal & Compliance; Operations & Infrastructure; Analytics & Monitoring; Go/No-Go Criteria; Rollback Plan; Check-in Schedule; and Open Issues.
Quality Checklist
Before finalizing, verify:
All functional areas are represented
Every item has an owner and target date
Blockers are clearly distinguished from nice-to-haves
Go/No-Go criteria are specific and measurable
Rollback plan is documented and tested
Check-in cadence is scheduled
Examples
See references/EXAMPLE.md for a completed example.