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:

1. 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.

2. 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.

3. Assign Owners and Dates Every checklist item needs an owner and a target completion date. Ownership creates accountability; dates enable tracking.

4. Identify Dependencies and Blockers Flag items that block other work or are blocked by external factors. Surface these early so teams can unblock.

5. Define Go/No-Go Criteria Establish clear criteria for making the launch decision. What conditions must be met? Who makes the final call?

6. Document Rollback Plan Every launch should have a rollback strategy. Document how to revert if critical issues emerge post-launch.

7. 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.

---

Supporting file: HISTORY.md

deliver-launch-checklist - Version History

2.2.0 (2026-07-04)

Released in v2.30.0 (../../site/src/content/docs/releases/Release_v2.30.0.md). Effort: M-35 (trust repair sweep).

The 2026-07-04 deep audit named this description as generic, with none of the "When NOT to Use" section's existing boundaries (against deliver-release-notes, measure-experiment-design, and small single-team changes) surfaced up front.

Changes

• Rewrote the frontmatter description (Batch 5, WS-T8e) to name the checklist's specifics (owners, dates, go/no-go criteria), the small-single-team-change boundary, and the deliver-release-notes deflection.

No change to the Instructions, Output Format, or Quality Checklist.

2.1.0 (2026-06-10)

Quality-convergence minor (F-12 Batch 1): added a "When NOT to Use" section with boundary pointers to neighboring skills, and the Output Format now enumerates the template sections a complete artifact fills. No template or example changes.

2.0.0 (2026-01-26)

Baseline row for the prior published version; see git history for its changes.

---

Supporting file: evals/trigger-fixtures.json

{
  "schema": 1,
  "skill": "deliver-launch-checklist",
  "runs_per_query": 3,
  "trigger_threshold": 0.5,
  "queries": [
    {
      "q": "Create a launch checklist for the v3 mobile app release going out in two weeks",
      "expect": "trigger",
      "split": "train"
    },
    {
      "q": "We ship the enterprise tier in ten days and I'm worried support and legal haven't signed off; help me track readiness across every team",
      "expect": "trigger",
      "split": "train",
      "notes": "Intent-only ask, no artifact keyword"
    },
    {
      "q": "Build the go/no-go readiness doc for the payments migration, including rollback plan and owner assignments",
      "expect": "trigger",
      "split": "train"
    },
    {
      "q": "We're coordinating engineering, marketing, and support for the rebrand launch; I need one artifact that catches anything we've missed before the date",
      "expect": "trigger",
      "split": "train"
    },
    {
      "q": "Kicking off launch planning for the AI assistant feature; draft the cross-functional pre-launch checklist",
      "expect": "trigger",
      "split": "train"
    },
    {
      "q": "Last launch we forgot to brief the support team and it was a mess; set up the readiness tracking so that never happens again",
      "expect": "trigger",
      "split": "train"
    },
    {
      "q": "Put together a pre-launch checklist for the self-serve pricing change, owners and dates included",
      "expect": "trigger",
      "split": "validation"
    },
    {
      "q": "What needs to be verified across legal, ops, and marketing before Thursday's feature rollout? Make me the tracking doc",
      "expect": "trigger",
      "split": "validation"
    },
    {
      "q": "Major version release next sprint; create the readiness checklist with go/no-go criteria and a rollback plan",
      "expect": "trigger",
      "split": "validation"
    },
    {
      "q": "Our launch tier is major this time; generate the full cross-functional readiness list so we can review it at kickoff",
      "expect": "trigger",
      "split": "validation"
    },
    {
      "q": "The feature ships tomorrow; write the customer-facing announcement of what's new and improved",
      "expect": "no-trigger",
      "split": "train",
      "near_miss_of": "deliver-release-notes",
      "notes": "Communicating the ship, not coordinating readiness, per When NOT to Use"
    },
    {
      "q": "We're not sure this should ship at all; design the A/B test that tells us whether to roll it out",
      "expect": "no-trigger",
      "split": "validation",
      "near_miss_of": "measure-experiment-design",
      "notes": "Validating whether to ship belongs to experiment design, per When NOT to Use"
    },
    {
      "q": "The launch happened last week; run a retrospective on how it went",
      "expect": "no-trigger",
      "split": "train",
      "notes": "Post-launch reflection; iterate-retrospective territory"
    },
    {
      "q": "Draft a PRD for the referral program so engineering can start building",
      "expect": "no-trigger",
      "split": "train"
    },
    {
      "q": "It's a tiny copy change shipping from one team; just write the ticket description for it",
      "expect": "no-trigger",
      "split": "train",
      "notes": "Small single-team change; the skill's own boundary says skip the checklist"
    },
    {
      "q": "Summarize the launch metrics from the dashboard and tell me whether we hit the activation target",
      "expect": "no-trigger",
      "split": "validation"
    },
    {
      "q": "Write a Python script that renames thousands of image files by date",
      "expect": "no-trigger",
      "split": "train",
      "notes": "Unrelated scripting ask"
    },
    {
      "q": "Plan a five-day trip to Lisbon for our team offsite, flights and hotels included",
      "expect": "no-trigger",
      "split": "validation",
      "notes": "Unrelated logistics ask"
    },
    {
      "q": "Help me debug why our Kubernetes pods keep crash-looping after the deploy",
      "expect": "no-trigger",
      "split": "train",
      "notes": "Unrelated debugging ask"
    },
    {
      "q": "Map the stakeholders for the platform migration so I know who needs to be aligned",
      "expect": "no-trigger",
      "split": "validation"
    }
  ]
}

---

Supporting file: references/EXAMPLE.md

Launch Checklist: TaskFlow Mobile v3.0

Launch Overview

Key Stakeholders

Engineering Readiness

QA & Testing

Design & UX

Marketing & Communications

Customer Support

Legal & Compliance

Operations & Infrastructure

Analytics & Monitoring

Go/No-Go Criteria

Must Have (Blockers)

• All P0 bugs resolved
• Security review complete (BLOCKED - scheduled Mar 3-5)
• Performance benchmarks met
• UAT sign-off from 10+ stakeholders (8/12 complete)
• On-call rotation confirmed for launch week
• Rollback plan tested

Should Have

• Marketing materials ready
• App store listing updated with new screenshots
• Support team training complete

Nice to Have

• Launch blog post published same day
• Social media campaign live at launch

Rollback Plan

Trigger Conditions

• Crash rate >2% (baseline: 0.3%)
• Error rate >5% on any critical API
• Major functionality broken (login, task creation, sync)
• Security vulnerability discovered

Rollback Steps

1. Disable feature flags (recurring_tasks_enabled, new_nav_enabled)
2. If flag disable insufficient: Push App Store emergency update reverting to v2.9
3. Communicate to users via in-app banner and email
4. Post incident channel update (#launch-v3-war-room)

Rollback Owner

David Park - david@taskflow.io (mailto:david@taskflow.io) - +1-555-0123

Rollback Time Estimate

• Feature flag disable: <5 minutes
• App store rollback: 24-48 hours (Apple review)

Check-in Schedule

Open Issues

---

Supporting file: references/TEMPLATE.md

Launch Checklist: [Launch Name]

Launch Overview

Key Stakeholders

Engineering Readiness

QA & Testing

Design & UX

Marketing & Communications

Customer Support

Legal & Compliance

Operations & Infrastructure

Analytics & Monitoring

Go/No-Go Criteria

Must Have (Blockers)

• [Blocker 1]
• [Blocker 2]
• [Blocker 3]

Should Have

• [Should-have 1]
• [Should-have 2]

Nice to Have

• [Nice-to-have 1]
• [Nice-to-have 2]

Rollback Plan

Trigger Conditions

• [Condition 1]
• [Condition 2]

Rollback Steps

1. [Step 1]
2. [Step 2]
3. [Step 3]

Rollback Owner

[Name] - [Contact]

Rollback Time Estimate

[Duration]

Check-in Schedule

Open Issues