How do I install the Bump Version skill?

Run npx skillmds@latest add sswconsulting/bump-version in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Bump Version safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Bump Version?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Bump Version free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Bump Version?

sswconsulting (@sswconsulting) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Bump Version by sswconsulting — Agent Skill

Name: Bump Version
Author: sswconsulting

Bump Version

Bump the SSW.VerticalSliceArchitecture.Template NuGet package version to cut a new release. Use when the user says "bump the version", "cut a release", "release a new version", "publish a new package version", or similar for this template repo. Edits the version in VerticalSliceArchitecture.nuspec — which is what triggers the publish — but never pushes or opens a PR.

File contents

What "bump the version" means in this repo

This repo is a dotnet new template published to NuGet as SSW.VerticalSliceArchitecture.Template. The release is push-triggered, not tag-triggered.

.github/workflows/package.yml runs only when a push to main changes VerticalSliceArchitecture.nuspec. When it does, it:

Packs the template with nuget pack.
Pushes the .nupkg to NuGet.org.
Reads <version> from the nuspec and creates a matching git tag.
Publishes a GitHub release on that tag with auto-generated notes.

So the <version> value in VerticalSliceArchitecture.nuspec is the release. Changing it and merging to main ships a new package. Nothing else cuts a release.

Versioning scheme: CalVer

Versions are calendar dates, YYYY.MM.DD (e.g. 2025.12.10, 2026.06.12). There is no SemVer major/minor/patch decision — the new version is simply today's date.

To find the latest published version, use gh release view --json tagName -q .tagName — that's authoritative. Don't trust git tag --sort=-v:refname | head: the repo has both v-prefixed and bare tags (v2025.10.24 and 2025.12.10), and the mixed namespace makes that sort return a stale tag above the real latest.

Steps

Read the current <version> from VerticalSliceArchitecture.nuspec.
Compute today's date as YYYY.MM.DD. That is the new version.
Guard against a same-day re-release: run git fetch --tags first (release tags are created by CI on the remote, so a local-only git tag can miss one shipped earlier today), then check the date isn't already a tag. If it is, a release already shipped today — append a numeric suffix (YYYY.MM.DD.1) or ask the user how they want to disambiguate. Don't silently overwrite.
Update <version> to the new value.
Refresh <releaseNotes>: summarise what changed since the last release. The <version> you read in step 1 (before bumping) is the previous release's tag, so use it as the changelog base: git log --oneline <previous-version>..HEAD. Distil that into a short, human summary (one or two sentences). This is the NuGet page blurb — GitHub generates the full PR-list notes separately, so keep it terse.
Run the humanizer skill over the release-notes prose before finishing (per the repo/global content-writing rule).

Guardrails

Don't push. Don't open a PR. Don't merge to main. Editing the nuspec on main is what triggers the publish, so that final step is the user's call — leave the change as a reviewable diff.
Only touch VerticalSliceArchitecture.nuspec. The package versions in Directory.Packages.props are unrelated to the template's release version.
Don't edit the workflow.

Verify

The change is metadata only — no build or test impact. Re-read the nuspec diff to confirm the version and notes are right. CI runs nuget pack (which needs mono) on merge, so there's nothing useful to run locally.

---name: bump-versiondescription: Bump the SSW.VerticalSliceArchitecture.Template NuGet package version to cut a new release. Use when the user says "bump the version", "cut a release", "release a new version", "publish a new package version", or similar for this template repo. Edits the version in VerticalSliceArchitecture.nuspec — which is what triggers the publish — but never pushes or opens a PR.---## What "bump the version" means in this repoThis repo is a `dotnet new` template published to NuGet as `SSW.VerticalSliceArchitecture.Template`. The release is push-triggered, not tag-triggered.`.github/workflows/package.yml` runs only when a push to `main` changes `VerticalSliceArchitecture.nuspec`. When it does, it:1. Packs the template with `nuget pack`.2. Pushes the `.nupkg` to NuGet.org.3. Reads `<version>` from the nuspec and creates a matching git tag.4. Publishes a GitHub release on that tag with auto-generated notes.So the `<version>` value in `VerticalSliceArchitecture.nuspec` *is* the release. Changing it and merging to `main` ships a new package. Nothing else cuts a release.## Versioning scheme: CalVerVersions are calendar dates, `YYYY.MM.DD` (e.g. `2025.12.10`, `2026.06.12`). There is no SemVer major/minor/patch decision — the new version is simply today's date.To find the latest published version, use `gh release view --json tagName -q .tagName` — that's authoritative. Don't trust `git tag --sort=-v:refname | head`: the repo has both `v`-prefixed and bare tags (`v2025.10.24` *and* `2025.12.10`), and the mixed namespace makes that sort return a stale tag above the real latest.## Steps1. Read the current `<version>` from `VerticalSliceArchitecture.nuspec`.2. Compute today's date as `YYYY.MM.DD`. That is the new version.3. Guard against a same-day re-release: run `git fetch --tags` first (release tags are created by CI on the remote, so a local-only `git tag` can miss one shipped earlier today), then check the date isn't already a tag. If it is, a release already shipped today — append a numeric suffix (`YYYY.MM.DD.1`) or ask the user how they want to disambiguate. Don't silently overwrite.4. Update `<version>` to the new value.5. Refresh `<releaseNotes>`: summarise what changed since the last release. The `<version>` you read in step 1 (before bumping) is the previous release's tag, so use it as the changelog base: `git log --oneline <previous-version>..HEAD`. Distil that into a short, human summary (one or two sentences). This is the NuGet page blurb — GitHub generates the full PR-list notes separately, so keep it terse.6. Run the `humanizer` skill over the release-notes prose before finishing (per the repo/global content-writing rule).## Guardrails- Don't push. Don't open a PR. Don't merge to `main`. Editing the nuspec on `main` is what triggers the publish, so that final step is the user's call — leave the change as a reviewable diff.- Only touch `VerticalSliceArchitecture.nuspec`. The package versions in `Directory.Packages.props` are unrelated to the template's release version.- Don't edit the workflow.## VerifyThe change is metadata only — no build or test impact. Re-read the nuspec diff to confirm the version and notes are right. CI runs `nuget pack` (which needs mono) on merge, so there's nothing useful to run locally.

Frequently asked questions