production-readiness

Production Readiness

Assemble cross-domain evidence into a launch decision. This skill defines the minimum production evidence packet by risk class, maps every evidence category to a named source or an explicit missing-evidence outcome, and produces one of four launch decisions with an accountable owner. It does not duplicate release checklists, does not produce a universal risk score, and routes detailed checks to the existing specialist skills.

When to load this

Load when any of these triggers matches:

• A service, feature, or change is approaching a launch decision and needs a production-readiness review.
• Evidence from multiple domains (ownership, SLOs, security, data, support, cost, observability) must be assembled into one reviewable record.
• A launch review board, readiness gate, or accountable owner needs a structured go / no-go / defer / exception recommendation.
• A migration-dependent release needs evidence that every dependency is ready.
• A low-risk documentation-only change needs proportional (not full-scale) readiness review.

When not to use

• Release pipeline mechanics — promotion, canary stages, CI/CD gate configuration, versioning, and artifact management. Route to release-engineering. Release-engineering owns the pipeline gate; production-readiness owns the cross-domain evidence assembly and launch decision.
• Incident response, SLO operations, on-call, and reliability engineering. Route to site-reliability-engineering. SRE owns the live-service health boundary; production-readiness owns the pre-launch readiness boundary.
• Security implementation, threat modeling, or penetration testing. Route to secure-software-engineering or security-audit-methodology.
• Data pipeline operations, schema migration engineering, or ETL/ELT design. Route to data-engineering.
• Test strategy, regression planning, and quality gates. Route to qa-methodology.
• Platform infrastructure provisioning or IDP design. Route to platform-engineering.
• Implementation planning, work breakdown, or delivery coordination. Route to implementation-planning.
• Spec authoring and SDD gate mechanics. Route to spec-driven-development.
• Verification verdicts against explicit criteria. Route to verification-methodology.
• API contract design and versioning policy. Route to api-design-and-evolution.
• Statistical analysis, experimental design, or causal inference. Route to data-scientist.
• End-to-end production lifecycle orchestration across all readiness dimensions. Route to the production-excellence bundle (prose reference only — not yet landed). Production-excellence composes production-readiness, migration-engineering, resilience-and-recovery, capacity-and-cost-engineering, and incident-learning into a full production-operations lifecycle.

Risk classes and evidence scaling

The readiness evidence packet scales by risk class. A low-risk documentation release must not demand the same evidence as a user-facing service launch.

Risk class is determined by the highest-risk dimension present, not by averaging or scoring. If any single dimension (e.g. data migration irreversibility, trust-boundary crossing) qualifies as High, the entire review is High.

Production evidence checklist

The 11 evidence categories form the minimum production evidence packet. Every category must have either a named source artifact or an explicit missing-evidence outcome.

Structured fields (mandatory)

These four categories must appear as structured fields (checklist markers, table rows, or labeled form fields) — never only narrative prose.

• Ownership — named owner or owning team with escalation path; recorded in the evidence checklist above.
• Rollback — rollback plan or recovery path with rehearsal evidence; recorded in the evidence checklist above.
• Support — runbook, support playbook, or handoff document; recorded in the evidence checklist above.
• Observability — dashboards, alert rules, monitoring coverage; recorded in the evidence checklist above.

Launch decision outcomes

Every readiness review produces exactly one of four outcomes. The accountable owner is recorded with the decision.

The exception outcome requires an explicit human-approval annotation — a named individual who approves the waiver. This approval is distinct from any automated check result and must be recorded separately (e.g., in an escalation record or exception log). The exception cannot be self-granted by the submitter.

Workflow

1. Determine risk class. Map the change against the trigger-condition table above. Select Low, Standard, or High.
2. Collect evidence. For each of the 11 categories, record a named source or a gap with owner and due date. Use the readiness record template.
3. Assess completeness. Check that every category has an entry. A category with a gap annotation is complete for the purpose of the review — the gap is visible.
4. Produce a launch decision. Map the evidence against the risk-class requirements and produce one of: Go, No-go, Defer, Exception.
5. Record the decision. Commit the readiness record with the accountable owner and, for exceptions, the explicit human-approval annotation.

No universal risk score

This skill does not produce a universal risk score, aggregate risk rating, or total risk number. Each evidence dimension stands on its own and is assessed against the risk-class requirements individually. If individual dimensions are evaluated separately (e.g., a security dimension assessment or a data dimension assessment), the rationale for any weighting is stated explicitly in that dimension's evidence entry — there is no single number that summarizes readiness.

File map

Route-to table