EmbedPDF changesets
Create release metadata from the actual package changes in the pull request,
including relevant uncommitted work. The repository convention is strict: one
changeset file describes exactly one package.
Audit the change
- Resolve the PR base branch and merge base. Inspect committed changes from the
merge base through
HEAD, then inspect staged, unstaged, and untracked files.
- Group changed files by their nearest package manifest. Read each affected
package.json and the repository Changesets configuration.
- Review changesets added by this PR separately from changesets that already
exist on the base branch.
- Decide which directly changed packages have a user-visible release impact.
Add a changeset for a publishable package when its runtime behavior, public API,
types, exports, generated client surface, packaged assets, or dependency
requirements change. Usually skip private packages, tests alone, examples,
internal tooling, and comment- or documentation-only edits. Do not add release
notes merely because a downstream package belongs to a Changesets fixed group;
let Changesets compute fixed-group propagation.
File convention
Every new or retained file must have one package entry in its frontmatter:
---
'@embedpdf/example': minor
---
Add a user-facing description of the released behavior.
- Never put multiple packages in one changeset file.
- Keep one PR changeset per directly affected package. If the PR already has a
changeset for that package, update it instead of adding a duplicate.
- Split an existing combined changeset into one file per package, preserving and
tailoring the release note for each package.
- Use
minor for backward-compatible public features or API additions, patch
for fixes and internal adaptations, and major only for deliberate breaking
releases under the repository's prerelease policy.
- Describe shipped behavior for package users. Do not mention internal plans,
workstreams, phases, or tracking codes.
Verify coverage
Before finishing:
- Map every directly changed publishable package to exactly one PR changeset,
or record the concrete reason it does not require one.
- Parse every PR changeset and confirm its frontmatter has exactly one package
key, that the package exists, and that no package appears in two PR files.
- Confirm each bump level matches the package-level diff and each note is
package-specific, user-facing, and free of internal plan references.
- Format the changed changeset files with the repository formatter.
- Run
pnpm changeset status --since=origin/<base-branch> once the files are
visible to Git. When they are intentionally untracked, use an isolated
temporary index rather than altering the user's staging area.
- Run
git diff --check and report the final package-to-file mapping plus any
packages intentionally skipped.
1---2name: embedpdf-changesets3description: Create and audit Changesets release notes for EmbedPDF pull requests and working-tree changes. Use when a PR needs changesets, when package coverage must be verified, or when combined or duplicate package changesets need cleanup.4---56# EmbedPDF changesets78Create release metadata from the actual package changes in the pull request,9including relevant uncommitted work. The repository convention is strict: one10changeset file describes exactly one package.1112## Audit the change13141. Resolve the PR base branch and merge base. Inspect committed changes from the15 merge base through `HEAD`, then inspect staged, unstaged, and untracked files.162. Group changed files by their nearest package manifest. Read each affected17 `package.json` and the repository Changesets configuration.183. Review changesets added by this PR separately from changesets that already19 exist on the base branch.204. Decide which directly changed packages have a user-visible release impact.2122Add a changeset for a publishable package when its runtime behavior, public API,23types, exports, generated client surface, packaged assets, or dependency24requirements change. Usually skip private packages, tests alone, examples,25internal tooling, and comment- or documentation-only edits. Do not add release26notes merely because a downstream package belongs to a Changesets fixed group;27let Changesets compute fixed-group propagation.2829## File convention3031Every new or retained file must have one package entry in its frontmatter:3233```md34---35'@embedpdf/example': minor36---3738Add a user-facing description of the released behavior.39```4041- Never put multiple packages in one changeset file.42- Keep one PR changeset per directly affected package. If the PR already has a43 changeset for that package, update it instead of adding a duplicate.44- Split an existing combined changeset into one file per package, preserving and45 tailoring the release note for each package.46- Use `minor` for backward-compatible public features or API additions, `patch`47 for fixes and internal adaptations, and `major` only for deliberate breaking48 releases under the repository's prerelease policy.49- Describe shipped behavior for package users. Do not mention internal plans,50 workstreams, phases, or tracking codes.5152## Verify coverage5354Before finishing:55561. Map every directly changed publishable package to exactly one PR changeset,57 or record the concrete reason it does not require one.582. Parse every PR changeset and confirm its frontmatter has exactly one package59 key, that the package exists, and that no package appears in two PR files.603. Confirm each bump level matches the package-level diff and each note is61 package-specific, user-facing, and free of internal plan references.624. Format the changed changeset files with the repository formatter.635. Run `pnpm changeset status --since=origin/<base-branch>` once the files are64 visible to Git. When they are intentionally untracked, use an isolated65 temporary index rather than altering the user's staging area.666. Run `git diff --check` and report the final package-to-file mapping plus any67 packages intentionally skipped.
embedpdf