New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Version Bump Advisor

by murphytrueman in murphytrueman/design-system-ops

Decide the semver bump (major, minor or patch) for a design system release from a diff or change list, with reasoning and a CHANGELOG entry.

MITAuto-check passedDevelopment

Install Version Bump Advisor

skills CLI
$ npx skills add murphytrueman/design-system-ops --skill version-bump-advisor -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install murphytrueman/design-system-ops version-bump-advisor --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/murphytrueman/design-system-ops.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/version-bump-advisor .claude/skills/version-bump-advisor && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
version-bump-advisor
GitHub stars
203
Token cost
~2.9k tokens
SKILL.md length
1,475 words
Files
1
Skills in repo
36
Repo updated
First seen
Licence
MIT

At a glance

Decide the semver bump (major, minor or patch) for a design system release from a diff or change list, with reasoning and a CHANGELOG entry.

  • Works in 7 steps: Establish the baseline → Accept and Classify Input → Determine the Semver Bump → …
  • Tasks that involve Changelog and release notes
  • SKILL.md covers Before you begin: verify…, Context, Steps and Quality Checks, plus 1 more section
  • Calls npx

What it does

Version Bump Advisor is an agent skill from murphytrueman/design-system-ops. Decide the semver bump (major, minor or patch) for a design system release from a diff or change list, with reasoning and a CHANGELOG entry. Triggers: what version bump, is this breaking, major or minor. Release notes and announcements: change-communication. Migration scripts: codemod-generator.

Its SKILL.md is about 2.9k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Changelog and release notes, Design systems and Code migrations. The repository describes itself as: Claude Code skills for the work that keeps a design system alive. The licence is MIT.

When your agent uses it

  • Tasks that involve Changelog and release notes
  • Tasks that involve Design systems
  • Tasks that involve Code migrations

Example prompts

  • “/version-bump-advisor”

Requirements

  • Node.js
  • Pre-approved tools (allowed-tools): Read, Write, Grep, Glob, Bash(cat:*), Bash(ls:*), Bash(git diff:*), Bash(git tag:*), Bash(git log:*), Bash(npm pack:*), Bash(npm view:*)

Workflow steps

7 steps, taken from the step headings in SKILL.md.

  1. Establish the baseline
  2. Accept and Classify Input
  3. Determine the Semver Bump
  4. Flag Edge Cases
  5. Generate Changelog Entry
  6. List the Migration Inputs for Breaking Changes
  7. Generate Decision Record Snippet (for major bumps only)

What it can do on your machine

Read from SKILL.md and the folder at commit f167898. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Read
    • Write
    • Grep
    • Glob
    • Bash(cat:*)
    • Bash(ls:*)
    • Bash(git diff:*)
    • Bash(git tag:*)
    • Bash(git log:*)
    • Bash(npm pack:*)

    …and 1 more on the same allowed-tools line.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • npx

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use npx, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Version Bump Advisor loads about 2.9k tokens when it runs. Until then it costs about 79 tokens; SKILL.md has 1,475 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~79
When it runs · the whole SKILL.md, loaded when a task matches
~2.9k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from murphytrueman/design-system-ops at commit f167898, republished under its MIT licence (© murphytrueman). 1,475 words, ~2,865 tokens.

Download SKILL.mdSave it as .claude/skills/version-bump-advisor/SKILL.md (or your agent's skills folder).
name
version-bump-advisor
description
Decide the semver bump (major, minor or patch) for a design system release from a diff or change list, with reasoning and a CHANGELOG entry. Triggers: what version bump, is this breaking, major or minor. Release notes and announcements: change-communication. Migration scripts: codemod-generator.
allowed-tools
Read, Write, Grep, Glob, Bash(cat:*), Bash(ls:*), Bash(git diff:*), Bash(git tag:*), Bash(git log:*), Bash(npm pack:*), Bash(npm view:*)
references
../../knowledge-notes/component-governance.md, ../../knowledge-notes/design-to-code-contract.md, ../../knowledge-notes/output-discipline.md

Version Bump Advisor

Before you begin: verify references

Confirm that every path in this skill's frontmatter references: exists relative to this SKILL.md. If any is missing, stop: the install is incomplete, usually because a flattening installer (for example npx skills install) dropped the repo-root knowledge-notes/ directory. Tell the user to reinstall by a method in 1-INSTALL.md and run verify-install.sh from the install root. Proceed without the references only if the user explicitly says to, and then say in the output that it was produced without the pack's reference material.

Context

Design system versioning is a persistent source of team friction. Breaking changes are called minor because they "just affect two components." Minor improvements trigger unnecessary major bumps because someone worries about change. And the reasoning is never written down, so every release prompts the same debate.

This skill removes the subjectivity by applying a consistent classification framework to every change, then generating a changelog entry and reasoning that the team can trust. When the next release ships, there's a record of why it was a major and what consumers need to change.

This is the pack's single source for semver calls. Other skills (change-communication, contribution-workflow, deprecation-process, decision-record) point here rather than classifying changes themselves.

Steps

0. Establish the baseline

If you have repository access, read the current version from the package's package.json (each published package, in a monorepo) so the recommendation names the actual next version. Then diff the exported surface between the last release tag and the change: exported component names, prop types and defaults from the published type definitions (.d.ts or the types entry), token names, CSS custom properties, and the exports map in package.json. A change list from the user is a starting point; the diff is what catches the removal nobody mentioned. If you can't read either, say so and classify from the change list alone.

Use the team's release tooling, not a parallel format. If .changeset/ exists, the recommendation is a changeset file (.changeset/<short-name>.md with the package name, the bump and a one-line summary) and the changelog entry is what Changesets will generate from it. If commitlint or conventional commits are in use, phrase each entry as the commit type it maps to (feat, fix, feat!). If release-please or semantic-release is configured, say so: they decide the version from the commits, and this skill's job becomes checking that the commits are classified honestly.

1. Accept and Classify Input

Accept input in any form: git diff output, PR description, a list of changes in natural language, or direct conversation about planned changes.

For each change, classify it into exactly one category:

  • Breaking (→ major): removed prop, component, token, CSS custom property, variant, variant option or exports subpath; renamed API surface; a new required prop; a narrowed set of accepted values or types; a changed callback signature (different arguments, or a widened argument type consumers narrow on); changed default behaviour; a removed CSS class or a changed selector specificity; a DOM or ARIA change consumers' tests or styles query (a changed role, a removed data-testid, a changed element type); dropped browser or peer-dependency support
  • Minor (→ minor): new optional prop, new component, new token, new variant, new optional parameter, new CSS custom property, a widened set of accepted input values, added optional CSS class without removing existing classes
  • Patch (→ patch): bug fix (fix for unintended behaviour), documentation update, internal refactor with no API change, dependency update, performance improvement with no API change

Be strict about classifications. Misclassifying a breaking change as a patch or minor is worse than over-bumping. If you are unsure, err toward breaking, and say which item is uncertain and what would settle it.

2. Determine the Semver Bump

The highest-severity change wins. If there is one breaking change and five patches, the bump is major. If there are five minors and zero breaking changes, the bump is minor.

Lead with the bump, then the composition by type so the team sees what drove it. Example: "Bump: major (2.4.1 → 3.0.0). 1 breaking change, 3 new features, 2 bug fixes."

3. Flag Edge Cases

Design systems have scenarios that don't fit standard semver cleanly. Identify and resolve them:

  • Breaking changes disguised as fixes: A change labeled "bug fix" but that actually changes component behaviour (e.g., "fixed Button to now require an onClick handler"). This is breaking, not a patch. Reclassify.

  • Pre-1.0 versions: The semver spec says a 0.y.z version may change at any time and promises nothing. The convention most teams and npm's caret ranges follow is that a breaking change bumps the minor (0.4.0 → 0.5.0) and a feature or fix bumps the patch. Apply that convention, say it's a convention, and don't jump to 1.0 unless the team has planned it.

  • Deprecation-only releases: A release that deprecates a prop but does not remove it is minor (deprecation is additive). The removal is breaking and happens in a later major bump. Example: "@deprecated Use newProp instead" on oldProp in v2.4.0 is minor; removing oldProp in v3.0.0 is major.

  • Peer dependency changes: Changes to peer dependencies (e.g., "now requires React 18+", "drops support for Node 14") are often breaking and frequently miscategorised as patches. Reclassify if necessary.

  • CSS specificity changes: A change that keeps class names but increases specificity (e.g., .button becomes .button-group .button) can be breaking even if the API surface didn't change. It breaks overrides. Treat as breaking if consumers rely on specificity.

  • Token value changes: A changed token value (e.g., color-primary from #0047AB to #0052CC) defaults to minor for a deliberate visual change, or patch for a correction, because consumers referencing the token pick it up as intended. Treat it as breaking only if the team's stated versioning policy says so, or there's evidence consumers snapshot values (hardcoded copies, visual regression baselines they own, values baked into another platform's build). State which assumption the call rests on.

Document which edge cases apply to this release, even if the answer is "none apply."

Show full SKILL.md (488 more words)Show less
4. Generate Changelog Entry

Produce a changelog entry in markdown format, organised by category, ready for CHANGELOG.md once its open placeholders are filled. The entries and figures below are illustrative:

## [X.Y.Z] - YYYY-MM-DD

### Removed
- **ComponentName:** prop `oldProp`. Use `newProp` instead. [migration: change `oldProp={value}` to `newProp={value}`]

### Changed
- **ComponentName:** default `size` is now `sm` (was `md`). [migration: pass `size="md"` to keep the old look]

### Added
- **ComponentName:** variant `outline` (`variant="outline"`).
- **Tokens:** `color-secondary-light` for lighter secondary backgrounds.

### Deprecated
- **ComponentName:** prop `oldSize`. Use `size` instead. Removal planned for the next major.

### Fixed
- **ComponentName:** icon spacing now applies in all variants.
- **Tokens:** `color-disabled` opacity corrected to meet the contrast baseline.

The headings are Keep a Changelog's (Added, Changed, Deprecated, Removed, Fixed, Security), which is what CHANGELOG readers and tooling expect; anything under Removed or Changed that breaks consumers gets a [migration: ...] note. Internal refactors and dev-dependency updates don't go in a consumer changelog. Keep descriptions to one line per item.

5. List the Migration Inputs for Breaking Changes

The migration guide is written once, by change-communication. For every breaking change, give it one row: the before and after in a line each, and the rationale.

ChangeBeforeAfterRationale
Button prop rename<Button oldProp="value" /><Button newProp="value" />[from the PR or decision record, or [ask author]]

Consumers deserve to know why the change was necessary, but the reason has to come from the user, the PR description or a linked decision record. If none gives one, write [ask author] and list it with the other open placeholders. Don't invent a plausible reason, and don't expand the rows into a guide here.

6. Generate Decision Record Snippet (for major bumps only)

If the bump is major, offer to generate a decision record snippet in the format of the decision-record skill. Provide a template that the team can fill in:

## Decision: Version X.Y.Z (Major Release)

**Date:** YYYY-MM-DD
**Bump reason:** [1 sentence]
**Breaking changes:** [numbered list]
**Impact:** [who is affected, how many consumers]
**Rollout plan:** [immediate, phased, beta period, etc.]
**Communication:** [how will consumers learn about this]

Do not write the full decision record — that is the decision-record skill's job. Provide the skeleton so the team has a prompt.

Quality Checks

  1. Breaking changes correctly identified even when described as "fixes" or "improvements." Read the change carefully. If behaviour changes, default changes, type signature changes, or something is removed, it is breaking. Do not trust the PR author's classification.

  2. Pre-1.0 convention applied if the version is 0.x.x, and named as a convention. If bumping from 0.4.0 with a breaking change, the new version is 0.5.0, not 1.0.0, unless the team has planned the v1 release.

  3. Changelog entry is properly formatted and honest about gaps. Fill what's known; list open placeholders at the top of the output; never invent dates, links, owners, rationale or percentages. Every breaking change has a migration note.

  4. Migration notes included for every breaking change. Before/after code examples, one per breaking change. Rationale comes from a source, or is flagged [ask author].

  5. The team's release tooling was used where it exists: a changeset file, conventional-commit phrasing, or a note that release-please decides.

  6. Edge cases section addressed, even if none apply. At the end of the recommendation, include a section: "Edge cases: [none identified]" or "Edge cases: breaking change disguised as fix (reclassified), deprecation-only release (minor bump applied)." Show your work.

Small-System Note

For releases with fewer than 5 changes, the classification and changelog output are the same. The structure doesn't change; the volume is lower. Still apply all quality checks — a small release with a breaking change is still major.

© murphytrueman, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/version-bump-advisor of murphytrueman/design-system-ops.

Open the folder on GitHubat commit f167898

Compare with similar skills

Version Bump Advisor next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Version Bump Advisor compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Version Bump Advisor this skillmurphytrueman/design-system-ops203—~2.9kAutomated safety check: PassMIT
Lint Fixgetsentry/sentry46k—~1kAutomated safety check: PassCustom licence
Using Docs Kitlobehub/lobe-ui2.2k—~2.8kAutomated safety check: PassMIT
Write Biweekly Announcementrazorpay/blade656—~1.5kAutomated safety check: PassMIT
Deprecate R Functions and Argumentstidyverse/dplyr5.1k1 repos~1.2kAutomated safety check: PassCustom licence
Releasing Php Packageyansongda/pay5.4k—~1.6kAutomated safety check: PassMIT

Similar skills

  • Lint Fix

    getsentry/sentry

    Official

    Fix violations of an eslintPluginScraps rule across the codebase.

    46k GitHub stars~1k tokensUpdated today
    DevelopmentAuto-check passed

  • Using Docs Kit

    lobehub/lobe-ui

    Set up and author a documentation site with @lobehub/docs-kit (the lobedocs CLI, React Router + Vite static docs used by ui.lobehub.com).

    2.2k GitHub stars~2.8k tokensUpdated today
    Frontend & DesignAuto-check passed

  • Write Biweekly Announcement

    razorpay/blade

    Generate bi-weekly announcement posts for Blade Design System updates by analyzing changelog entries from the past two weeks

    656 GitHub stars~1.5k tokensUpdated today
    DevelopmentAuto-check passed

  • Deprecate R Functions and Arguments

    tidyverse/dplyr

    Walks through deprecating an R function or argument in a package: lifecycle warning, silenced tests, a new snapshot test, documentation badge and NEWS entry.

    5.1k GitHub starsUsed in 1 repo~1.2k tokens
    DevelopmentAuto-check passed

  • Releasing Php Package

    yansongda/pay

    A skill your agent uses when preparing to publish a new version of a PHP Composer package and need to write or update CHANGELOG, upgrade guides, and documentation before tagging and releasing

    5.4k GitHub stars~1.6k tokensUpdated 9 days ago
    DevelopmentAuto-check passed

  • Release

    jaemk/self_update

    Prepare a release (bump the crate version, update CHANGELOG.md with a migration guide for breaking changes, regenerate README, commit), or run a pre-release review.

    961 GitHub stars~2.2k tokensUpdated 1 mo ago
    DevelopmentAuto-check passed

More from murphytrueman/design-system-ops

All 36 skills in this repo

  • Agent Instructions

    murphytrueman/design-system-ops

    Write the AGENTS.md that tells coding agents how to use this design system: where things live, sourced rules, how to check work, what not to do; Claude, Cursor or Copilot pointers on request.

    203 GitHub stars~2.3k tokensUpdated 13 days ago
    Auto-check passed

  • AI Component Description

    murphytrueman/design-system-ops

    Write a six-section prose description (purpose, props, anti-patterns, composition, accessibility, examples) for a Figma component's description field so LLMs read it via MCP.

    203 GitHub stars~4.7k tokensUpdated 13 days ago
    Auto-check passed

  • Change Communication

    murphytrueman/design-system-ops

    Write release notes, a migration guide and a team announcement for a design system change that is already decided, scaled to its impact.

    203 GitHub stars~3.4k tokensUpdated 13 days ago
    Auto-check passed

  • Codebase Index

    murphytrueman/design-system-ops

    Generate machine-readable index files in .ai/index/ (component inventory, uses/usedBy graph, stats) for AI agents.

    203 GitHub stars~4.7k tokensUpdated 13 days ago
    Auto-check passed

  • Codemod Generator

    murphytrueman/design-system-ops

    Generate tested jscodeshift/postcss codemods for design system migrations: token renames, prop renames or removals, import paths, component swaps.

    203 GitHub stars~4.9k tokensUpdated 13 days ago
    Auto-check passed

  • Component API Validator

    murphytrueman/design-system-ops

    Audit prop APIs across a component library: naming consistency, boolean/default patterns, type coverage, exported types, breaking changes between versions.

    203 GitHub stars~4.3k tokensUpdated 13 days ago
    Auto-check passed

Categories

Questions about Version Bump Advisor

What does Version Bump Advisor do?

Decide the semver bump (major, minor or patch) for a design system release from a diff or change list, with reasoning and a CHANGELOG entry. Version Bump Advisor is an agent skill from murphytrueman/design-system-ops. Decide the semver bump (major, minor or patch) for a design system release from a diff or change list, with reasoning and a CHANGELOG entry.

When should I use Version Bump Advisor?

Version Bump Advisor fits situations like: tasks that involve Changelog and release notes; tasks that involve Design systems; tasks that involve Code migrations.

How do I install Version Bump Advisor in Claude Code?

Run `npx skills add murphytrueman/design-system-ops --skill version-bump-advisor -a claude-code`. Or copy the skill folder (skills/version-bump-advisor in murphytrueman/design-system-ops) into .claude/skills/version-bump-advisor in your project. Claude Code loads it when a task matches its description.

How do I install Version Bump Advisor in Codex?

Run `npx skills add murphytrueman/design-system-ops --skill version-bump-advisor -a codex`. Or copy the skill folder (skills/version-bump-advisor in murphytrueman/design-system-ops) into .agents/skills/version-bump-advisor in your project. Codex loads it when a task matches its description.

Can I use Version Bump Advisor in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add murphytrueman/design-system-ops --skill version-bump-advisor -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/version-bump-advisor, .gemini/skills/version-bump-advisor, .github/skills/version-bump-advisor and .opencode/skills/version-bump-advisor in your project.

What does Version Bump Advisor need to run?

Going by SKILL.md and its folder, Version Bump Advisor needs the command-line tools its instructions call (npx). Our summary lists: Node.js. Its frontmatter pre-approves these tools: Read, Write, Grep, Glob, Bash(cat:*), Bash(ls:*), Bash(git diff:*), Bash(git tag:*), Bash(git log:*), Bash(npm pack:*), Bash(npm view:*).

Does Version Bump Advisor access the network?

SKILL.md contains no URLs. Its commands use npx, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Version Bump Advisor safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Version Bump Advisor use?

Version Bump Advisor is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Version Bump Advisor use?

About 2.9k tokens (SKILL.md is roughly 11k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Version Bump Advisor?

Skills that share tags, products or a category with Version Bump Advisor: Lint Fix (getsentry/sentry, 46k stars), Using Docs Kit (lobehub/lobe-ui, 2.2k stars), Write Biweekly Announcement (razorpay/blade, 656 stars) and Deprecate R Functions and Arguments (tidyverse/dplyr, 5.1k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Version Bump Advisor?

murphytrueman (a GitHub user) maintains it in murphytrueman/design-system-ops, which has 203 GitHub stars. The repository holds 36 skills in this directory. The repository was last updated on September 24, 2026.

Source: murphytrueman/design-system-ops on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.