changeset

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:

# For each package, substitute <LATEST_TAG> with the actual latest tag found in step 1.
# Example: if the latest tag for core is @vimee/core@0.3.0, run:
#   git log '@vimee/core@0.3.0..HEAD' --oneline -- packages/core/src
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.