| name | changesets |
| description | Use when preparing a PR — adding a changeset, choosing bump types, empty changesets, API-contract changes, or understanding the version/release flow. |
Changesets (versioning + changelogs)
Every PR to dev must include a changeset describing the change, OR an empty changeset
if the PR cannot ship behavior. The changeset-check CI job in tests.yaml blocks merges
otherwise. Path-filter auto-skips PRs that touch only **/*.md, .github/**, or
.changeset/config.json.
How to add a changeset
Run from the repo root:
pnpm changeset
The CLI asks you to:
- Select the package(s) the PR affects (space to toggle, enter to confirm). Pick every
package you modified; never bundle unrelated packages into one changeset.
- Choose the bump type per package:
patch (bugfix / internal change), minor (new
feature, backwards-compatible), major (breaking change). For 0.x packages, treat
minor as "anything new" and major as "breaking" (semver is loose pre-1.0).
- Write a one-line summary. This appears verbatim in
CHANGELOG.md and gets auto-linked
to the PR, commit, and author. Write it for someone reading the changelog six months
from now; focus on the user-visible behavior, not implementation detail.
Commit the generated .changeset/<random>.md file alongside your code changes.
When to use an empty changeset
For PRs that genuinely cannot affect a package's behavior (CI tweaks not caught by the
path filter, comment-only edits, etc.):
pnpm changeset --empty
