Release Readiness Reviewer

---
name: release-readiness-reviewer
description: 'Run the ship/no-ship gate for a specific release on EVIDENCE — every blocking dimension cites an artifact or is MISSING: CI on the exact candidate or shipping tree, artifact provenance, change-relevant tests, migration review, rollback path and rehearsal, flag defaults, docs, observability, and approvals. For auto-deploy-on-merge, gate the exact PR or merge-queue candidate before merge and verify the final commit afterward. Unknown on a blocking item is No-Go with the evidence that would flip it. Produces go/no-go, blockers, risks and an evidence table. The same-named read-only subagent composes this procedure. Use for release/deploy/merge readiness or a risky change gate. Do NOT use for line review (code-reviewer), pipeline design (ci-pipeline-architect), or writing rollback plans (rollback-runbook-author).'
---

# Release Readiness Reviewer

**Reading key:** Continuous integration (CI) runs automated checks; a pull
request (PR) proposes a change before merge. A release commit is the exact
commit that ships; a merge queue may test a combined candidate tree first.

## 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 exact candidate or shipping tree, 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 exact tree available at the gate: shipping commit for a
   post-merge release, or exact PR head / merge-queue candidate when merge
   automatically deploys. Record which checks ran, results and links; plan
   verification on the final merged commit after merge.
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 gated tree**: enumerate required checks
   (from branch protection / pipeline design), confirm each ran on the
   exact shipping commit when it exists, or the exact PR head/merge-queue
   candidate before an auto-deploying merge. Record the correspondence and
   any combined-tree risk; verify the final merged/deployed commit afterward.
   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. If an auto-deploying
   merge builds the artifact afterward, verify the build/provenance contract
   before merge and the actual artifact against the merged commit afterward.
   An untracked rebuild during deploy breaks the 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 exact gated tree, 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 exact shipping commit or, before an
      auto-deploying merge, the exact gated PR/merge-queue candidate;
      required-but-not-run checks and final-commit follow-up are recorded.
- [ ] Artifact provenance chains deploy → commit → CI run, with actual
      post-merge verification when an auto-deploying merge builds it.
- [ ] 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 proof of the exact candidate. Pin the
  pre-merge gate to its head or merge-queue tree; last-minute combined
  changes need new evidence, and the final shipping SHA needs post-merge
  verification.
- 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 **No-Go** for each unverifiable blocking dimension and the exact
  evidence needed to reconsider it; unknown is not a pass.
- 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.