* test(evals): scope claims to harness model fixtures and revision Append the neckbeard claims-scoping sentence to one representative expected_output per per-skill manifest so every corpus member states VAL-EVL-032 scope (harness, model, fixtures, revision under test). Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com> * test(product-lifecycle): upgrade integrated launch trajectory Add an explicit launch-decision assertion to the new-product lifecycle case so the integrated product-launch scenario terminates in a launch decision recorded as a lifecycle evidence-ledger entry (VAL-CRP-010), and scope its expected_output claims per VAL-EVL-032. Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com> * test(production-excellence): add integrated migration reconciliation failure case Add integrated-migration-reconciliation-failure: the production-excellence gate model returns No-go on a reconciliation mismatch, records the failure evidence, produces a rollback/roll-forward decision with an accountable owner, and does not proceed to launch (VAL-CRP-012). Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com> * test(agent-production-operations): add privacy boundary escalation case Add integrated-privacy-boundary-escalation (VAL-CRP-015): the runtime control plan halts a cross-boundary EU PII trace export before any data processing, names the privacy boundary, and escalates to jurisdiction- specific legal review and a human operator. Also add a tool-authority- health handoff assertion to the read-only contract case (VAL-CRP-016). Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com> * test(lifecycle-evals): add lifecycle evaluation corpus Add the #204 corpus home: run tooling (run-corpus.sh, fake adapter only), programmatic coverage validator (validate-corpus-coverage.py), machine- readable coverage index + human-readable coverage matrix, regression- detection and fixture/source notes, the bounded discovery brief, and a one-snapshot committed set of fake-adapter per-trial run artifacts with harness/model/date scoping fields. Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com> --------- Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
Production Readiness
Assemble cross-domain production evidence into a risk-scaled launch decision — from a lightweight documentation release to a full user-facing service launch.
Why Install This Skill
Every launch decision needs evidence from multiple domains: who owns the service, what SLOs protect it, whether security reviewed it, how to roll back, what it costs. Without a structured evidence packet, teams either launch with invisible gaps or get stuck in review churn. Production-readiness gives your agent a single, risk-scaled framework for assembling that evidence and producing a defensible go / no-go / defer / exception recommendation with an accountable owner attached.
After installing, your agent can run a proportional readiness review for any change — from a docs-only update (three evidence categories, self-review) to a customer-facing service launch (all 11 evidence categories with named sources, formal review, exception routing to explicit human approval). The skill routes detailed technical checks to the existing specialists (release-engineering, SRE, security, data, QA, platform) so it never duplicates what they already own.
What You Get
| Path | What it provides |
|---|---|
SKILL.md |
Risk-class definitions (Low/Standard/High), 11-category evidence checklist with source/gap fields, four launch-decision outcomes with accountable owners, exception routing to explicit human approval, and a route-to table for 12 specialist skills |
README.md |
This human-facing overview |
references/discovery-brief.md |
Survey of existing production and engineering skills with ownership boundaries vs release-engineering and site-reliability-engineering |
references/readiness-record.md |
Fillable readiness-record template with all 11 evidence categories, risk-class selection, and launch-decision recording |
evals/evals.json |
Five output-quality evaluation cases covering low-risk docs, user-facing launch, migration-dependent release, missing owner evidence (blocked), and exception requiring human approval |
Quick Start
- Determine the risk class for your change: Low (docs-only, internal tool ≤1 team), Standard (user-facing feature, API addition), or High (customer-facing launch, SLO-bearing, trust-boundary crossing).
- Fill the readiness record template (
references/readiness-record.md) — for each of the 11 evidence categories, provide either a named source or an explicit gap with owner and due date. - Produce a launch decision: Go (all evidence present), No-go (blocking gap), Defer (postponed with conditions), or Exception (waiver with explicit human approval).
- Record the decision with the accountable owner.
Triggers
- "Is this ready to launch?"
- "Run a production-readiness review"
- "Assemble the launch evidence packet"
- "Do we have all the evidence for go/no-go?"
- "Check production readiness for this change"
- "We need a readiness record before the launch review"
- "What evidence is missing before we can launch?"
- A launch-review board or readiness gate is approaching
- A migration-dependent release needs coordinated readiness assessment
- A low-risk change needs a proportional (not full-scale) readiness check
Requirements
- No runtime dependencies, API keys, or external services.
- The skill routes to existing catalog specialists for detailed technical checks; those skills must be present in the catalog for full routing capability (12 skills routed, all currently exist in the repository).