| name | release |
| description | Release a new version of a package (cli, desktop) |
| triggers | ["release","publish","ship"] |
| user_invocable | true |
Create a release for a package in this monorepo.
/release <package> [version]
Examples:
/release cli โ release the CLI (prompts for version)/release cli 1.0.3 โ release CLI v1.0.3| Package | Tag format | Script |
|---|---|---|
| cli | cli-v{version} | cli/scripts/release.sh |
| desktop | desktop-v{version} | desktop/scripts/release.sh |
Parse the package name and optional version from the arguments. If no version
is given, read the current version from the package's package.json and ask
the user what the new version should be.
git status --porcelain should be empty
inside the package directory)mainpnpm buildpnpm testIf any check fails, stop and explain what needs to be fixed.
Find the previous release tag:
git tag --list '<package>-v*' --sort=-version:refname | head -1
Review all changes since that tag, scoped to the package directory:
git log <prev-tag>..HEAD --oneline -- <package-dir>/
git diff <prev-tag>..HEAD -- <package-dir>/
Write <package-dir>/RELEASE_NOTES.md with a concise, human-friendly summary
of what changed. Focus on user-facing changes. Use this format:
Summary sentence of the release.
<section>:
- Change description
Group changes into sections like Features, Fixes, Improvements as appropriate. Skip sections with no entries. Don't list every commit โ synthesise related changes into clear bullet points.
Show the draft to the user and ask for approval before proceeding.
bash <package-dir>/scripts/release.sh <version>
The script handles: version bump in source files, git commit, tag, and push.
GitHub Actions will build and publish the release using the committed
RELEASE_NOTES.md.
Print the release URL: https://github.com/whoami-wiki/whoami/releases/tag/<tag>