launch-readiness
The launch-readiness skill systematically evaluates product and feature readiness across product, engineering, marketing, support, sales, and analytics functions, then delivers a documented Go, Conditional Go, or No-Go recommendation. Use this skill when preparing any product launch or major feature release to identify blockers with assigned owners and deadlines, surface risks requiring mitigation, and confirm that rollback plans are tested and viable before shipping.
git clone --depth 1 https://github.com/mohitagw15856/pm-claude-skills /tmp/launch-readiness && cp -r /tmp/launch-readiness/plugins/pm-delivery/skills/launch-readiness ~/.claude/skills/launch-readinessSKILL.md
# Launch Readiness Skill Ensure nothing falls through the cracks before launch by systematically checking readiness across every function — and producing a clear, evidenced go/no-go recommendation. ## Required Inputs Ask the user for these if not provided: - **Launch name and target date** - **Launch tier** (Tier 1 = major launch / Tier 2 = significant feature / Tier 3 = incremental update) - **Completed checklist items or self-assessment** (even partial is fine — we'll surface gaps) - **Team and role names** (to assign owners to blockers) ## Readiness Checklist by Function ### Product & Engineering - [ ] Feature complete against launch spec - [ ] Performance benchmarks met - [ ] Accessibility standards checked - [ ] Edge cases documented and handled - [ ] Rollback plan defined and tested ### Marketing & Comms - [ ] Launch messaging approved - [ ] Blog post / press release drafted - [ ] Social content prepared - [ ] Email campaigns scheduled - [ ] Landing page live and tested ### Support & Success - [ ] Support team trained on new feature - [ ] FAQ and help docs published - [ ] Escalation path defined for launch issues - [ ] Customer success briefed (if enterprise) ### Sales & Partnerships - [ ] Sales enablement materials ready - [ ] Pricing confirmed and communicated - [ ] Partner comms sent (if applicable) ### Data & Analytics - [ ] Tracking events implemented and verified - [ ] Launch metrics dashboard live - [ ] Baseline metrics captured pre-launch ## Process 1. Review provided launch brief and checklist responses 2. Flag any incomplete items as blockers (must fix) or risks (monitor) 3. Assess overall readiness and produce go/no-go recommendation with rationale 4. If no-go, specify exactly what must be completed and by when 5. **Validate** — Confirm every blocker has a named owner and resolution deadline, and that the rollback plan is tested (not just documented) ## Output Structure ### Launch Readiness Assessment: [Feature/Product Name] **Launch Date:** [date] **Launch Tier:** [1 / 2 / 3] **Overall Status:** ✅ Go / ⚠️ Conditional Go / 🛑 No-Go **Blockers (must resolve before launch):** - [item + owner + resolution required by] **Risks (monitor closely):** - [item + mitigation plan] **Ready Areas:** - [function]: ✅ Ready **Recommendation:** [Clear go/no-go with rationale — 3-5 sentences] ## Quality Checks - [ ] Every blocker has a specific owner (not "the team") and a deadline - [ ] Rollback plan is explicitly tested, not just written - [ ] Analytics events are verified in staging, not just implemented - [ ] Go/No-Go decision has a named decision-maker and a cut-off time - [ ] At least one post-launch monitoring check is scheduled (e.g., T+2hr, T+24hr) ## Anti-Patterns - [ ] Do not mark a function as "Ready" without evidence — green status must be backed by a completed checklist item, not an assumption - [ ] Do not issue a Conditional Go without specifying exactly what conditions must be met and by when — vague conditions are not conditions - [ ] Do not treat the rollback plan as complete unless it has been tested in staging, not just documented - [ ] Do not assign blockers to "the team" — every blocker must have a single named owner or it will not be resolved before launch - [ ] Do not skip the analytics verification step — unverified tracking events mean the launch will be invisible and cannot be evaluated
Design a 360-degree feedback survey or write a structured 360 feedback report. Use when asked to build a 360 feedback process, write 360 feedback for a colleague, design a feedback survey, or produce a feedback report. Produces either a complete survey instrument with rating scales and open-ended questions, or a structured narrative feedback report with themes, strengths, and development areas.
Decode a 401k or workplace retirement plan — the real cost of its funds, the match's fine print, vesting math, and the plan features worth using or avoiding. Use when someone asks 'is my 401k any good', 'decode my 401k plan', 'which funds should I look at', or 'what fees am I paying'. Produces a fee decode in dollars-over-time, match and vesting math, a fund-lineup triage by cost, and the questions for HR or the plan administrator.
Design statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, design an A/B test, calculate sample size, or interpret test results. Produces a complete test plan with hypothesis, variant definitions, sample size, duration estimate, guardrail metrics, and a results interpretation guide.
Analyse a finished A/B test and write the readout — the result, whether it's statistically and practically significant, what it means, and the ship/no-ship call. Use when asked to analyse experiment results, write an A/B test readout, interpret test data, or decide whether to ship a variant. Produces a clear verdict with the lift and confidence, segment cuts, the risks (peeking, novelty, sample), and a recommendation. Distinct from planning a test — this reads results.
Generate a WCAG 2.2 accessibility audit checklist and remediation suggestions for any UI or design. Use when asked to audit for accessibility, check WCAG compliance, review a design for a11y issues, or create an accessibility remediation plan. Produces a prioritised checklist with pass/fail assessments and specific fixes.
Plan a trip that actually works with a disability or access need — confirm real accessibility (not just 'accessible' labels), book the assistance in advance, plan for equipment and medication, and build in the contingencies for when access breaks down. Use when someone says 'plan an accessible trip', 'travelling with a wheelchair/disability', 'book assistance for my flight', or 'will this hotel actually work for me'. Produces an access-verified itinerary, an assistance-booking checklist, an equipment/medication plan, and contingency scripts. Verify specifics with providers.
Request a reasonable accommodation at work or in education — frame it around the barrier and the adjustment (not your diagnosis), cite the right process, and navigate the back-and-forth constructively. Use when someone says 'I need a workplace accommodation', 'request reasonable adjustments', 'ADA/Equality Act accommodation', or 'how do I ask for accommodations for my disability/condition'. Produces the request letter, a barriers-and-adjustments map, disclosure guidance, and a plan for the interactive process. Not legal advice — routes to the formal process and to advocacy where needed.
Build a structured account plan for any key customer or target account. Use when asked to create an account plan, key account strategy, strategic account review, or territory plan. Produces a complete account plan with relationship map, growth opportunities, risks, and 90-day action plan.