create-release

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:

# Every packages/*/package.json that has a "name" field

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):

1. Create .changeset/<short-slug>.md
2. Frontmatter: each package name → chosen bump type
3. 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)