Release Health Gates
Run deployment readiness and quality-signal gates so a solo builder’s release PR has rollback, observability, checks, and sign-offs documented before prod.
Overview
Release Health Gates is an agent skill most often used in Ship (also Operate iterate) that enforces deployment readiness and quality-signal checklists with GitHub-comment evidence before and after release.
Install
npx skills add https://github.com/athola/claude-night-market --skill release-health-gatesWhat is this skill?
- Deployment Readiness Gate with required inputs: filled deployment template, rollback in PR, validated dashboards, suppor
- GitHub comment skeleton for release readiness with scope freeze, QA, docs, support brief, and rollback owner
- Quality Signals Gate checklist covering 24h green checks, integration reruns, flaky triage, benchmarks, and error budget
- Data-source table mapping checks, deployments, and issues to GitHub REST endpoints for evidence snapshots
- Post-deployment steps: mark tracker Done, retro discussion, archive artifacts under release-train-health references
- 5-item Quality Signals Gate checklist
- 4-row GitHub data-sources table for checks and deployments
Adoption & trust: 1 installs on skills.sh; 304 GitHub stars; 2/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You are about to deploy but lack a single PR-visible record that scope is frozen, checks stayed green, rollback is owned, and observability links still work.
Who is it for?
Solo SaaS builders using GitHub PRs, trackers, and staging/prod deployments who want release train discipline without a full release manager.
Skip if: Pure local CLI drops with no GitHub checks, deployments, or shared tracker—most steps assume a repo-centric release process.
When should I use this skill?
Use when preparing a named production release and you need PR-visible readiness and quality evidence gates.
What do I get? / Deliverables
Your deployment PR carries mirrored gates, linked evidence, executive summary excerpt, and recorded sign-offs—then post-deploy tracker and retro steps are logged.
- Release Readiness GitHub PR comment
- Quality Signals evidence snapshot notes
- Post-deploy tracker updates and retro link
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship because the skill centers on release readiness, scope freeze, and pre-deploy gates—not day-two incident triage alone. Launch subphase fits scope freeze, executive status excerpts, support briefs, and final PR approvals immediately before deployment.
Where it fits
Mirror the readiness checklist in the deployment PR before requesting final code review.
Post the Release Readiness GitHub comment with rollback owner and support brief links.
Attach integration rerun proof and flaky-test issue links under Quality Signals Gate.
Mark tracker tasks Done and open a retro discussion referencing the Release Gate comment.
How it compares
Structured release gate checklists in the agent, not a CI platform replacement or automatic deploy button.
Common Questions / FAQ
Who is release-health-gates for?
Indie builders and tiny teams shipping named releases who need PR-comment readiness and quality evidence without hiring a release manager.
When should I use release-health-gates?
In Ship launch before promoting to production; in Ship review when freezing scope; and in Operate iterate when closing a release with retro and artifact archival.
Is release-health-gates safe to install?
It guides documentation and GitHub API reads for evidence; review the Security Audits panel on this page and scope any tokens to least privilege.
SKILL.md
READMESKILL.md - Release Health Gates
# Deployment Readiness Gate ## Required Inputs - Deployment issue template filled out. - Rollback steps included in PR description. - Observability dashboard links validated. - Support announcement drafted. ## GitHub Comment Skeleton ``` ### Release <name> Readiness - Scope freeze: <yes/no> (issue links) - QA status: <check summary> - Docs merged: <PR link> - Support brief: <discussion link> - Rollback owner: @handle ``` ## Steps 1. Mirror this checklist in the deployment PR. 2. Use tracker CSV export to confirm no open `High` priority work in release scope. 3. Attach `status-report-template.md` excerpt for executive summary. 4. Capture final sign-offs as PR approvals and mention handles. ## Post-Deployment - Update tracker tasks to `Done` and log actual effort. - Create retro discussion referencing Release Gate comment. - Archive artifacts under `docs/playbooks/release-train-health.md` references. # Quality Signals Gate ## Checklist - [ ] Required GitHub checks green for 24h. - [ ] Integration tests rerun after last commit. - [ ] Flaky tests triaged with tracking issue link. - [ ] Performance benchmarks attached to PR comment. - [ ] Error budget impact reviewed with SRE. ## Data Sources | Signal | GitHub Source | Notes | |--------|---------------|-------| | Checks | `GET /repos/{owner}/{repo}/commits/{sha}/check-suites` | Store snapshot hash in tracker notes. | | Deployments | `GET /repos/{owner}/{repo}/deployments` | Validate staging and prod status. | | Issues | label:`qa-blocker` | Drive gating conversation. | ## Escalation Path 1. If any check fails, tag `@release-captain` and owning engineer in PR. 2. Log blocker in tracker with `status="In Progress"` and pointer to GitHub artifact. 3. Update Release Gate comment with mitigation ETA. --- name: release-health-gates description: Standardizes release approvals with GitHub-aware checklists and deployment gates. Use before releasing to production to verify all gates pass. alwaysApply: false category: governance tags: - release - github - readiness - quality - governance dependencies: [] tools: [] provides: governance: - release-gates - rollout-scorecards reporting: - deployment-comment - qa-handshake usage_patterns: - release-train - hotfix-review - stakeholder-briefing complexity: intermediate model_hint: standard estimated_tokens: 700 progressive_loading: true modules: - modules/quality-signals.md - modules/deployment-readiness.md --- # Release Health Gates ## Purpose Standardize release approvals by expressing gates as GitHub-aware checklists. Ensure code, docs, comms, and observability items are green before deployment. ## Gate Categories 1. **Scope & Risk** – Are all blocking issues closed or deferred with owners? 2. **Quality Signals** – Are required checks, tests, and soak times satisfied? 3. **Comms & Docs** – Are docs merged and release notes posted? 4. **Operations** – Are runbooks, oncall sign-off, and rollback plans ready? ## Workflow 1. Load skill to access gate modules. 2. Attach Release Gate section to deployment PR. 3. Use tracker data to auto-fill blockers and highlight overdue tasks. 4. Update comment as gates turn green; require approvals for any waivers. ## Outputs - Release Gate markdown snippet (embed in PR/issue). - QA Handshake summary referencing GitHub Checks. - Rollout scorecard that persists in tracker data for retros. ## Exit Criteria - All release gates evaluated and documented. - Any blocking gates have waiver approvals recorded. - Deployment PR contains embedded Release Gate snippet. - Rollout scorecard saved for post-release retrospective.