Assess whether validated implementation work is ready for human-approved merge, release, or deployment. Use when Codex is asked to prepare release readiness, summarize validation and CI/CD status, check approvals, review unresolved risks, confirm rollback notes, produce release evidence, or decide whether work can move from validation review to human release approval.
Prepare a human release decision from validated implementation work. This skill gathers the final evidence trail, checks that required approvals and gates are present, highlights unresolved risks, and recommends whether the work is ready for human-approved merge, release, or deployment.
Inspect context.
Read README.md, AGENTS.md, relevant validation artifacts under spec/validation/, the ExecPlan, and linked requirements, features, stories, designs, and ADRs. Inspect current branch state and changed files with git status --short.
Confirm release scope. Define what is being considered for release: a story, feature, milestone, branch, pull request, deployment candidate, documentation update, or configuration change.
Gather readiness evidence. Summarize validation results, test commands, CI/CD status when available, Playwright screenshots for UI work, security review notes, quality gate notes, implementation review notes, and unresolved follow-ups.
Check approval state. Verify which human checkpoints were explicitly approved and which remain pending. Do not treat Codex or subagent readiness judgments as approval.
Check release risks. Identify unresolved product, architecture, security, privacy, data, migration, operational, rollback, observability, performance, or support risks. State whether each risk blocks release, requires human acceptance, or can become follow-up work.
Check rollback and recovery. For deployment or customer-visible changes, confirm there is a rollback or recovery path. If no runtime exists yet, record that rollback is not applicable. If rollback is required but missing, mark release readiness as blocked.
Draft release readiness summary.
Use a concise Markdown summary in the response or create/update a focused release-readiness artifact under spec/release-readiness/ if durable evidence is needed. Do not create release notes, tags, deployments, or PR actions unless the user explicitly asks.
Recommend subagent review when risk warrants it.
If the user explicitly asks for subagents, parallel review, or independent validation, use release_readiness_reviewer for final readiness, validation_gate_reviewer for validation evidence, security_reviewer for security-sensitive releases, quality_gate_reviewer for test/build/lint quality, and implementation_reviewer for plan-to-implementation alignment.
A release-readiness review should answer:
Use these advisory states:
Ready for human release approval: evidence is complete enough for a human release decision.Ready with accepted risks: evidence is mostly complete, but named risks require explicit human acceptance.Blocked: missing approval, failed validation, unresolved release risk, missing rollback, or incomplete evidence prevents release.Not applicable: release readiness does not apply to the current change, such as early specification-only work.These states are advisory only and must not be treated as release approval.
End release-readiness work by asking the human to approve or revise:
Codex and subagents may recommend readiness, but must not merge, release, deploy, tag, announce, or mark release complete without explicit human approval.
When the human approves release and there is post-release evidence, incident data, feedback, metrics, or follow-up learning to capture, use the lifecycle-retrospective skill.
When completing release-readiness review, provide: