release

Create a new release of ctx-launcher. CI handles everything — this skill just tags and pushes.

Version numbers come from git tags via MinVer. Tagging vX.Y.Z triggers CI, which:

1. Builds native AOT binaries on Windows / Linux / macOS-arm64
2. Publishes all four npm packages (@ctx-launcher/wl, @ctx-launcher/wl-win-x64, -linux-x64, -darwin-arm64) with --tag=latest
3. Creates the GitHub release with binaries attached (auto-generated notes)

Prerequisites

Confirm working tree is clean and on master:

git status --porcelain && git rev-parse --abbrev-ref HEAD

Stop if dirty or not on master.

(No npm whoami check needed — publish runs in CI with the NPM_TOKEN repo secret.)

Step 1: Analyze and propose

1. Current version:

   git describe --tags --abbrev=0

2. Changes since:

   git log $(git describe --tags --abbrev=0)..HEAD --oneline

3. Categorize:
   • patch (0.1.0 → 0.1.1): bug fixes, formatting, docs
   • minor (0.1.0 → 0.2.0): new features, new commands, behavior changes
   • major (0.1.0 → 1.0.0): breaking CLI or workspace format changes
4. Present:

   Current version: <current>
   Changes since last release:
     - <commit>
     - <commit>
   
   Suggested version: <new>  (<patch/minor/major> — <reason>)
   
   Proceed?

Step 2: Changelog

Add a ## <version> — <yyyy-MM-dd> section at the top of CHANGELOG.md (Added / Fixed / Removed; for breaking changes an Upgrading before → after table). If the release changes commands, files, or workspace.json, update docs/reference.md in the same commit. Show the entry to the user, then commit and push it before tagging.

Step 3: Sanity check

Unit tests first (fast local safety net — CI runs the full matrix afterwards):

dotnet test tests/wl.tests/wl.tests.csproj --verbosity quiet

Stop if any fail.

Step 4: Tag and push

git tag v<version>
git push && git push origin v<version>

The tag push triggers CI. MinVer sees the tag and emits a clean <version> string into the binaries.

Step 5: Watch CI

gh run list --workflow CI --event push --limit 5

Find the run whose branch column shows v<version>. Watch:

gh run watch <run-id>

CI jobs, in order:

1. build-{win-x64,linux-x64,osx-arm64} (matrix) — unit + AOT publish + e2e
2. publish-{wl-win-x64,wl-linux-x64,wl-darwin-arm64} (matrix) — npm publish per-platform
3. publish-main — npm publish @ctx-launcher/wl
4. github-release — gh release create with binaries

Once all four are green: done. Everything is live. The GitHub release notes are auto-generated from commits; point users to CHANGELOG.md for the upgrade notes.

Rollback

If CI fails partway through:

• Before any publish-platform job succeeds: git push --delete origin v<version> + git tag -d v<version> removes the tag. Safe.
• Some platforms published, main not yet: unpublish within 72h (npm unpublish @ctx-launcher/wl-<platform>@<version>) and delete the tag. After 72h, bump to the next patch and re-release.
• Main published: fix-forward by bumping to the next patch. Don't unpublish; users may have installed.

Manual dev preview (no tag)

If you want a dev build on npm without cutting a release:

gh workflow run CI --ref master -f publish_dev=true

CI publishes the current master as <next-patch>-dev.<N>+<sha> with npm dist-tag dev. Users can install with:

npm install -g @ctx-launcher/wl@dev

The latest tag is untouched — regular npm install still gets the released version.