# Changeset

> Use when the user asks to create, generate, write, or apply a Changesets release note/version bump from current code changes (for example "make a changeset", "add a changeset", "apply changesets", or "version packages").

- Skill: `stolinski/changeset` (Agent Skill)
- Install (CLI): `npx skillmds@latest add stolinski/changeset`
- Raw SKILL.md: https://api.skillmd.com/api/skills/stolinski/changeset/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: stolinski (https://skillmd.com/u/stolinski)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/stolinski/changeset

---


# Changeset

Use this skill to create and optionally apply Changesets based on the code changes in the current session.

## What this skill does

- Detects what changed in the working tree.
- Maps changed files to affected packages in a monorepo or single-package repo.
- Proposes appropriate semver bump levels (`patch`, `minor`, `major`) with rationale.
- Creates a changeset markdown file in `.changeset/`.
- Applies pending changesets (`changeset version`) when requested.

## Preconditions

- Repository uses `@changesets/cli` (or has an equivalent `changeset` script).
- `.changeset/` exists or can be created.
- The user requested changeset creation and/or application.

## Safety rules

1. Do not apply changesets unless the user asked to apply them.
2. Do not invent package names; only use workspace package names found in `package.json` files.
3. Exclude private/internal packages unless the repo convention explicitly versions them.
4. If bump type is ambiguous, default to `patch` and explain why.
5. Never include unrelated files or speculative release notes.

## Workflow

1. Inspect repo state:
   - `git status --short`
   - `git diff --name-only` (and staged diff when relevant)
2. Detect package manager and scripts from root `package.json`.
3. Identify affected packages:
   - For monorepos, map changed files to nearest package root.
   - For single-package repos, use root package name.
4. Decide bump level per package:
   - `patch`: bug fixes, internal refactors, non-breaking behavior changes.
   - `minor`: new backwards-compatible functionality.
   - `major`: breaking changes.
5. Draft concise release note text focused on user impact.
6. Create changeset file in `.changeset/*.md` with frontmatter package bumps.
7. If user asked to apply it, run one of:
   - `pnpm changeset version`
   - `npm run changeset version` (if script exists)
   - `bunx changeset version`
8. Report exactly what was created/changed.

## Changeset template

```md
---
"@scope/package-a": minor
"@scope/package-b": patch
---

Short, concrete summary of what changed and why users should care.
```

## Command selection

Prefer project-native tooling in this order:

1. Existing script in `package.json` (for example `pnpm changeset`, `npm run changeset`).
2. Package-manager exec (`pnpm changeset`, `bunx changeset`, `npx changeset`).

## Output format

Return:

1. `Affected Packages`
2. `Bump Decisions`
3. `Changeset File`
4. `Applied` (yes/no, and command used)
5. `Notes` (ambiguities, assumptions, or follow-ups)