| name | changeset |
| description | Create a changeset for package releases. Analyzes commits since the last release, determines affected packages and bump type, and generates a changeset file. |
| user_invocable | true |
Changeset Skill
Create a changeset by analyzing commits since the last release tag.
Workflow
1. Identify the last release tag for each package
List all release tags sorted by version:
git tag --list '@vimee/*' --sort=-version:refname
From this output, extract the latest (highest version) tag for each package name. Tags follow the format @vimee/<name>@<version>. For each unique package name, take the first (highest) tag.
2. Determine affected packages per-package
For each package, use its latest tag from step 1 to compare against HEAD. Only check src/ directories to focus on source changes:
git log '<LATEST_TAG>..HEAD' --oneline -- packages/<name>/src
Do this for every package that has at least one release tag. If a package has no release tag yet, skip it or ask the user.
Only include packages that have actual source changes (ignore CI-only or docs-only changes outside packages/*/src).
3. Determine bump type for each package
Analyze the commit messages for each affected package:
| Commit prefix | Bump type |
|---|
fix: | patch |
feat: | minor |
BREAKING CHANGE or !: in message | major |
chore:, ci:, docs:, refactor:, test: | No bump needed (skip unless they contain functional changes) |
Choose the highest bump type found across all commits for each package.
If the bump type is ambiguous or could be interpreted as either minor or major, ask the user before proceeding.
4. Confirm with user
Present the plan before creating the changeset, showing per-package comparisons:
<package> (since <its-latest-tag>):
- <commit list for that package>
Changeset:
- @vimee/<pkg>: <bump>
...
Summary: <one-line description>
Ask: "Does this look right?" — adjust if the user wants to change the bump type or summary.
5. Create the changeset file
Write to .changeset/<descriptive-name>.md:
---
"@vimee/shiki-editor": patch
"@vimee/core": minor
---
<summary describing what changed and why>
6. Commit the changeset
Commit with message: chore: add changeset for <brief description>
Important Notes
- Do NOT run
changeset version or changeset publish — the release.yaml GitHub Action handles versioning and publishing automatically when changesets are merged to main.
updateInternalDependencies is set to "patch" in .changeset/config.json, so dependents get bumped automatically.- If there are no package changes since the last tag (only CI/docs changes), inform the user that no changeset is needed.
