Production readiness

An autonomous audit that answers one question with evidence: can this product face real users now, and if not, what stands in the way? It runs start to finish without stopping to ask, covers every surface and every applicable part of the product, and returns a structured payload plus a report. The report ranks each part and each surface by risk and gives a go/no-go decision for each surface and for the whole product.

The skill is independent of stack, vendor, region and agent harness. Tools and vendors named in the references are examples. Use what the project actually runs on.

How the run works

This is designed to be one long, thorough run. Work through the phases below until every applicable check has a recorded result, then produce the deliverables. Do not stop partway to ask questions. When something is ambiguous, make the most reasonable assumption, record it in run.assumptions, and continue. A wrong assumption stated plainly is easy for the owner to correct. A run that stops halfway gives them nothing.

1. Scope. Choose the profile from the request (table below); default to Pre-Launch Gate for an unlaunched product and Full Audit for a live one. Establish what the product is, who uses it and where (product.markets drives privacy, tax, accessibility and consumer law), and what environments you can reach. Then reconnoitre the project for its stated intent, wherever it lives and whatever it is called: a blueprint, PRD, spec, business plan, brand brief, agent instruction files (AGENTS.md, CLAUDE.md, GEMINI.md and the like, which often point at the rest), READMEs, docs, the pricing page and store listings. Assume no folder or file name. Record in run.assumptions what you found and used, and where. The strongest statement of requirements found is the standard for the functional part; statements of pricing, brand and stack inform billing, cost, brand and infrastructure. Where there is none, derive the standard from the product's public claims.
2. Inventory surfaces. Find every surface the product exposes (catalogue below) from the repository, deploy configuration, DNS, app manifests, package manifests and docs. Record each in surfaces with a stable id, and mark which are core.
3. Decide applicability. For each of the 32 parts, decide whether it applies. Record every part that does not apply in parts with the reason. Anything not declared inapplicable must be assessed.
4. Gather evidence. Automated evidence first: run the project's own build, tests, linters and scanners, then the checks each reference lists. Then manual evidence: read code, walk journeys, probe endpoints and inspect pages, within the safety limits below. Each part's reference file lists its evidence sources.
5. Assess every check. For each applicable part, read its reference file and record a result for every check on every surface it applies to: pass, partial, fail, not_verified or not_applicable (with the reason in evidence). Omitting a check hides a gap. Apply the part's severity notes to set severity, and set core_flow: true where the check protects authentication, payment, the primary value action or data integrity. Add custom checks (SEC-C01) for risks the references do not cover.
6. Write findings. Every failing or partial check of Critical or High severity belongs to a finding, and lower-severity ones can be grouped into findings too. Findings carry evidence, user and business impact, a specific recommendation, effort (S/M/L), an owner ("unassigned" unless one is known; never invent names) and how the fix will be validated. Write the executive summary last.
7. Score and render. Save the payload as production-readiness.json in the output folder (below) and run python <this skill's directory>/scripts/readiness.py <output folder>/production-readiness.json. The script validates the payload and warns about checks you skipped. It computes scores, coverage, risk rankings and decisions, and writes production-readiness.md and production-readiness.result.json. Fix any errors and act on the warnings, then run it again.
8. Return. Reply with the decision, the top blockers, the items that must be verified by a person, the surface and part rankings (the top of each table is enough), and the paths to the report and payload.