Launch Readiness Check - E-commerce
Use this skill when
Something is about to go live and the cost of finding a gap afterwards is high.
Common requests:
- "We launch Thursday. What's not ready?"
- "Restock drops Monday, check everything."
- "We're tripling spend next week. Are we safe?"
- "Give me a go/no-go."
Required input
Minimum useful input:
- What is launching, when, and the expected traffic or spend.
- Product page URLs or screenshots for the launch items.
- Stock position for the launch SKUs.
Recommended additional input:
- Feed or catalog status for the launch items.
- Tracking and conversion event status.
- Email and SMS flows scheduled around the launch.
- Support coverage and canned responses.
- Shipping and returns policy for launch items, including pre-order rules.
- Margin position at the planned discount or price.
- Rollback plan and who can execute it.
Before analysis
- Establish the launch date, the traffic peak expectation, and who owns the go decision.
- Establish the single failure that would hurt most in this specific launch, and check it first.
- Confirm what can still be changed before launch and what is already locked. A finding on something locked is a contingency plan, not a fix.
- Confirm whether this is a hard launch or a staged one, since staging changes the risk profile of every item below.
Analysis workflow
- Walk the eight readiness layers in order and mark each ready, at risk, or blocked:
- stock and fulfilment capacity, including the oversell scenario
- product page: clarity, proof, objections, delivery promise, mobile
- checkout: payment methods, discount mechanic tested, promo code live and scoped
- feed and catalog: availability, price, images, identifiers accurate for the launch items
- tracking: purchase event fires, values correct, no duplicate counting
- lifecycle: launch email and SMS scheduled, back-in-stock and abandoned flows not conflicting
- support: expected question themes have answers, coverage matches the peak
- margin: the planned price and discount survive fees, shipping, and expected returns
- For each layer, name what has actually been verified and what is only assumed. Assumed is not ready.
- Test the discount or promo mechanic end to end before launch, including the edge cases: stacking, minimum thresholds, excluded SKUs, and expiry.
- Model the oversell case explicitly: what happens if demand is three times the plan and stock runs out mid-campaign.
- Produce a go, go-with-conditions, or hold verdict with the conditions named and owned.
- Define the first-hour and first-day watch list, and the rollback trigger for each.
Decision and evidence standard
Tag every finding with evidence: url, screenshot, export, inventory_export, feed_diagnostics, policy, margin_csv, promo_calendar, hypothesis, or needs_data. Full vocabulary: ../references/output-standard.md.
Rank findings by what they would cost on launch day, not by how hard they are to fix.
A layer nobody verified is needs_data and cannot be marked ready. Silence is not a pass.
Output format
Go / no-go verdict
Go, go with conditions, or hold. Name the conditions and their owners.
Readiness board
| Layer |
Status |
Evidence |
Blocker |
Owner |
Due before launch |
Blockers
Everything that must be closed before go, ordered by launch-day cost.
Oversell and failure scenarios
What happens if demand overshoots, stock runs out, or tracking breaks, and what the response is.
Watch list and rollback
| Signal |
Where to look |
Threshold |
Action |
Missing data
List every layer nobody could confirm before the deadline, with the person who would have known. That list is the real risk register for launch day, and it is more useful than the layers that passed.
Example input and output
Input:
- launch brief with date and planned spend
- launch product URLs
- stock position
- flow schedule and promo code details
Good output excerpt:
| Finding |
Evidence |
Severity |
Confidence |
Business impact |
Effort |
Owner decision |
| Launch promo code stacks with the existing welcome code, taking two SKUs below cost |
screenshot, margin_csv |
critical |
high |
margin |
XS |
do_now |
| Back-in-stock flow will fire against the same list as the launch email on the same morning |
export |
medium |
high |
retention/support_load |
S |
do_now |
What not to do yet: mark tracking ready because it worked last month. Verify a test purchase on the launch items.
Guardrails
- Do not mark a layer ready on assumption. Unverified is
needs_data.
- Do not give a go verdict while a critical blocker is open, even under time pressure.
- Do not fix anything yourself during the check. The point is a list the owner can act on before the deadline, and an unannounced fix on launch morning is how two people change the same thing twice.
- Do not promise launch performance.
- Do not skip the oversell scenario because it feels optimistic. It is the most common launch failure.
1---2name: launch-readiness-check-ecommerce3description: Runs a go/no-go readiness check before a product launch, restock, promo, or spend increase, covering stock, page, feed, tracking, lifecycle flows, support, policy, and margin. Use when a launch, drop, restock or spend increase is about to go live and the cost of finding a gap afterwards is high. Works from a brief plus screenshots, so it needs no exports.4---56# Launch Readiness Check - E-commerce78## Use this skill when910Something is about to go live and the cost of finding a gap afterwards is high.1112Common requests:1314- "We launch Thursday. What's not ready?"15- "Restock drops Monday, check everything."16- "We're tripling spend next week. Are we safe?"17- "Give me a go/no-go."1819## Required input2021Minimum useful input:2223- What is launching, when, and the expected traffic or spend.24- Product page URLs or screenshots for the launch items.25- Stock position for the launch SKUs.2627Recommended additional input:2829- Feed or catalog status for the launch items.30- Tracking and conversion event status.31- Email and SMS flows scheduled around the launch.32- Support coverage and canned responses.33- Shipping and returns policy for launch items, including pre-order rules.34- Margin position at the planned discount or price.35- Rollback plan and who can execute it.3637## Before analysis38391. Establish the launch date, the traffic peak expectation, and who owns the go decision.402. Establish the single failure that would hurt most in this specific launch, and check it first.413. Confirm what can still be changed before launch and what is already locked. A finding on something locked is a contingency plan, not a fix.424. Confirm whether this is a hard launch or a staged one, since staging changes the risk profile of every item below.4344## Analysis workflow45461. Walk the eight readiness layers in order and mark each ready, at risk, or blocked:47 - stock and fulfilment capacity, including the oversell scenario48 - product page: clarity, proof, objections, delivery promise, mobile49 - checkout: payment methods, discount mechanic tested, promo code live and scoped50 - feed and catalog: availability, price, images, identifiers accurate for the launch items51 - tracking: purchase event fires, values correct, no duplicate counting52 - lifecycle: launch email and SMS scheduled, back-in-stock and abandoned flows not conflicting53 - support: expected question themes have answers, coverage matches the peak54 - margin: the planned price and discount survive fees, shipping, and expected returns552. For each layer, name what has actually been verified and what is only assumed. Assumed is not ready.563. Test the discount or promo mechanic end to end before launch, including the edge cases: stacking, minimum thresholds, excluded SKUs, and expiry.574. Model the oversell case explicitly: what happens if demand is three times the plan and stock runs out mid-campaign.585. Produce a go, go-with-conditions, or hold verdict with the conditions named and owned.596. Define the first-hour and first-day watch list, and the rollback trigger for each.6061## Decision and evidence standard6263Tag every finding with evidence: `url`, `screenshot`, `export`, `inventory_export`, `feed_diagnostics`, `policy`, `margin_csv`, `promo_calendar`, `hypothesis`, or `needs_data`. Full vocabulary: `../references/output-standard.md`.6465Rank findings by what they would cost on launch day, not by how hard they are to fix.6667A layer nobody verified is `needs_data` and cannot be marked ready. Silence is not a pass.6869## Output format7071### Go / no-go verdict7273Go, go with conditions, or hold. Name the conditions and their owners.7475### Readiness board7677| Layer | Status | Evidence | Blocker | Owner | Due before launch |78|---|---|---|---|---|---|7980### Blockers8182Everything that must be closed before go, ordered by launch-day cost.8384### Oversell and failure scenarios8586What happens if demand overshoots, stock runs out, or tracking breaks, and what the response is.8788### Watch list and rollback8990| Signal | Where to look | Threshold | Action |91|---|---|---|---|9293### Missing data9495List every layer nobody could confirm before the deadline, with the person who would have known. That list is the real risk register for launch day, and it is more useful than the layers that passed.9697## Example input and output9899Input:100101- launch brief with date and planned spend102- launch product URLs103- stock position104- flow schedule and promo code details105106Good output excerpt:107108| Finding | Evidence | Severity | Confidence | Business impact | Effort | Owner decision |109|---|---|---|---|---|---|---|110| Launch promo code stacks with the existing welcome code, taking two SKUs below cost | `screenshot`, `margin_csv` | critical | high | margin | XS | do_now |111| Back-in-stock flow will fire against the same list as the launch email on the same morning | `export` | medium | high | retention/support_load | S | do_now |112113What not to do yet: mark tracking ready because it worked last month. Verify a test purchase on the launch items.114115## Guardrails116117- Do not mark a layer ready on assumption. Unverified is `needs_data`.118- Do not give a go verdict while a critical blocker is open, even under time pressure.119- Do not fix anything yourself during the check. The point is a list the owner can act on before the deadline, and an unannounced fix on launch morning is how two people change the same thing twice.120- Do not promise launch performance.121- Do not skip the oversell scenario because it feels optimistic. It is the most common launch failure.
mardab96