release-readinesslisted

Assess whether a specific release candidate, build, artifact, application, service, mobile/desktop build, or API is ready for production in a named environment and issue an evidence-backed GO / GO_WITH_CONTROLS / NO_GO / DEFER verdict across product acceptance, QA, security, operations/reliability, documentation, billing/entitlements, and support/incident readiness. Use when the user names or implies a concrete candidate (version, build ID, branch/tag, artifact digest, deploy target) for launch/release gates, pre-deploy audits, "is this build ready to ship?", hotfix readiness, post-incident releases, and repeated delta/revalidation reviews. Do not use for first-time whole-project roadmap baselines or "analyze the entire repo" — use Repo to Roadmap. Do not use for ongoing weekly prioritization on an existing roadmap — use Product Operator. Orchestrate specialist evidence without pretending to replace security scans, live-app QA, legal/privacy review, or deployment authorization.
MaciejZet/agent-skills · ★ 1 · AI & Automation · score 74

Install: claude install-skill MaciejZet/agent-skills

# Release Readiness Treat release readiness as a **candidate-specific production decision**, not a repository quality score and not a generic checklist. Optimize against false-positive `GO`: missing scope, omitted gates, stale evidence, environment mismatch, and unapproved risk must reduce confidence or block the verdict rather than disappear from scoring. ## Non-negotiable invariants 1. Tie every verdict to an exact release candidate and target environment. 2. Separate **weighted readiness** from **binding gates**. Never average away a blocker. 3. Prove **scope completeness** before accepting a complete gate set. 4. Derive required gates from profile + risk flags; do not let omitted checks create a false green result. 5. Require candidate-bound, temporally admissible evidence for binding passes. 6. Treat `N/A` as exclusion with rationale, never as credit. 7. Separate `PASS_WITH_CONTROLS` from explicit `ACCEPTED_RISK`. 8. Keep governance gates (`legal`, `privacy`, etc.) outside majority/scoring logic. 9. Re-run the verdict after any material red-team finding or evidence downgrade. 10. Treat a readiness verdict as assessment evidence, **not authorization to deploy or perform side effects**. ## Workflow Follow this sequence: 1. **Identify the release candidate.** Capture release/build ID, artifact identity, target environment, `as_of`, and change set. 2. **Select profile and mode.** Use `references/risk-routing.md`. 3. **Complete the risk scope.** Resolve every required r