prelaunch_website_qa v1.0.0

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.

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

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

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

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

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

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

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

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

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