Use when deciding patch vs minor releases and writing changelog/changeset entries for packages/core.
Contributor tooling for release notes and versioning decisions.
Use this skill when:
packages/core version.packages/core/CHANGELOG.md entries.This skill is for release communication and semver hygiene, not runtime implementation.
Write changelog entries in terms users care about:
Do not highlight internal-only refactors, file moves, test relocation, or module decomposition unless they directly change user-visible behavior.
When describing architecture-oriented cleanup that affected structure but not behavior, keep changelog phrasing outcome-oriented and user-facing.
Preferred contributor reminder:
Use this as implementation guidance during coding, but keep release notes focused on external impact.
x.y.Z): Bug fixes, docs-only clarifications, or non-breaking corrections with no meaningful feature expansion.x.Y.z): Backward-compatible feature additions, notable behavior improvements, new user-facing options, improved report fields, or meaningful cross-surface parity improvements.For core releases, update all of:
packages/core/package.json versionpackages/core/CHANGELOG.md with a new top sectionIf release impacts public behavior across surfaces, verify docs are aligned in:
packages/docs/content/api-sdk.mdpackages/docs/content/cli.mdpackages/docs/content/getting-started.mdpackages/docs/content/integrations.mdpackages/docs/content/policy-and-safety.mdpackages/docs/content/changelog.mdREADME.mdpackages/core/llms.txtllms.txtbarrel, file split, module move) unless it changed external behavior.pnpm --dir packages/core typecheckpnpm --dir packages/core test