name	nam-release-workflow
description	Handle NAM-BOT release chores in this repository. Use when asked to update the changelog, decide the next version bump, clean generated build output or temporary logs, sync release-related docs, commit the release work, or push `main`.

Nam Release Workflow

Use this skill to turn the current thread's completed repo changes into a clean NAM-BOT release.

Release Rules

Treat requests like update changelog, patch update, release this, or commit and push as a release workflow request for this repo.
Default to a patch bump for docs, UX polish, copy, bug fixes, small workflow improvements, and project-maintenance changes.
Use a minor bump only when the repo gained a clearly new user-facing capability or a larger workflow surface.
Keep prerelease formatting consistent with the repo's current scheme, e.g. 0.0.5-alpha.
When promoting a tested release candidate to a stable release, consolidate the prerelease notes into the stable version section and remove the RC sections from the final public changelog unless the user explicitly wants prerelease entries preserved.
Treat pushing main and pushing a release tag as separate decisions.
Always mention the matching version tag when reporting or proposing a release push to main.
After pushing main, explicitly ask whether the user wants to push the matching v<version> tag now.
Never push a version tag unless the user explicitly asks for it or explicitly confirms it in that thread.
release.yml publishes the Windows and macOS release assets from v* tags.
preview-release.yml publishes rolling GitHub prerelease preview builds for pushes to main; those preview entries should not be treated as stable releases.
When a release resolves specific GitHub issues, close those associated issues after the relevant release steps are complete and leave a short shipped-in-version note.

Required Files

Update CHANGELOG.md.
Update package.json.
Update package-lock.json.
Check whether the About screen uses a hardcoded version string. If it does, update it; if it already reads the runtime app version dynamically, no About version edit is needed.
If AGENTS.md contains a version in the title or release-specific instructions, keep it in sync.

Workflow

Inspect git status, the latest commits, package.json, and the top of CHANGELOG.md.
Decide the next version bump from the work completed since the last versioned changelog entry.
Convert Unreleased notes into a dated versioned section for the new release.
If the release notes are missing the current thread's changes, add concise bullets before finalizing the versioned section.
Bump the version in package.json and package-lock.json.
Run npm run build to verify the release state before cleanup.
Remove generated junk that should not linger between sessions, such as out/, release/, loose temporary logs, and scratch temp folders created during the work.
Re-check git status so only intentional repo files remain.
Commit with a direct release-oriented message.
Push main. When reporting the push, explicitly mention whether the matching version tag has not been pushed yet, that pushing the tag is what triggers the public GitHub Windows and macOS release, and ask the user whether they want to push the tag now.
Only if the user explicitly asks for the full release tag push, create and push the matching v<version> tag.
Close any associated GitHub issues that the release actually resolves, with a short comment noting the shipped version and the fix scope.
Keep preview prerelease automation and stable tagged release automation distinct: preview builds may publish on main, but only v* tags should trigger the public Windows and macOS release flow.

Changelog Notes

Keep ## [Unreleased] at the top.
Put the new version directly under Unreleased.
Use the current local date in YYYY-MM-DD format.
Keep notes concise and grouped under Added, Changed, and Fixed when applicable.
Prefer shipping one coherent release entry rather than stacking many tiny Unreleased bullets across threads.
For stable releases that follow one or more RCs, prefer one coherent stable changelog section instead of public RC sections.

Cleanup Rules

Delete ignored build output only when it was generated by repo workflows and is safe to recreate.
Do not delete tracked files, user assets, or anything outside the repository.
Do not use destructive reset commands as a shortcut for cleanup.

Commit And Push

Stage only the intended release files.
Prefer non-interactive git commands.
If conflicts appear during rebase, resolve them carefully, keep newer upstream changes, reapply the local release intent, and continue non-interactively.

Nam Release Workflow

Use this skill to turn the current thread's completed repo changes into a clean NAM-BOT release.

Release Rules

Treat requests like update changelog, patch update, release this, or commit and push as a release workflow request for this repo.

Default to a patch bump for docs, UX polish, copy, bug fixes, small workflow improvements, and project-maintenance changes.

Use a minor bump only when the repo gained a clearly new user-facing capability or a larger workflow surface.

Keep prerelease formatting consistent with the repo's current scheme, e.g. 0.0.5-alpha.

When promoting a tested release candidate to a stable release, consolidate the prerelease notes into the stable version section and remove the RC sections from the final public changelog unless the user explicitly wants prerelease entries preserved.

Treat pushing main and pushing a release tag as separate decisions.

Always mention the matching version tag when reporting or proposing a release push to main.

After pushing main, explicitly ask whether the user wants to push the matching v<version> tag now.

Never push a version tag unless the user explicitly asks for it or explicitly confirms it in that thread.

release.yml publishes the Windows and macOS release assets from v* tags.

preview-release.yml publishes rolling GitHub prerelease preview builds for pushes to main; those preview entries should not be treated as stable releases.

When a release resolves specific GitHub issues, close those associated issues after the relevant release steps are complete and leave a short shipped-in-version note.

Required Files

Update CHANGELOG.md.

Update package.json.

Update package-lock.json.

Check whether the About screen uses a hardcoded version string. If it does, update it; if it already reads the runtime app version dynamically, no About version edit is needed.

If AGENTS.md contains a version in the title or release-specific instructions, keep it in sync.

Workflow

Inspect git status, the latest commits, package.json, and the top of CHANGELOG.md.

Decide the next version bump from the work completed since the last versioned changelog entry.

Convert Unreleased notes into a dated versioned section for the new release.

If the release notes are missing the current thread's changes, add concise bullets before finalizing the versioned section.

Bump the version in package.json and package-lock.json.

Run npm run build to verify the release state before cleanup.

Remove generated junk that should not linger between sessions, such as out/, release/, loose temporary logs, and scratch temp folders created during the work.

Re-check git status so only intentional repo files remain.

Commit with a direct release-oriented message.

Push main. When reporting the push, explicitly mention whether the matching version tag has not been pushed yet, that pushing the tag is what triggers the public GitHub Windows and macOS release, and ask the user whether they want to push the tag now.

Only if the user explicitly asks for the full release tag push, create and push the matching v<version> tag.

Close any associated GitHub issues that the release actually resolves, with a short comment noting the shipped version and the fix scope.

Keep preview prerelease automation and stable tagged release automation distinct: preview builds may publish on main, but only v* tags should trigger the public Windows and macOS release flow.

Changelog Notes

Keep ## [Unreleased] at the top.

Put the new version directly under Unreleased.

Use the current local date in YYYY-MM-DD format.

Keep notes concise and grouped under Added, Changed, and Fixed when applicable.

Prefer shipping one coherent release entry rather than stacking many tiny Unreleased bullets across threads.

For stable releases that follow one or more RCs, prefer one coherent stable changelog section instead of public RC sections.

Cleanup Rules

Delete ignored build output only when it was generated by repo workflows and is safe to recreate.

Do not delete tracked files, user assets, or anything outside the repository.

Do not use destructive reset commands as a shortcut for cleanup.

Commit And Push

Stage only the intended release files.

Prefer non-interactive git commands.

If conflicts appear during rebase, resolve them carefully, keep newer upstream changes, reapply the local release intent, and continue non-interactively.

nam-release-workflow