App Launch Readiness Review: Eight Checks, Evidence and Next Actions
Build a release checklist from supplied evidence, reproduce three review outcomes and keep missing checks visible. A free local workflow for HTML and Markdown handoffs.
Fastest way
Ask your AI to do it
Paste this into the AI agent you already use:
Use Launch Readiness Review with my supplied release evidence. Ask for version, environment, actual review date and scope. Keep missing checks unknown, require evidence for pass and prioritize observed failures. First run the fictional example into a new directory and verify 2 pass, 2 fail, 4 unknown and Blocked. Produce HTML and Markdown without overwriting prior reports. Do not run payments, external tests, deployments or paid APIs; the report organizes evidence and does not certify a release.
What is an app launch readiness review?
An app launch readiness review records which release checks have evidence, which are blocked and which still need investigation. Launch Readiness Review v1.0.0 organizes eight categories into HTML and Markdown reports with prioritized next actions. It does not run browser tests, verify a payment, restore a database or certify a release. A green declaration is supplied evidence, not an independently verified result.
The package is free for verified Skillrove accounts. The local builder needs Node.js 24 and its standard library; no dependency installation, network request or paid API is needed to build a report. An assistant can help prepare inputs, but its model access is separate.
Collect evidence for the eight checks before assigning pass
Use the actual checkedAt date, environment URL, product version and scope. Keep secrets and personal records out of reports. Use pass only with a specific evidence note; use fail for an observed defect and unknown when no adequate check exists. Omitted categories remain unknown. Do not mark a payment or policy check passed merely because a settings page exists.
| Check ID | Record actual observations |
|---|---|
| public | Signed-out HTTPS routes and the intended release/version |
| authentication | Sign-in callback, sign-out and account isolation |
| payments | Authorized test-mode checkout, fulfillment and cancellation evidence |
| packages | Download, integrity, installation and a usable first result |
| mobile | Narrow layout, keyboard navigation and touch interactions |
| support | An authorized synthetic request and a resolved support handoff |
| recovery | Isolated restore exercise and reviewed operational access |
| legal | Reviewed product, pricing, data-handling and content-rights information |
Run the fictional example and expect Blocked
From the complete installed package, run the command below into a new output directory. Open launch-report.html and compare it with launch-report.md and examples/launch.json. The fictional FernNotes example has eight checks: two pass, two fail and four unknown. Blocked is the correct result; the six next actions put observed failures before missing evidence.
Inspect the fictional launch report before installing
node scripts/build-report.mjs --input examples/launch.json --output ./my-launch-reviewReproduce the three decisions without inventing evidence
Copy the fictional JSON to your own working file. For a calculation exercise only, change both failing checks to unknown and rebuild into a fresh directory: expect two pass, zero fail and six unknown. Keep this synthetic exercise separate from any actual release record. Changing labels cannot repair the product.
The builder rejects a pass without evidence, duplicate check IDs and invalid review dates. It protects existing output directories. Ready for human review is a handoff for a responsible reviewer; it is not deployment authorization, security certification or proof of a working checkout.
| Input state | Expected report decision |
|---|---|
| At least one fail | Blocked |
| No fail, but at least one unknown | Needs evidence |
| Eight pass entries, each with supplied evidence | Ready for human review |
Close a real blocker, then link the new evidence
Work on the highest-priority observed defect, repeat the same check in the target environment and update only the evidence that changed. Preserve the previous report for comparison. Share the version, scope, two report files, unresolved checks and responsible owners; review HTML and Markdown before distribution.
Capture a reproducible defect and compare the repaired result