# Release Readiness

> Go / no-go gate before any deployment. Checks failure modes, rollback plan, cost, production bar, and definition of done. Trigger before releasing to any environment that carries real consequences.

- Skill: `jpantsjoha/release-readiness` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jpantsjoha/release-readiness`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jpantsjoha/release-readiness/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: jpantsjoha (https://skillmd.com/u/jpantsjoha)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jpantsjoha/release-readiness

---


# Release Readiness

> **A working demo is not evidence of production readiness. Production readiness is proven through sustained operation, incident handling, cost predictability, and controlled evolution.**

This skill enforces the production bar. It produces a go / no-go verdict with a signed checklist. No checklist = no go.

## When to use

- Before deploying to staging or production
- Before handing a system to another team
- Before declaring a sprint or milestone complete
- When someone says "it works on my machine"

## Procedure

1. **Validate the definition of done** — confirm that acceptance criteria from the spec are met. "Looks good" is not a criterion. Run the actual validation commands.

2. **Check all quality gates pass**:
   - `make lint` — style and static analysis clean
   - `make typecheck` — no type errors
   - `make test` — unit tests green
   - `make e2e` — end-to-end tests green (or equivalent for your stack)
   - No outstanding HIGH or CRITICAL findings from security scan

3. **Name the failure modes** — at minimum:
   - What happens if the service is unavailable?
   - What happens under unexpected load?
   - What happens if a dependency (external API, database, queue) is degraded?
   - What is the data-loss risk?

4. **Confirm rollback exists and is tested** — a rollback plan that has never been tested is not a rollback plan. If the rollback has not been exercised, flag it.

5. **Estimate cost impact** — LLM calls, storage writes, egress, third-party API calls. Any unbounded cost vector must be capped or accepted explicitly.

6. **Confirm monitoring and alerting** — what fires when this breaks? Who gets the alert? What is the on-call runbook?

7. **Check data boundaries** — does the release touch PII, regulated data, or cross a tenant boundary? If yes, confirm the appropriate controls are in place.

8. **Sign off** — record: who reviewed, what was checked, what was accepted as known risk, and the go/no-go verdict.

## Outputs

- Signed release checklist (append to PR or release doc)
- Go / no-go verdict
- List of accepted known risks with named owners

## Guardrails

- **No go without a rollback plan.** "We'll figure it out" is not a rollback.
- **Green CI is necessary, not sufficient.** CI validates happy paths. Release readiness validates failure modes.
- **Cost estimates are not optional.** An unbounded LLM call in a hot path is a production incident waiting to happen.
- **Monitoring must exist before go-live, not after.** "We'll add monitoring later" means the first incident is invisible.

## Anti-rationalization table

| Excuse | Counter |
|---|---|
| "CI is green, we're good to go" | CI checks known paths. Release readiness checks failure modes CI doesn't cover. |
| "We'll monitor it after launch" | The first failure will be invisible. Add monitoring before go-live. |
| "Rollback is just redeploy the previous version" | Untested. Run the rollback in staging first. |
| "Cost is fine, it's low traffic" | Low traffic + an LLM loop bug = runaway spend. Cap it. |