package-release

name	package-release
description	Cut and verify tag-driven `mithril-mastools` releases. Use when Codex needs to publish a new `Mithril.MasTools.*` version, trigger `.github/workflows/release-packages.yml` with a `v*` tag, confirm the GitHub Action completed, and verify GitHub Release plus GitHub Packages artifacts exist.

Package Release

Overview

Use this skill to ship a new Mithril.MasTools.* version through the repository's tag-driven GitHub Action. Read references/release-checklist.md for the concrete commands and verification queries before pushing the tag.

Workflow

1. Confirm the target semantic version and make sure the release intent is explicit.
2. Re-read .github/workflows/release-packages.yml, scripts/pack-release-packages.ps1, and README.md when the release flow may have changed since the last cut.
3. Run preflight checks:
   • git status --short must be clean or intentionally scoped.
   • gh auth status must show an active GitHub session with repo and workflow access.
   • git remote -v should point at github.com/MithrilMan/mithril-mastools.
4. Validate locally before tagging:
   • dotnet build Mithril.MasTools.slnx -c Release
   • pwsh -File scripts/pack-release-packages.ps1 -Version <version>
5. Prepare the release commit first when code or docs changed. Do not tag uncommitted work.
6. Create and push the release tag:
   • git tag v<version>
   • git push origin HEAD
   • git push origin v<version>
7. Monitor the GitHub Action until pack-and-publish succeeds:
   • use gh run list, gh run view, and gh run watch
   • stop and inspect logs if the workflow fails
8. Verify published outputs:
   • inspect the GitHub Release created for v<version>
   • confirm every expected .nupkg and .snupkg asset exists
   • query GitHub Packages versions when stronger confirmation is needed
9. Close the release with evidence:
   • version and tag
   • commit hash
   • workflow run URL or ID
   • GitHub Release URL
   • package IDs and assets verified

Guardrails

• Do not reuse or mutate an already published version tag.
• Stop if local build or pack fails; fix forward before tagging.
• Treat missing GitHub Release assets or missing package versions as a failed release until verified.
• If workflow or feed behavior changes, update docs and this skill in the same phase.

Reference

• Use references/release-checklist.md for command templates, expected package IDs, and verification snippets.