Assess and bump the SDK version using Semantic Versioning 2.0.0. Evaluates queued changes to recommend PATCH/MINOR/MAJOR, updates src/Directory.Build.props, and creates a pull request. Owns the SemVer assessment logic shared by prepare-release and publish-release. Use when asked to bump the version, assess the version, or determine what the next version should be.
68
83%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Assess and bump the SDK version in src/Directory.Build.props to prepare for the next release. This skill owns the Semantic Versioning 2.0.0 assessment logic — the SemVer assessment guide is the single source of truth for version assessment criteria used across the release workflow by both the prepare-release and publish-release skills.
Use the shared release branch reference for branch roles, previous-release lookup rules, and release work-branch naming.
Note: For comprehensive release preparation — including ApiCompat/ApiDiff, documentation review, and release notes — use the prepare-release skill, which incorporates version assessment as part of its broader workflow.
Read src/Directory.Build.props on the current branch and extract:
<VersionPrefix> — the MAJOR.MINOR.PATCH version<VersionSuffix> — the prerelease suffix, when presentThe candidate version is {VersionPrefix} plus -{VersionSuffix} when the suffix is present (for example, 2.0.0-preview.1). Display the current candidate version to the user.
Determine the previous release tag from gh release list — the highest semver among published releases that are ancestors of the target commit, not the most recently published by date. Draft releases must be ignored — they represent a pending release that has not yet shipped. Use --exclude-drafts or filter to only published releases when querying. The lookup is branch-aware: from a release/{MAJOR}.x branch, restrict candidates to tags matching v{MAJOR}.*; from main, there is no MAJOR filter. See release-branches.md for details, including why date ordering picks the wrong tag.
If the user provided a target version in their prompt, use it directly. Otherwise, determine the next version using one of two approaches:
When context about queued changes is available or can be gathered, assess the version following the SemVer assessment guide:
[Experimental] APIsDirectory.Build.props and flag any discrepancy.When a quick bump is needed without full change analysis, suggest based on the candidate version:
1.0.0 → suggest 1.1.01.2.3 → suggest 1.3.0preview. or rc. followed by an integer, suggest incrementing the trailing integer:
2.0.0-preview.1 → suggest 2.0.0-preview.22.0.0-rc.1 → suggest 2.0.0-rc.2Present the suggestion and let the user confirm or provide an alternative.
Parse the confirmed version into its VersionPrefix and VersionSuffix components. Stable versions have no suffix.
bump-version-to-{version} (e.g. bump-version-to-1.1.0) from the current branchsrc/Directory.Build.props:
<VersionPrefix> to the confirmed stable component<VersionSuffix> for prerelease versions, or clear it for stable versions; add the element if it is missing<PackageValidationBaselineVersion> if the MAJOR version has changedBump version to {version}Bump version to {version}infrastructurerelease/1.x, is that servicing branch — not main)Display the pull request URL to the user.
609499b
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.