| name | release |
| description | End-to-end release workflow — draft notes, run checks, push, watch CI, publish GitHub release, and update download links. Minimal user interaction required. |
| disable-model-invocation | true |
End-to-end release workflow. The goal is to minimize back-and-forth with the user: gather info, present a single approval prompt, then execute everything autonomously (push, watch CI, fix failures, publish release, update links).
1. Find the latest version
Run git tag -l 'v*' --sort=-v:refname to list all version tags sorted by semver descending. The first line is the latest version.
2. Read changes since that tag
Run these commands to understand what changed:
git log <latest-tag>..HEAD --oneline
git diff <latest-tag>..HEAD --stat
Read the actual diffs for key files if the summary isn't clear enough to write good release notes.
3. Run checks
Before proceeding, run typechecks and tests in both projects. Run these commands in parallel:
cd projects/electron && npm run typecheck && npm run test
cd projects/web && npm run typecheck && npm run test
If biome makes any formatting fixes during typecheck, note those files — they must be included in the release commit.
If any check fails, stop and report the failures to the user. Do NOT continue with the release until all checks pass.
4. Suggest a version number
The project follows semver. Most releases bump the minor version (e.g., 0.51.0 → 0.52.0). Suggest a patch bump only for pure bugfix releases.
5. Draft the release notes entry
Read to see the existing format. Draft a new entry to prepend to the array:
