| name | create-release |
| description | Create a concise English release message from commits since the last vX.Y.Z tag, then bump every workspace package to the same version with pnpm changeset and pnpm changeset version. Use when the user asks to release, cut a release, bump versions, write a release message, or run changesets for this monorepo. |
Create Release
Keep all packages/* versions identical. Never bump only the packages touched by recent commits.
Workflow
Copy and track:
Release progress:
- [ ] 1. Find last release tag
- [ ] 2. Collect commits since that tag
- [ ] 3. Draft release message (30–100 English words, conventional prefix)
- [ ] 4. Choose bump type (major | minor | patch)
- [ ] 5. Create changeset covering ALL workspace packages
- [ ] 6. Run pnpm changeset version
- [ ] 7. Verify every package version matches
- [ ] 8. Commit version bump (only if user asked to commit)
1. Find last release tag
Use the latest semver vX.Y.Z tag (not by create date alone):
git tag --list "v*.*.*"
Sort by major → minor → patch descending. That tag is the release baseline.
2. Collect commits
git log <latest-tag>..HEAD --pretty=format:"%h %s"
Ignore pure release commits such as release: release X.Y.Z. Summarize the remaining user-facing changes.
3. Draft release message
Requirements:
- English only
- 30–100 words (aim ~40–80)
- Start with a conventional prefix:
feat:, fix:, perf:, refactor:, docs:, or chore:
- One short paragraph summarizing the release theme (not a bullet dump of every commit)
- Match existing CHANGELOG tone (see
packages/*/CHANGELOG.md)
Prefix choice:
- Dominant change is a new capability →
feat:
- Dominant change is a bug fix →
fix:
- Mixed with a clear feature theme → prefer
feat:
- Only tooling/docs →
chore: / docs:
Example style (from prior releases):
feat: speeds up drawing open with progressive loading by default, a direct-batch convert fast path, and smarter rendering-cache heuristics that share compacted INSERT template geometry. Fonts load on demand during text draw, and picking is fixed so hollow lines are not selected via bbox while hatch islands stay selectable
Show the draft to the user before applying the changeset unless they already approved the wording.
4. Choose bump type
Infer from commits since the last tag (ask if unclear):
| Commits indicate | Bump |
|---|
| Breaking API / incompatible change | major |
| New features, no breaking change | minor |
| Fixes / small improvements only | patch |
Apply the same bump type to every package.
5. Create changeset for ALL packages
Discover packages:
Include every named workspace package in the changeset frontmatter — public and private. Do not omit untouched packages.
Prefer writing the changeset file directly (agents often lack an interactive TTY for pnpm changeset):
- Create
.changeset/<short-slug>.md
- Frontmatter: each package name → chosen bump type
- Body: the approved release message (single paragraph)
---
"@mlightcad/cad-agent-plugin": patch
"@mlightcad/cad-html-plugin": patch
"@mlightcad/cad-pdf-plugin": patch
"@mlightcad/cad-simple-ui-plugin": patch
"@mlightcad/cad-simple-viewer": patch
"@mlightcad/cad-simple-viewer-cli": patch
"@mlightcad/cad-simple-viewer-example": patch
"@mlightcad/cad-svg-plugin": patch
"@mlightcad/cad-viewer": patch
"@mlightcad/cad-viewer-example": patch
"@mlightcad/cad-viewer-examples": patch
"@mlightcad/three-renderer": patch
---
feat: your 30–100 word release summary here
Refresh the package list from disk each release; do not hard-code a stale set if packages were added or removed.
If an interactive terminal is available, pnpm changeset is fine only when every package is selected. Skipping packages is a failure.
6. Version
pnpm changeset version
This consumes the changeset, bumps versions, and updates CHANGELOGs.
7. Verify lockstep versions
Confirm every packages/*/package.json "version" is identical. If any package lagged behind, fix before committing — do not ship divergent versions.
Optional sanity check after edits:
pnpm sync:versions:check
8. Commit / tag
- Commit only when the user asks. Suggested message:
release: release X.Y.Z (match prior commits).
- Creating/pushing the git tag is separate:
pnpm release (or pnpm release X.Y.Z). Do not run tag push unless the user asks.
Anti-patterns
- Bumping only “affected” packages
- Release notes as a raw commit list or over 100 words
- Missing conventional prefix on the release message
- Running
pnpm changeset version with an incomplete changeset
- Changing root
package.json version (root stays private/1.0.0; only packages/* release together)
