Record what consumers need to know after implementation and focused validation.
Workflow
- Inspect the complete diff and identify directly affected published packages.
- Classify impact across source types, runtime behavior, entrypoints, required
services, lifecycle, and persisted or wire data.
- Perform the breaking audit below.
- Record either a reason no changeset is required or one coherent changeset.
When required, read authoring.md.
- Validate package names, frontmatter, bump policy, and consumer-facing text.
Do not include unrelated worktree changes.
Requirement
Create a changeset for observable runtime behavior changes, including bug
fixes; exported value or public type changes; entrypoint or export-map changes;
changes to required services, errors, ownership, defaults, or lifecycle; and
persisted, serialization, protocol, or wire-format changes.
Tests-only changes, behavior-preserving internal refactors, documentation or
JSDoc maintenance, and unpublished tooling normally do not need one. When
unclear, inspect exports and consumer-visible declarations rather than inferring
from source location.
Breaking Audit
A change is breaking when valid existing consumer code, configuration, or data
must change to keep compiling or behaving according to the previous contract.
Audit every surface:
- Names and locations: exports, entrypoints, compatibility exports, and
module paths.
- Call compatibility: parameters, accepted inputs, overload resolution,
generic parameters, and defaults.
- Result compatibility: return and error types, output narrowing, members,
inference, and required services.
- Runtime contracts: defaults, failures, interruption, concurrency,
ordering, resource lifetime, acquisition, cleanup, and mutation.
- Data compatibility: persisted schemas, encodings, database layouts,
protocols, and wire formats.
Additive exports, optional parameters, and behavior-preserving implementations
are normally non-breaking. A fix restoring the documented contract is normally
non-breaking but still needs a changeset when its operational impact is
consumer-visible. Verify representative existing calls when overload ordering,
structural assignability, or inference makes compatibility uncertain. API diff
output is mechanical evidence, not a semantic-version decision.
The task is complete when every affected surface and published package is
accounted for and either the no-changeset decision is explicit or one coherent,
valid changeset describes the consumer impact and migration for every break.
1---2name: changesets3description: Changesets. Use after consumer-visible runtime, public API, entrypoint, lifecycle, or wire-format changes, when deciding whether a change is breaking, or when authoring changesets and consumer release notes.4---56Record what consumers need to know after implementation and focused validation.78## Workflow9101. Inspect the complete diff and identify directly affected published packages.112. Classify impact across source types, runtime behavior, entrypoints, required12 services, lifecycle, and persisted or wire data.133. Perform the breaking audit below.144. Record either a reason no changeset is required or one coherent changeset.15 When required, read [authoring.md](authoring.md).165. Validate package names, frontmatter, bump policy, and consumer-facing text.1718Do not include unrelated worktree changes.1920## Requirement2122Create a changeset for observable runtime behavior changes, including bug23fixes; exported value or public type changes; entrypoint or export-map changes;24changes to required services, errors, ownership, defaults, or lifecycle; and25persisted, serialization, protocol, or wire-format changes.2627Tests-only changes, behavior-preserving internal refactors, documentation or28JSDoc maintenance, and unpublished tooling normally do not need one. When29unclear, inspect exports and consumer-visible declarations rather than inferring30from source location.3132## Breaking Audit3334A change is breaking when valid existing consumer code, configuration, or data35must change to keep compiling or behaving according to the previous contract.36Audit every surface:3738- **Names and locations:** exports, entrypoints, compatibility exports, and39 module paths.40- **Call compatibility:** parameters, accepted inputs, overload resolution,41 generic parameters, and defaults.42- **Result compatibility:** return and error types, output narrowing, members,43 inference, and required services.44- **Runtime contracts:** defaults, failures, interruption, concurrency,45 ordering, resource lifetime, acquisition, cleanup, and mutation.46- **Data compatibility:** persisted schemas, encodings, database layouts,47 protocols, and wire formats.4849Additive exports, optional parameters, and behavior-preserving implementations50are normally non-breaking. A fix restoring the documented contract is normally51non-breaking but still needs a changeset when its operational impact is52consumer-visible. Verify representative existing calls when overload ordering,53structural assignability, or inference makes compatibility uncertain. API diff54output is mechanical evidence, not a semantic-version decision.5556The task is complete when every affected surface and published package is57accounted for and either the no-changeset decision is explicit or one coherent,58valid changeset describes the consumer impact and migration for every break.
foldkit