chore(release): add agent release workflow

.claude/commands/release.md

@@ -0,0 +1,15 @@
+---
+description: Prepare or publish an Agent Note release with the repo-local Markdown workflow.
+argument-hint: <version> [--push|--dry-run]
+---
+
+# Agent Note Release
+
+Use the repo-local `agentnote-release` skill.
+
+1. Use the provided version argument, accepting `x.y.z` or `vx.y.z`.
+2. For an actual release, switch to `main`, pull, and ensure unrelated dirty files are not present.
+3. Normalize the version: package metadata uses `x.y.z`; the git tag is always `vx.y.z`.
+4. Follow the skill's manual release steps: update package metadata, rebuild, run checks, preview with `git-cliff --config .github/cliff.toml --unreleased --tag vx.y.z --strip header`, commit, tag, and push only when publishing.
+5. Verify the release workflow, GitHub Release, and both npm packages after pushing.
+6. Report the commands run and final release status.

.claude/skills/agentnote-release/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: agentnote-release
+description: Prepare and publish Agent Note releases with the repo-local Markdown workflow, including version bump validation, release note preview, tag creation, workflow monitoring, and npm/GitHub verification.
+---
+
+# Agent Note Release Workflow
+
+Use this skill when the task asks to release Agent Note, bump a version, cut a tag, publish npm packages, or verify a release.
+
+## Prepare
+
+1. Confirm the target version from the user request, accepting either `x.y.z` or `vx.y.z`. Use `x.y.z` for package metadata and `vx.y.z` for the git tag.
+2. Switch to `main` and pull the latest changes before an actual release.
+3. Check the working tree. Do not release with unrelated dirty files.
+4. If the user only wants a rehearsal or passes `--dry-run`, do not edit files, commit, tag, or push; only inspect state, run safe checks when useful, and preview the release notes.
+
+## Release
+
+Follow these steps instead of relying on a release script:
+
+1. Update `packages/cli/package.json` to `x.y.z`.
+2. Run `npm install` from the repository root so npm updates `package-lock.json` and synchronizes `packages["packages/cli"].version` to `x.y.z`.
+3. Run `npm -w packages/cli run build`.
+4. Run `npm -w packages/cli run typecheck`.
+5. Run `npm -w packages/cli run lint`.
+6. Run `npm -w packages/cli test`.
+7. Preview release notes with `git-cliff --config .github/cliff.toml --unreleased --tag vx.y.z --strip header`.
+8. Stage `packages/cli/package.json`, `package-lock.json`, and the rebuilt `packages/cli/dist/cli.js`.
+9. Commit only those release files as `chore: bump version to x.y.z` with `Release note: skip`.
+10. Create the annotated tag with `git tag -a vx.y.z -m vx.y.z`.
+11. Push `main` and `vx.y.z` only when ready to publish.
+
+## Guardrails
+
+- Do not manually push a release tag before the package version bump commit is on `main`.
+- If release notes look like an implementation log, fix commit subjects or `Release note:` bodies before tagging.
+- If any step fails after a local commit or tag, inspect the repository state before retrying; do not create duplicate tags.
+- Keep release plumbing commits hidden with `Release note: skip`.
+
+## Verify
+
+After pushing a release tag:
+
+1. Watch the release workflow until completion.
+2. Verify the GitHub Release exists for `v<version>`.
+3. Verify npm publishes both `agent-note@<version>` and `@wasabeef/agentnote@<version>`.
+4. If release notes need copy edits after publication, update the GitHub Release body directly and keep the source commit guidance for future releases.
+
+## Report
+
+End with:
+
+- Version released or prepared
+- Commands run
+- Workflow status
+- GitHub Release URL
+- npm package versions confirmed

.codex/commands/release.md

@@ -0,0 +1,15 @@
+---
+description: Prepare or publish an Agent Note release with the repo-local Markdown workflow.
+argument-hint: <version> [--push|--dry-run]
+---
+
+# Agent Note Release
+
+Use the repo-local `agentnote-release` skill.
+
+1. Use the provided version argument, accepting `x.y.z` or `vx.y.z`.
+2. For an actual release, switch to `main`, pull, and ensure unrelated dirty files are not present.
+3. Normalize the version: package metadata uses `x.y.z`; the git tag is always `vx.y.z`.
+4. Follow the skill's manual release steps: update package metadata, rebuild, run checks, preview with `git-cliff --config .github/cliff.toml --unreleased --tag vx.y.z --strip header`, commit, tag, and push only when publishing.
+5. Verify the release workflow, GitHub Release, and both npm packages after pushing.
+6. Report the commands run and final release status.

.codex/skills/agentnote-release/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: agentnote-release
+description: Prepare and publish Agent Note releases with the repo-local Markdown workflow, including version bump validation, release note preview, tag creation, workflow monitoring, and npm/GitHub verification.
+---
+
+# Agent Note Release Workflow
+
+Use this skill when the task asks to release Agent Note, bump a version, cut a tag, publish npm packages, or verify a release.
+
+## Prepare
+
+1. Confirm the target version from the user request, accepting either `x.y.z` or `vx.y.z`. Use `x.y.z` for package metadata and `vx.y.z` for the git tag.
+2. Switch to `main` and pull the latest changes before an actual release.
+3. Check the working tree. Do not release with unrelated dirty files.
+4. If the user only wants a rehearsal or passes `--dry-run`, do not edit files, commit, tag, or push; only inspect state, run safe checks when useful, and preview the release notes.
+
+## Release
+
+Follow these steps instead of relying on a release script:
+
+1. Update `packages/cli/package.json` to `x.y.z`.
+2. Run `npm install` from the repository root so npm updates `package-lock.json` and synchronizes `packages["packages/cli"].version` to `x.y.z`.
+3. Run `npm -w packages/cli run build`.
+4. Run `npm -w packages/cli run typecheck`.
+5. Run `npm -w packages/cli run lint`.
+6. Run `npm -w packages/cli test`.
+7. Preview release notes with `git-cliff --config .github/cliff.toml --unreleased --tag vx.y.z --strip header`.
+8. Stage `packages/cli/package.json`, `package-lock.json`, and the rebuilt `packages/cli/dist/cli.js`.
+9. Commit only those release files as `chore: bump version to x.y.z` with `Release note: skip`.
+10. Create the annotated tag with `git tag -a vx.y.z -m vx.y.z`.
+11. Push `main` and `vx.y.z` only when ready to publish.
+
+## Guardrails
+
+- Do not manually push a release tag before the package version bump commit is on `main`.
+- If release notes look like an implementation log, fix commit subjects or `Release note:` bodies before tagging.
+- If any step fails after a local commit or tag, inspect the repository state before retrying; do not create duplicate tags.
+- Keep release plumbing commits hidden with `Release note: skip`.
+
+## Verify
+
+After pushing a release tag:
+
+1. Watch the release workflow until completion.
+2. Verify the GitHub Release exists for `v<version>`.
+3. Verify npm publishes both `agent-note@<version>` and `@wasabeef/agentnote@<version>`.
+4. If release notes need copy edits after publication, update the GitHub Release body directly and keep the source commit guidance for future releases.
+
+## Report
+
+End with:
+
+- Version released or prepared
+- Commands run
+- Workflow status
+- GitHub Release URL
+- npm package versions confirmed

.cursor/commands/release.md

@@ -0,0 +1,15 @@
+---
+description: Prepare or publish an Agent Note release with the repo-local Markdown workflow.
+argument-hint: <version> [--push|--dry-run]
+---
+
+# Agent Note Release
+
+Use the repo-local `agentnote-release` skill.
+
+1. Use the provided version argument, accepting `x.y.z` or `vx.y.z`.
+2. For an actual release, switch to `main`, pull, and ensure unrelated dirty files are not present.
+3. Normalize the version: package metadata uses `x.y.z`; the git tag is always `vx.y.z`.
+4. Follow the skill's manual release steps: update package metadata, rebuild, run checks, preview with `git-cliff --config .github/cliff.toml --unreleased --tag vx.y.z --strip header`, commit, tag, and push only when publishing.
+5. Verify the release workflow, GitHub Release, and both npm packages after pushing.
+6. Report the commands run and final release status.

.cursor/skills/agentnote-release/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: agentnote-release
+description: Prepare and publish Agent Note releases with the repo-local Markdown workflow, including version bump validation, release note preview, tag creation, workflow monitoring, and npm/GitHub verification.
+---
+
+# Agent Note Release Workflow
+
+Use this skill when the task asks to release Agent Note, bump a version, cut a tag, publish npm packages, or verify a release.
+
+## Prepare
+
+1. Confirm the target version from the user request, accepting either `x.y.z` or `vx.y.z`. Use `x.y.z` for package metadata and `vx.y.z` for the git tag.
+2. Switch to `main` and pull the latest changes before an actual release.
+3. Check the working tree. Do not release with unrelated dirty files.
+4. If the user only wants a rehearsal or passes `--dry-run`, do not edit files, commit, tag, or push; only inspect state, run safe checks when useful, and preview the release notes.
+
+## Release
+
+Follow these steps instead of relying on a release script:
+
+1. Update `packages/cli/package.json` to `x.y.z`.
+2. Run `npm install` from the repository root so npm updates `package-lock.json` and synchronizes `packages["packages/cli"].version` to `x.y.z`.
+3. Run `npm -w packages/cli run build`.
+4. Run `npm -w packages/cli run typecheck`.
+5. Run `npm -w packages/cli run lint`.
+6. Run `npm -w packages/cli test`.
+7. Preview release notes with `git-cliff --config .github/cliff.toml --unreleased --tag vx.y.z --strip header`.
+8. Stage `packages/cli/package.json`, `package-lock.json`, and the rebuilt `packages/cli/dist/cli.js`.
+9. Commit only those release files as `chore: bump version to x.y.z` with `Release note: skip`.
+10. Create the annotated tag with `git tag -a vx.y.z -m vx.y.z`.
+11. Push `main` and `vx.y.z` only when ready to publish.
+
+## Guardrails
+
+- Do not manually push a release tag before the package version bump commit is on `main`.
+- If release notes look like an implementation log, fix commit subjects or `Release note:` bodies before tagging.
+- If any step fails after a local commit or tag, inspect the repository state before retrying; do not create duplicate tags.
+- Keep release plumbing commits hidden with `Release note: skip`.
+
+## Verify
+
+After pushing a release tag:
+
+1. Watch the release workflow until completion.
+2. Verify the GitHub Release exists for `v<version>`.
+3. Verify npm publishes both `agent-note@<version>` and `@wasabeef/agentnote@<version>`.
+4. If release notes need copy edits after publication, update the GitHub Release body directly and keep the source commit guidance for future releases.
+
+## Report
+
+End with:
+
+- Version released or prepared
+- Commands run
+- Workflow status
+- GitHub Release URL
+- npm package versions confirmed

.gemini/commands/release.md

@@ -0,0 +1,15 @@
+---
+description: Prepare or publish an Agent Note release with the repo-local Markdown workflow.
+argument-hint: <version> [--push|--dry-run]
+---
+
+# Agent Note Release
+
+Use the repo-local `agentnote-release` skill.
+
+1. Use the provided version argument, accepting `x.y.z` or `vx.y.z`.
+2. For an actual release, switch to `main`, pull, and ensure unrelated dirty files are not present.
+3. Normalize the version: package metadata uses `x.y.z`; the git tag is always `vx.y.z`.
+4. Follow the skill's manual release steps: update package metadata, rebuild, run checks, preview with `git-cliff --config .github/cliff.toml --unreleased --tag vx.y.z --strip header`, commit, tag, and push only when publishing.
+5. Verify the release workflow, GitHub Release, and both npm packages after pushing.
+6. Report the commands run and final release status.

.gemini/skills/agentnote-release/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: agentnote-release
+description: Prepare and publish Agent Note releases with the repo-local Markdown workflow, including version bump validation, release note preview, tag creation, workflow monitoring, and npm/GitHub verification.
+---
+
+# Agent Note Release Workflow
+
+Use this skill when the task asks to release Agent Note, bump a version, cut a tag, publish npm packages, or verify a release.
+
+## Prepare
+
+1. Confirm the target version from the user request, accepting either `x.y.z` or `vx.y.z`. Use `x.y.z` for package metadata and `vx.y.z` for the git tag.
+2. Switch to `main` and pull the latest changes before an actual release.
+3. Check the working tree. Do not release with unrelated dirty files.
+4. If the user only wants a rehearsal or passes `--dry-run`, do not edit files, commit, tag, or push; only inspect state, run safe checks when useful, and preview the release notes.
+
+## Release
+
+Follow these steps instead of relying on a release script:
+
+1. Update `packages/cli/package.json` to `x.y.z`.
+2. Run `npm install` from the repository root so npm updates `package-lock.json` and synchronizes `packages["packages/cli"].version` to `x.y.z`.
+3. Run `npm -w packages/cli run build`.
+4. Run `npm -w packages/cli run typecheck`.
+5. Run `npm -w packages/cli run lint`.
+6. Run `npm -w packages/cli test`.
+7. Preview release notes with `git-cliff --config .github/cliff.toml --unreleased --tag vx.y.z --strip header`.
+8. Stage `packages/cli/package.json`, `package-lock.json`, and the rebuilt `packages/cli/dist/cli.js`.
+9. Commit only those release files as `chore: bump version to x.y.z` with `Release note: skip`.
+10. Create the annotated tag with `git tag -a vx.y.z -m vx.y.z`.
+11. Push `main` and `vx.y.z` only when ready to publish.
+
+## Guardrails
+
+- Do not manually push a release tag before the package version bump commit is on `main`.
+- If release notes look like an implementation log, fix commit subjects or `Release note:` bodies before tagging.
+- If any step fails after a local commit or tag, inspect the repository state before retrying; do not create duplicate tags.
+- Keep release plumbing commits hidden with `Release note: skip`.
+
+## Verify
+
+After pushing a release tag:
+
+1. Watch the release workflow until completion.
+2. Verify the GitHub Release exists for `v<version>`.
+3. Verify npm publishes both `agent-note@<version>` and `@wasabeef/agentnote@<version>`.
+4. If release notes need copy edits after publication, update the GitHub Release body directly and keep the source commit guidance for future releases.
+
+## Report
+
+End with:
+
+- Version released or prepared
+- Commands run
+- Workflow status
+- GitHub Release URL
+- npm package versions confirmed

AGENTS.md

@@ -145,15 +145,15 @@ Each `UserPromptSubmit` increments a turn counter. File changes inherit the curr
 - **Keep release notes human-sized.** A multi-commit PR should normally produce one clear release bullet per user-visible change, not one bullet per review fix. Put the public wording on the primary implementation commit with `Release note: <sentence>`, and add `Release note: skip` to follow-up commits such as `address review findings`, `tighten fallback`, `bound window`, or generated bundle syncs unless they describe a distinct user-visible outcome.
 - **Write release notes as natural English sentences.** The generator capitalizes the first character as a safety net, but do not rely on that to fix awkward wording. Prefer `Release note: Codex commits made from cmux sessions are now recorded reliably.` over `Release note: recover codex env sessions`.
 - **PR titles should be release-summary quality.** Write PR titles as a user-facing outcome, not an implementation step. Even though GitHub Releases are generated from commits, a good PR title is the easiest review-time signal that the eventual release note will be understandable.
-- **Preview release notes before merging release-sensitive PRs.** If `git-cliff --config .github/cliff.toml --latest --strip header` reads like an implementation log, rewrite commit subjects/bodies before merge or tag. Do not leave low-level cleanup commits visible just because tests pass.
+- **Preview release notes before merging release-sensitive PRs.** If `git-cliff --config .github/cliff.toml --latest --strip header` reads like an implementation log, rewrite commit subjects/bodies before merge. Before tagging, use the release command below so the preview targets the next version.
 - **Do not rely on merge commits for release copy.** Release notes include merged PR links from `Merge pull request...` commits, but the user-facing bullets still come from implementation commits and `Release note:` lines. Version bumps and generated bundle sync commits stay hidden.
 - **Structural vs behavioral changes** must not be mixed in a single commit. Renames/reformats separate from feature/fix commits.
 - **Before committing**, all four checks must pass (run from `packages/cli/`):
   1. `npm run build` — esbuild bundle
   2. `npm run typecheck` — tsc --noEmit
   3. `npm run lint` — biome check
   4. `npm test` — node:test (requires build first)
-- **Version bumps** go in a dedicated `chore: bump version to x.y.z` commit. Tag `vx.y.z` triggers the release workflow (test → GitHub Release → npm publish).
+- **Version bumps** go in a dedicated `chore: bump version to x.y.z` commit. Prefer the repo-local `agentnote-release` skill or `/release` command; `x.y.z` and `vx.y.z` inputs both create the `vx.y.z` tag. Push the tag only when ready to trigger the release workflow (test → GitHub Release → npm publish).
 
 ## Constraints
 

CLAUDE.md

@@ -145,15 +145,15 @@ Each `UserPromptSubmit` increments a turn counter. File changes inherit the curr
 - **Keep release notes human-sized.** A multi-commit PR should normally produce one clear release bullet per user-visible change, not one bullet per review fix. Put the public wording on the primary implementation commit with `Release note: <sentence>`, and add `Release note: skip` to follow-up commits such as `address review findings`, `tighten fallback`, `bound window`, or generated bundle syncs unless they describe a distinct user-visible outcome.
 - **Write release notes as natural English sentences.** The generator capitalizes the first character as a safety net, but do not rely on that to fix awkward wording. Prefer `Release note: Codex commits made from cmux sessions are now recorded reliably.` over `Release note: recover codex env sessions`.
 - **PR titles should be release-summary quality.** Write PR titles as a user-facing outcome, not an implementation step. Even though GitHub Releases are generated from commits, a good PR title is the easiest review-time signal that the eventual release note will be understandable.
-- **Preview release notes before merging release-sensitive PRs.** If `git-cliff --config .github/cliff.toml --latest --strip header` reads like an implementation log, rewrite commit subjects/bodies before merge or tag. Do not leave low-level cleanup commits visible just because tests pass.
+- **Preview release notes before merging release-sensitive PRs.** If `git-cliff --config .github/cliff.toml --latest --strip header` reads like an implementation log, rewrite commit subjects/bodies before merge. Before tagging, use the release command below so the preview targets the next version.
 - **Do not rely on merge commits for release copy.** Release notes include merged PR links from `Merge pull request...` commits, but the user-facing bullets still come from implementation commits and `Release note:` lines. Version bumps and generated bundle sync commits stay hidden.
 - **Structural vs behavioral changes** must not be mixed in a single commit. Renames/reformats separate from feature/fix commits.
 - **Before committing**, all four checks must pass (run from `packages/cli/`):
   1. `npm run build` — esbuild bundle
   2. `npm run typecheck` — tsc --noEmit
   3. `npm run lint` — biome check
   4. `npm test` — node:test (requires build first)
-- **Version bumps** go in a dedicated `chore: bump version to x.y.z` commit. Tag `vx.y.z` triggers the release workflow (test → GitHub Release → npm publish).
+- **Version bumps** go in a dedicated `chore: bump version to x.y.z` commit. Prefer the repo-local `agentnote-release` skill or `/release` command; `x.y.z` and `vx.y.z` inputs both create the `vx.y.z` tag. Push the tag only when ready to trigger the release workflow (test → GitHub Release → npm publish).
 
 ## Constraints