Changesets release
Skill wakqasahmed/ai-engineering-workflow-skills/skills/engineering/changesets-release
Canonical AI engineering workflow skills, aggregated by wakqasahmed/skills
npx -y skills add wakqasahmed/ai-engineering-workflow-skills --skill changesets-releaseAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Records release intent with Changesets and guides semver, changelog, CI, and artifact-version checks for independently distributed packages. Use when a repository has `@changesets/cli`, `.changeset/`, a version-packages PR, publishable plugins, SDKs, libraries, or monorepos.
SKILL.md
2.9 KB, as published. Nobody here has run it
Changesets Release
Use this for consumer-installed packages. Do not require Changesets for a single deployed application unless its owner chooses release versions.
Decide Scope
- Use it for libraries, SDKs, CLIs, plugins, and packages published independently.
- In a monorepo, include every changed consumer package; let Changesets calculate internal dependency bumps.
- For internal-only work, use the repository's explicit
no-changesetconvention. Do not add an empty changeset merely to satisfy CI. - Before first adoption, confirm the owner wants Changesets, then initialize it with the repository's package manager. Do not introduce a release dependency unilaterally.
Add Release Intent
- Read
.changeset/config.json, package metadata, and the consumer contract before choosing a bump. - Use
patchfor compatible fixes,minorfor compatible capabilities, andmajorfor breaking behavior, removed APIs, or required consumer changes. - Run the configured
changesetcommand and commit its generated.changeset/<name>.mdwith the implementation PR. - Write the entry for consumers: what changed, why it matters, and migration steps when needed. Never copy a commit subject as the release note.
CI And Version PR
- Require a changeset or an approved
no-changesetmarker on releaseable PRs;changeset statusis the non-interactive CI check. - Use the Changesets GitHub Action to create/update a version-packages PR. Review generated versions and changelogs before merging.
- Keep publishing credentials in CI secrets. Never put registry tokens in a changeset, repository config, or commit.
Non-NPM Artifacts
Changesets records release intent; it does not automatically update every native manifest. The version PR must update and verify every public version surface.
- WordPress plugin: plugin header,
readme.txtstable tag, ZIP filename/metadata, Git tag, and release notes. - PHP/Composer package: package metadata, tag, generated artifact, and changelog.
- Application: only use Changesets when its release version is a real customer contract; otherwise keep deployment SHA and release notes separate.
Release Check
- Run the affected package tests and build.
- Confirm generated changelog text is accurate and actionable.
- Confirm the final tag and every distributable artifact report the same version.
- Use
release-gatefor staging, rollout, rollback, and health checks.
Verification
changeset statussucceeds in CI for a releaseable change.- The version PR contains the expected bump and changelog entry.
- Artifact inspection proves all public version surfaces match the release tag.