---
name: "prelaunch_website_qa"
description: "Run the final pre-launch QA gate on any website, on any builder or stack: walk every page, form, and link as a first visitor in a fixed order, test money flows through to the inbox and the receipt, check findability, access, and performance against published thresholds, test on a device matrix built from the audience, rank every break by what it costs, and finish with a signed go or no-go sheet before the launch post goes out. Triggers when someone asks to QA a site before launch, run a launch checklist, check a site before it goes live, do a final site review, or decide whether a site is ready to announce."
metadata: { "includeInPrompt": true }
---

# Prelaunch Website QA

## Purpose

Run the last check a website gets before strangers arrive, and turn it into
one decision: launch, launch with written waivers, or hold.

This skill is the visitor facing gate. It covers what a first visitor sees,
clicks, submits, and pays, on any platform or builder. Two neighbouring
skills cover other ground and this one calls them instead of repeating them:
click-path-audit crawls a site and scripts its flows, and
production-launch-checklist covers deploy infrastructure such as hosting,
databases, secrets, and rollback plumbing. If the launch needs those, run
them alongside. This gate still has to pass on its own.

The core habit: test outcomes, not appearances. A form is not tested when
it shows a thank you message. It is tested when the entry reaches the right
inbox, the notification fires, and the stored record matches what was typed.

## Severity ranking

Rank every finding by what it costs the launch, not by how ugly it looks.
The verdict rule at the end depends on these ranks, so rank honestly.

- S0, launch blocker. The site cannot do its job: a money page down or
  returning an error, checkout or the main form broken or delivering
  nowhere, the site blocked from search by a leftover noindex or a blanket
  robots disallow, the site served without HTTPS, or a legal page missing
  where the law or a payment provider requires one. Any open S0 means
  NO-GO, with no waivers.
- S1, major. A main path works badly: a broken link from a launch page, a
  form error state that loses typed input, wrong prices, dates, or contact
  details, a soft 404, a sitemap listing dead URLs, layout broken on a top
  audience device, or analytics not recording. S1 findings need a fix or a
  written waiver with an owner and a fix date.
- S2, minor. One page or a small audience is hurt: a missing meta
  description, a duplicate title, an image without alt, a slow heavy page,
  a missing security header that matters. Fix before launch when time
  allows, record either way.
- S3, polish. Cosmetic or future proofing: heading levels skipping, a
  missing favicon, minor spacing. Record and schedule. Polish never
  outranks an S1 fix in the last day.

## Workflow

1. Freeze and inventory. Set a content freeze, write the launch page list
   and the money paths, and list every form and integration. Name the fix
   owner, the sign off owner, and where the backup lives. Full detail for
   every pass is in `references/walk-checklist.md`.

2. Run the probe first. The bundled script checks the mechanical layer of
   the launch pages you name, plus robots.txt, sitemap.xml, a made up URL
   for soft 404s, and response headers, and writes a severity ranked
   report. It does not crawl and it does not judge content.

   `python3 ~/workspace/skills/prelaunch-website-qa/scripts/prelaunch_probe.py --base https://example.com --pages / /pricing /contact --output probe-report.md --json probe-report.json`

   The probe exits 1 when an S0 exists. Read its Not checked section out
   loud to whoever commissioned the QA: most of this gate is manual, and
   the probe report must never be presented as the whole QA.

3. Walk as a first visitor. Fresh profile, no login, entering from a direct
   link and from the home page. Read the money pages aloud, verify names,
   prices, dates, and contact details against their approved sources, and
   hunt leftovers: placeholder text, test products, sample posts, draft
   images, and staging links. Check the trust surfaces (about, contact,
   privacy, terms, refund terms where money moves) and the share preview
   of the home page and one money page.

4. Test the money flows end to end. Every form to the real inbox, including
   one deliberate bad submission per form. Checkout or booking in test
   mode, then in live mode at the smallest real amount the owner approves,
   through to the receipt and the refund path. Signup, login, and password
   reset with a fresh account. One double click on the pay or submit
   button must produce one order, not two.

5. Check findability on the production configuration. Read robots.txt line
   by line, open the sitemap, confirm no noindex or staging password
   survives on launch pages, and confirm titles and descriptions are
   unique. Sitemap limits from the protocol: 50,000 URLs and 50 MB
   uncompressed per file, listing only canonical URLs that return 200.
   Where a redirect map exists, walk its top entries by hand.

6. Check access and performance. Run the W3C Easy Checks set as a first
   review: keyboard order with visible focus, alt text, heading order,
   form labels, captions. Check contrast against WCAG 2.2 AA (4.5 to 1 for
   normal text, 3 to 1 for large text), reflow at 320 CSS pixels wide,
   text at 200 percent, and tap targets of at least 24 by 24 CSS pixels.
   Easy Checks is a first review, not a certification, and the report says
   so. For performance, record LCP, INP, and CLS against the web.dev good
   thresholds (LCP 2.5 seconds or less, INP 200 milliseconds or less, CLS
   0.1 or less, judged at the 75th percentile in field data), using a lab
   run plus a real phone check before launch, since a new site has no
   field data yet.

7. Walk the device matrix. Build it from the audience per
   `references/device-matrix.md`: the combinations that bring the traffic,
   always including one recent iPhone, one mid range Android phone, one
   desktop browser set, and the narrow widths. Real devices for the top
   rows and every money flow. Record each row as done, or name it on the
   sign off sheet as an accepted risk.

8. Prove measurement and operations. Open analytics and watch your own
   visit arrive in realtime, fire every conversion event once, confirm
   search console verification, send a test error alert to a person, and
   take the final backup with its location and restore steps written down.
   Write the rollback trigger before launch, not during an incident.

9. Sign off. Complete `references/sign-off-sheet.md`. The verdict is GO
   only with zero S0 open, GO WITH WAIVERS when S1 items carry a written
   waiver with an owner and a fix date, and NO-GO otherwise. No verdict
   ships on a verbal pass. The announcement, launch post, or launch email
   goes out only after the sheet is signed.

10. Recheck on launch day, on production. Rerun the probe against the
    production URL, repeat the single most important money flow live, and
    click the links in the actual launch post and bio. Production differs
    from staging in headers, redirects, and leftovers, so staging results
    never stand in for this pass.

## Output Contract

- The probe report (markdown and JSON): severity counts, every finding
  with URL, evidence, and fix, and the list of what the probe did not check.
- A findings list for the manual passes in the same shape: severity, page,
  steps to reproduce, evidence, owner.
- The completed sign-off sheet from `references/sign-off-sheet.md`, with
  money flow evidence, device rows, performance record, open findings and
  waivers, backup location, rollback trigger, and one verdict, signed and
  dated.
- A short launch note for the team: verdict, the top three risks that
  remain, and who is watching what during the first hours live.

## Operating Rules

1. Outcomes over appearances. No flow counts as tested until its result
   was seen where the business receives it: the inbox, the order list, the
   analytics realtime view, the bank or provider record.
2. Production is the evidence. A check that only ran on staging is marked
   as staging until the launch day recheck repeats it live.
3. Never waive an S0. An S1 waiver is written, owned, and dated on the
   sheet, or the finding blocks the launch like an S0.
4. Report only observed facts. Every finding carries a URL and evidence
   from a fetch, a screenshot, a test submission, or a device run. No
   invented timings, counts, or device results.
5. Stay polite on live infrastructure. The probe waits between requests by
   default. Do not load test, scan aggressively, or submit bulk test data
   to a production site during QA.
6. Test data identifies itself. Mark test submissions and accounts as QA
   tests, use the smallest live amounts the owner approves, and clean up
   or hand over every test record created.
7. Accessibility findings are a first review. State that plainly. Never
   certify WCAG conformance from this pass, and route a conformance claim
   to a full accessibility audit.
8. The sheet decides. If a stakeholder pushes to launch past the verdict,
   record the push, the name, and the accepted findings on the sheet. The
   record is the deliverable, not an argument after the fact.
9. Style: plain language, no em dashes, no promotional phrasing about the
   site being checked.