Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

Comenzar

source-command-release

Estrellas133

Forks1

Actualizado26 de junio de 2026 a las 02:44

Review and merge the release-plz release PR with explicit user confirmation

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

utensils

utensils/nxv

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

SKILL.md

readonly

name	source-command-release
description	Review and merge the release-plz release PR with explicit user confirmation

source-command-release

Use this skill when the user asks to run the migrated source command release.

Command Template

Release

Releases are driven by release-plz (release-plz.toml + .github/workflows/release-plz.yml). On every push to main it maintains a chore: release vX.Y.Z PR with the version bump and CHANGELOG update derived from conventional commits. Merging that PR ships the release — release-plz pushes the vX.Y.Z tag, which triggers release.yml (static binaries, GitHub release, crates.io, Docker) and flakehub-publish-tagged.yml.

This command walks that flow safely. Never merge the release PR without explicit user confirmation — it is an outward-facing, hard-to-reverse action.

Phase 1: Locate the release PR

gh pr list --repo utensils/nxv --search "chore: release in:title" --state open

If none exists, check whether main has unreleased conventional commits since the last tag (git log $(git describe --tags --abbrev=0)..origin/main --oneline). If there are releasable commits but no PR, check the latest Release-plz workflow run for errors (gh run list --workflow release-plz.yml).

Phase 2: Review what will ship

Show the PR's version bump (Cargo.toml diff) and CHANGELOG addition.
Verify the version follows the project convention: feat: commits bump the 0.x minor (features_always_increment_minor = true), fixes bump patch.
If the version or changelog is wrong, edit the release PR directly (it is a normal editable PR) — release-plz preserves manual edits unless new commits land on main.

Phase 3: Pre-flight

All CI checks on the release PR must be green. If checks show "Expected / Waiting", the App token is misconfigured — see release-plz.yml comments.
Confirm no other PR is about to land that should be in this release.

Phase 4: Confirm and merge

Present a summary (version, commit list, changelog) and require the user to confirm with the explicit version number (AskUserQuestion). Then:

gh pr merge <PR> --repo utensils/nxv --squash

Phase 5: Monitor

The Release-plz workflow on main pushes the tag.
The Release workflow builds binaries and publishes — monitor with gh run list --workflow release.yml / gh run watch.
Verify the GitHub release has all four binaries + SHA256SUMS.txt, crates.io has the new version, and ghcr.io has the version tag.

Manual escape hatches

Tagging failed after the release PR merged: re-run the Release-plz workflow on main (it is idempotent — existing tags are the gate).
The old fully-manual flow (bump Cargo.toml, edit CHANGELOG, tag by hand) still works in emergencies but must match release-plz's expectations (tag vX.Y.Z, CHANGELOG section ## [X.Y.Z] - YYYY-MM-DD).

Más de este repositorio

mismo repositorio

nxv

utensils/nxv

Find any version of any Nix package across nixpkgs git history using the nxv CLI or HTTP API. Use when asked which nixpkgs commit shipped a specific package version (e.g. "python 2.7", "nodejs 15", "ruby 2.6"), when looking up package metadata/license/homepage, when generating a `nix shell nixpkgs/<commit>#pkg` invocation for an old version, or when querying the public/private nxv server. Triggers include "find python 2.7 in nixpkgs", "which commit had nodejs 15.14", "when was foo added/removed", "give me the nix shell command for ruby 2.6", "search nixpkgs for X", or any question about historical Nix package versions.

Release

This command walks that flow safely. Never merge the release PR without explicit user confirmation — it is an outward-facing, hard-to-reverse action.

Phase 1: Locate the release PR

gh pr list --repo utensils/nxv --search "chore: release in:title" --state open

Phase 2: Review what will ship

Show the PR's version bump (Cargo.toml diff) and CHANGELOG addition.

Verify the version follows the project convention: feat: commits bump the 0.x minor (features_always_increment_minor = true), fixes bump patch.

If the version or changelog is wrong, edit the release PR directly (it is a normal editable PR) — release-plz preserves manual edits unless new commits land on main.

Phase 3: Pre-flight

All CI checks on the release PR must be green. If checks show "Expected / Waiting", the App token is misconfigured — see release-plz.yml comments.

Confirm no other PR is about to land that should be in this release.

Phase 4: Confirm and merge

Present a summary (version, commit list, changelog) and require the user to confirm with the explicit version number (AskUserQuestion). Then:

gh pr merge <PR> --repo utensils/nxv --squash

Phase 5: Monitor

The Release-plz workflow on main pushes the tag.

The Release workflow builds binaries and publishes — monitor with gh run list --workflow release.yml / gh run watch.

Verify the GitHub release has all four binaries + SHA256SUMS.txt, crates.io has the new version, and ghcr.io has the version tag.

Manual escape hatches

Tagging failed after the release PR merged: re-run the Release-plz workflow on main (it is idempotent — existing tags are the gate).

The old fully-manual flow (bump Cargo.toml, edit CHANGELOG, tag by hand) still works in emergencies but must match release-plz's expectations (tag vX.Y.Z, CHANGELOG section ## [X.Y.Z] - YYYY-MM-DD).