Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

Loslegen

source-command-release

Sterne133

Forks1

Aktualisiert26. Juni 2026 um 02:44

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

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

utensils

utensils/nxv

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·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).

Mehr aus diesem Repository

gleiches Repository

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).