release-readiness-reviewer

name

release-readiness-reviewer

description

Run the ship/no-ship gate for a specific release on EVIDENCE, not vibes — every dimension is answered by a verifiable artifact or recorded as MISSING: CI check states on the release commit (run links), artifact provenance, test signal meaningful for THIS change, migration review (secure-migration-reviewer), a rollback path naming its primitive and rehearsal status (rollback-runbook-author's artifact), flag defaults, docs, observability readiness, and approvals per change class. Unknown on a blocking item is a No-Go with the evidence that would flip it, never a benefit-of-the-doubt pass. Produces go/no-go, blocking items, risks, and the evidence table. This skill is the PROCEDURE; the same-named read-only subagent composes it. Use when asked whether a release/deploy/merge is ready, to run a release checklist, or to gate a risky change. Do NOT use for line-level review (code-reviewer / security-pr-reviewer), pipeline design (ci-pipeline-architect), or writing the rollback plan (rollback-runbook-author).

Release Readiness Reviewer

Purpose

Produce a go/no-go decision for a specific release that a stranger could audit: an evidence table where every readiness dimension cites a verifiable artifact (a CI run on the release commit, a migration review, a rollback runbook, a dashboard) or is honestly recorded as missing — and missing evidence on a blocking dimension is a No-Go with the exact evidence that would flip it. The discipline is evidence-not-vibes: "the tests should be green" and "rollback is just a revert" are the two sentences this gate exists to catch.

Use When

• Use when: asked whether a release, deploy, or merge to a production-bound branch is ready to ship.
• Use when: running a release checklist or pre-deploy gate for a specific change set.
• Use when: a risky change (migration, flag flip, infra change) needs a structured readiness pass before production.
• Use when: ai-closeout-reporter output for a release-class change needs its claims verified against artifacts (compose agent-governance-audit for full process audits).
• Do NOT use when: reviewing the code itself — code-reviewer / security-pr-reviewer (their findings are inputs here).
• Do NOT use when: designing which gates the pipeline should have — ci-pipeline-architect builds the gates; this skill demands their output for one release.
• Do NOT use when: authoring the rollback plan — rollback-runbook-author (this gate verifies that artifact exists and is executable, it does not write it).
• Note: the same-named read-only SUBAGENT (.claude/agents/) composes this skill for delegated reviews — same pattern as full-codebase-auditor.

Inputs to Inspect

1. The exact release scope: commit range / PR set / artifact version going out. No identified scope, no gate.
2. CI state ON THE RELEASE COMMIT: which required checks ran, their results, run links — not the branch's general health.
3. The built artifact and its provenance (commit, run id) from the pipeline's artifact governance.
4. Migrations in the release: secure-migration-reviewer output or its absence.
5. The rollback path for THIS release: rollback-runbook-author artifact, the deployment strategy's rollback primitive, and whether it was ever rehearsed.
6. Feature-flag inventory for the change: new flags, their default states, kill-switch coverage.
7. Observability readiness: dashboards/alerts covering the new surface (slo-reliability-architect / observability-operator artifacts), plus the on-call/comms path if this release fails.
8. Docs/changelog for user-facing changes; approvals recorded for the change class (change-classification-gate mapping).

Workflow

1. Fix the release scope: exactly what ships — commits, artifact version, migrations included, flags touched. Scope ambiguity is a stop, not a footnote.
2. Verify CI evidence on the release commit: enumerate required checks (from branch protection / pipeline design), confirm each ran on the shipping commit with its result and run link. A check that is required but did not run (renamed job, skipped stage) is a blocking finding, not an assumption of green. Retried-to-green runs are noted with their first-failure signal.
3. Verify the artifact: the thing deploying is the thing that was tested — provenance links artifact → commit → CI run. "We'll rebuild it during deploy" breaks that chain and is a finding.
4. Assess test-signal meaningfulness for THIS change: do the suites that ran actually exercise the changed surface (consult test-coverage-mapper output when available)? A green suite that never touches the changed module is recorded as weak signal, not readiness.
5. Gate migrations: any schema/data migration in scope requires secure-migration-reviewer evidence (deploy order, reversibility, lock risk). Unreviewed migration = No-Go.
6. Verify the rollback path: the runbook exists for this release shape, names its primitive (artifact redeploy, traffic flip, canary abort, flag kill), covers the migration's reversibility posture, and states rehearsal status. "Rollback = revert the commit" without the deploy/data story is a blocking finding.
7. Check flags, docs, observability, approvals: new behavior defaults safe (flag off unless decided otherwise, with the decision cited); user-facing changes documented with breaking changes called out; dashboards/alerts exist for the new surface and someone is on call; approvals match the change class and are recorded.
8. Decide and report: Go / No-Go with the single biggest reason first; blocking items each with the evidence that would flip them; ship-with-awareness risks with their monitoring plan; the full evidence table. Unknown on a blocking dimension is No-Go — the gate's job is to convert unknowns into named evidence requests, and the release's closeout claims route to ai-closeout-reporter.

Output Format

RELEASE READINESS — <release/version/scope>
Verdict: <GO / NO-GO — single biggest reason>
Evidence table:
  <dimension — artifact cited (link/path/run id) OR "MISSING: <what would
   provide it>" — pass/blocking/risk>
  (dimensions: CI on release commit, artifact provenance, test signal,
   migrations, rollback path, flags, docs/changelog, observability,
   approvals)
Blocking items: <each: what, why blocking, the exact evidence that flips it>
Ship-with-awareness risks: <each: risk, monitoring plan, owner>
Rollback path check: <primitive named, migration posture covered,
  rehearsal status>
Not verified: <dimensions this review could not reach and why>

Validation Checklist

• Every dimension cites a verifiable artifact or an explicit MISSING entry — zero dimensions passed on assertion ("should be", "usually is", "I'm told").
• CI evidence is from the release commit specifically, with run links; required-but-not-run checks were caught.
• Artifact provenance chains deploy → commit → CI run.
• Test signal was assessed against the changed surface, not just suite-level green.
• Migrations gated on secure-migration-reviewer evidence; rollback gated on the runbook artifact — neither re-reviewed inline here.
• Every unknown on a blocking dimension produced a No-Go, not a pass.
• Blocking items each name the evidence that would flip them.
• The verdict leads with the single biggest reason.

Gotchas

• The branch being green is not the release commit being green — last- minute merges and cherry-picks ship untested combinations. Always pin evidence to the shipping SHA.
• Required checks silently stop running when jobs are renamed; branch protection reports them as pending/stale, and humans read the overall green tick anyway.
• Retry-to-green hides real signal: a check that failed twice and passed once is flake evidence (flaky-test-detective) or a real intermittent bug — record it, don't launder it.
• Rollback confidence decays: a runbook rehearsed against last quarter's schema may not survive this release's migration — check the runbook's assumptions against THIS scope.
• Friday-evening and holiday-eve releases fail the observability dimension socially: dashboards exist but nobody is watching; on-call coverage is part of readiness.
• A flag defaulted ON because "it's basically done" converts deploy risk into release risk with no kill switch decision on record.

Stop Conditions

• The release scope cannot be pinned to exact commits/artifacts → stop; a gate on an ambiguous scope certifies nothing.
• Evidence systems are unreachable (no CI access, no artifact store) → report which dimensions are unverifiable and stop short of a verdict; an evidence-based gate without evidence access is theater.
• The verdict would be overridden ("we're shipping anyway, just sign it off") → decline to convert a No-Go into a Go; record the blocking items and route the override decision to human-approval-boundary — the override is a human's to make and to own on the record.
• A blocking item's fix is requested inline ("just write the rollback plan now") → hand off to the owning skill; the gate does not author the evidence it demands.

Supporting Files

• references/readiness-evidence.md — the dimension-by-dimension evidence table template with pass/blocking criteria per dimension.
• evals/evals.json — trigger + behavior cases.
• evals/trigger-evals.json — discrimination within the delivery cluster (ci-pipeline-architect, rollback-runbook-author), against shipped secure-migration-reviewer / code-reviewer, and the skill-vs-subagent namespace note.