メニュー
Create and publish releases for the Optique project. Use when releasing a new version, creating a patch release, or creating a major/minor release. Handles CHANGES.md updates, version bumping, tagging, and branch management.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Help a maintainer adopt and operate Sacho, the opinionated changelog manager that keeps user-facing release notes as one small Markdown fragment per change under changes.d/ and compiles them into CHANGES.md at release time. Use this skill whenever a repository has a sacho.toml, a changes.d/ directory, or a CHANGES.md built from fragments; whenever the user wants to add Sacho to a project, write or edit a changelog entry for a change they just made, cut a release, publish release notes, or wire `sacho check` into CI or a pre-commit hook; whenever forward-porting a bugfix release across maintenance branches or resolving a changelog merge conflict; and whenever `sacho check` or the changelog merge driver reports a problem. Also use it any time the user mentions Sacho, changes.d fragments, or asks how to write a changelog entry for users instead of generating one from commit messages.
Make a commit in Git with an appropriate commit message for the currently staged changes.
Use this skill when writing any code that builds a command-line interface with Optique in TypeScript or JavaScript. Covers the combinatorial parser model, choosing @optique/core vs @optique/run, value parsers, structured messages, optional()/withDefault()/multiple(), subcommands with command() and or(), shell completion, async parsing, the integration packages, and common mistakes to avoid. Trigger whenever the user is parsing command-line arguments, building a CLI, or adding options or subcommands to a tool.
Expert-level JavaScript testing skill focused on writing high-quality tests that find bugs, serve as documentation, and prevent regressions. Advocates for property-based testing with fast-check and protects against indeterministic code in tests. Does not cover black-box e2e testing.
| name | release |
| description | Create and publish releases for the Optique project. Use when releasing a new version, creating a patch release, or creating a major/minor release. Handles CHANGES.md updates, version bumping, tagging, and branch management. |
| metadata | {"internal":true} |
This skill automates the release process for the Optique project. There are two types of releases: patch releases and major/minor releases.
Before starting any release:
Verify the remote repository name:
git remote -v
Use the correct remote name (usually origin or upstream) in all push
commands.
Ensure you're on the correct branch and it's up to date.
Run tests to ensure everything passes:
mise test
mise check
Patch releases (e.g., 1.2.3) are for bug fixes and small improvements.
They are created from X.Y-maintenance branches.
Check out the maintenance branch:
git checkout 1.2-maintenance
git pull
Update CHANGES.md: Find the section for the version being released and change “To be released.” to “Released on {Month} {Day}, {Year}.” using the current date in English. For example:
Version 1.2.3
-------------
Released on January 5, 2026.
Commit the changes:
git add CHANGES.md
git commit -m "Release 1.2.3"
Create the tag (without v prefix). Always use -m to provide a tag
message to avoid opening an editor for GPG-signed tags:
git tag -m "Optique 1.2.3" 1.2.3
Add a new section at the top of CHANGES.md for the next patch version:
Version 1.2.4
-------------
To be released.
Version 1.2.3
-------------
Released on January 5, 2026.
Bump the version in packages/core/deno.json:
Change "version": "1.2.3" to "version": "1.2.4".
Run the version sync script:
mise check-versions --fix
Commit the version bump:
git add -A
git commit -m "Version bump
[ci skip]"
Push the tag and branch to the remote:
git push origin 1.2.3 1.2-maintenance
After creating a patch release, you must merge it forward to newer maintenance
branches and eventually to main.
Check if a newer maintenance branch exists (e.g., 1.3-maintenance):
git branch -a | grep maintenance
If a newer maintenance branch exists:
Check out the newer branch and merge the tag:
git checkout 1.3-maintenance
git merge 1.2.3
Resolve any conflicts (commonly in CHANGES.md, deno.json, and package.json files).
Copy changelog entries: After resolving conflicts, copy the changelog entries from the merged tag's version into the current branch's unreleased version section. The entries should be:
### @optique/core, ### @optique/run)[#123]: ...) should not
be duplicated if they already existFor example, if merging 1.2.3 into 1.3-maintenance where 1.3.2 is pending:
Before (1.3-maintenance):
Version 1.3.2
-------------
To be released.
### @optique/run
- Added new logging features. [[#125]]
[#125]: https://github.com/dahlia/optique/issues/125
Merged tag 1.2.3 contains:
Version 1.2.3
-------------
Released on January 6, 2026.
### @optique/run
- Fixed a crash on startup. [[#123]]
[#123]: https://github.com/dahlia/optique/issues/123
After (1.3-maintenance):
Version 1.3.2
-------------
To be released.
### @optique/run
- Fixed a crash on startup. [[#123]]
- Added new logging features. [[#125]]
[#123]: https://github.com/dahlia/optique/issues/123
[#125]: https://github.com/dahlia/optique/issues/125
Run tests to verify:
mise test
mise check
Complete the merge commit (use default message).
Create a new patch release for this branch by repeating Steps 1-3 for version 1.3.x (e.g., 1.3.1).
Continue cascading to even newer maintenance branches if they exist.
If no newer maintenance branch exists, merge to main:
git checkout main
git merge 1.2.3 # or the last tag you created (e.g., 1.3.1)
Resolve conflicts, run tests, and push:
mise test
mise check
git push origin main
[!IMPORTANT] Do not copy changelog entries to
main. Themainbranch tracks the next major/minor release, so patch release entries should not be duplicated there. Just resolve conflicts and keep the existing unreleased section as-is.
Major/minor releases (e.g., 1.3.0, 2.0.0) introduce new features or breaking
changes. They are always created from the main branch with patch version 0.
Check out and update main:
git checkout main
git pull
Update CHANGES.md: Find the section for the version being released and change “To be released.” to “Released on {Month} {Day}, {Year}.” using the current date in English. For example:
Version 1.3.0
-------------
Released on January 5, 2026.
Commit the changes:
git add CHANGES.md
git commit -m "Release 1.3.0"
Create the tag (without v prefix). Always use -m to provide a tag
message to avoid opening an editor for GPG-signed tags:
git tag -m "Optique 1.3.0" 1.3.0
Add a new section at the top of CHANGES.md for the next minor version:
Version 1.4.0
-------------
To be released.
Version 1.3.0
-------------
Released on January 5, 2026.
Bump the version in packages/core/deno.json:
Change "version": "1.3.0" to "version": "1.4.0".
Run the version sync script:
mise check-versions --fix
Commit the version bump:
git add -A
git commit -m "Version bump
[ci skip]"
git push origin 1.3.0 main
Create the maintenance branch from the release tag:
git branch 1.3-maintenance 1.3.0
Check out the maintenance branch:
git checkout 1.3-maintenance
Add a section for the first patch version in CHANGES.md:
Version 1.3.1
-------------
To be released.
Version 1.3.0
-------------
Released on January 5, 2026.
Bump the version in packages/core/deno.json:
Change "version": "1.3.0" to "version": "1.3.1".
Run the version sync script:
mise check-versions --fix
Commit the version bump:
git add -A
git commit -m "Version bump
[ci skip]"
Push the maintenance branch:
git push origin 1.3-maintenance
X.Y.Z where Z > 0 (e.g., 1.2.3, 1.2.4)X.Y.0 (e.g., 1.3.0, 1.4.0)X.0.0 (e.g., 2.0.0, 3.0.0)X.Y-maintenance (e.g., 1.2-maintenance)v prefix (e.g., 1.2.3, not v1.2.3)Optique X.Y.Z format (use -m flag to avoid editor)Each version section follows this format:
Version X.Y.Z
-------------
Released on {Month} {Day}, {Year}.
### @optique/core
- Change description. [[#123]]
### @optique/run
- Change description.
[#123]: https://github.com/dahlia/optique/issues/123
For unreleased versions:
Version X.Y.Z
-------------
To be released.
X.Y-maintenance branchX.Y.Z with -m "Optique X.Y.Z"mise check-versions --fixVersion bump\n\n[ci skip]main (if no newer maintenance branches)main branchX.Y.0 with -m "Optique X.Y.0"mise check-versions --fixVersion bump\n\n[ci skip]main branchX.Y-maintenance branch from tagmise check-versions --fixVersion bump\n\n[ci skip]