Laive Release

node ./scripts/release.mjs prepare <patch|minor|major> --json

6. Run release checks before applying:

node ./scripts/release.mjs check

7. When the user explicitly wants release prep applied:

node ./scripts/release.mjs prepare <patch|minor|major> --apply

8. After prep, summarize:
   • next version
   • changelog entries included
   • commands run
   • any remaining manual steps

Publish

Only publish when the user explicitly asks.

Manual publish sequence:

git add CHANGELOG.md package.json packages/*/package.json
git commit -m "chore(release): vX.Y.Z"
git tag vX.Y.Z
npm publish --access public

After npm publish and tag push, create or update the GitHub release for the same version. Use the matching CHANGELOG.md section as the release body.

Example flow:

gh release view vX.Y.Z || gh release create vX.Y.Z --title "vX.Y.Z" --notes-file /tmp/laive-vX.Y.Z-release-notes.md

If the release already exists, use:

gh release edit vX.Y.Z --title "vX.Y.Z" --notes-file /tmp/laive-vX.Y.Z-release-notes.md

Required Notes

• Default to dry-run behavior unless the user explicitly asks to apply or publish.
• Do not skip CHANGELOG.md.
• Keep the changelog grouped by Features / Fixes / Maintenance for both ## Unreleased and versioned sections.
• Keep changelog bullets terse and commit-referenced.
• If install steps or support posture changed, update the relevant docs in the same change.
• When a release is published, do not stop after npm. Confirm the matching GitHub release exists and is populated from the changelog.