releaselisted

Runs a repository's full release process end to end, driven by a `.claude/release.yml` committed to that repo — no hardcoded repo, workflow, or branch names. `/release init` interviews you, writes that config, and opens a PR for it. `/release dry-run` rehearses a release read-only, changing nothing. A full run baselines from the last successful release, reviews every PR merged since, audits docs and screenshots and stops with an [ON HOLD] issue if anything is stale (it reports staleness, never fixes it), opens a labelled review issue for explicit human approval, confirms the ref, deploys the docs site first, dispatches the release workflow with the approved issue's number, tracks it, locates the resulting PR or GitHub Release, announces it, and writes a self-contained HTML record of what shipped. Use on /release, or any ask to cut, ship, publish, or promote a release. Not for feature work (/code-development) or a red pipeline (/ci-pipeline). Needs `gh` or a GitHub MCP server — Claude Code only.
dawg-io/claude-skills · ★ 0 · DevOps & Infrastructure · score 72

Install: claude install-skill dawg-io/claude-skills

# release Runs a repository's release process end to end: audit what changed and whether docs and screenshots still match it, get human approval on a review issue, make sure the live docs site is current, dispatch the release workflow with that issue's number, track it, announce the outcome, and leave behind an HTML record of what shipped. Everything project-specific — which workflow, which branch, which inputs, where the release lands, where to announce it — comes from **`.claude/release.yml` in the repo being released**. This skill hardcodes nothing. `references/config-schema.md` documents every field; `references/examples.md` has worked configs to copy. This has real side effects: it opens and closes GitHub issues, dispatches a production CI workflow, and posts an announcement. Move deliberately. Hard rules, restated up front because they're the ones that erode under "just ship it" pressure: 1. **Never skip the docs gate (Phase 3) or the approval gate (Phase 4).** They are the two things standing between a stale release and production. 2. **The docs gate reports, never fixes.** Finding and describing the gap precisely is this skill's job. Drafting docs or regenerating screenshots is the user's. 3. **Never guess a name** — workflow, input, label, or repo. Every one is either read from the config or discovered from the repo, then validated against the live workflow YAML. 4. **The config is the contract; the repo is the truth.** Where they disagree, stop and say