From enterspeed
Analyse unreleased commits and propose a semantic version bump for an Enterspeed project. Use when the user says "prepare a release", "what should the next version be", "check what's unreleased", or "propose a version bump". Run this before gitflow-release-start to review the proposed version before any changes are made.
How this skill is triggered — by the user, by Claude, or both
Slash command
/enterspeed:gitflow-release-prepareThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Reads the current version from `azure-pipeline.yaml`, pulls the latest branches, analyses unreleased commits, and proposes a semantic version bump. No files are modified and no branches are created — this is a read-only step to let you review and confirm the version before starting the release.
Reads the current version from azure-pipeline.yaml, pulls the latest branches, analyses unreleased commits, and proposes a semantic version bump. No files are modified and no branches are created — this is a read-only step to let you review and confirm the version before starting the release.
Run the gitflow-prerequisites skill first. If any check fails, stop — do not continue.
Find the pipeline file (checks both .yaml and .yml extensions):
PIPELINE_FILE=$(ls azure-pipelines.yaml 2>/dev/null || ls azure-pipelines.yml 2>/dev/null || ls azure-pipeline.yaml 2>/dev/null || ls azure-pipeline.yml 2>/dev/null)
Store the found filename as PIPELINE_FILE. If none of the four variants are found, ask the user for the path. Verify the user-provided path exists before continuing.
Extract the three version variables:
grep -E '^\s*(majorVersion|minorVersion|patchVersion):' "$PIPELINE_FILE"
Verify all three keys were found. If any are missing, stop and tell the user:
"Could not find
majorVersion,minorVersion, orpatchVersionin$PIPELINE_FILE. Check that the file follows the expected format."
If the keys are present but have unexpected formatting (e.g., quoted values, unusual indentation, or YAML nesting), ask the user:
"Found version keys in
$PIPELINE_FILEbut they may have unexpected formatting. Please verify the exact format matches the standard pattern (e.g.,majorVersion: 1with no quotes)."
Parse the current version as {major}.{minor}.{patch}.
git checkout master && git pull origin master
git checkout develop && git pull origin develop
If either command fails, stop and report the error.
Find the most recent tag:
git describe --tags --abbrev=0 2>/dev/null || echo "no-tags"
Enterspeed projects use plain semver tags without a v prefix (e.g. 1.53.0, not v1.53.0). If the detected tag starts with v, stop and tell the user:
"The most recent tag (
<tag>) uses avprefix, which doesn't match the expected convention. If you believe your tags follow a different convention, contact your team lead before releasing."
List real commits (excluding merges) since the last tag:
git log <last-tag>..HEAD --no-merges --oneline
If this command fails, stop and report the error:
"Failed to retrieve commit history. Check your network connection and ensure the repository is accessible."
If no tags exist, list the most recent commits:
git log --no-merges --oneline -20
Before proposing a bump, always run a full log to search commit bodies for BREAKING CHANGE (the oneline format above only shows commit subjects). If a tag exists, search from the tag to HEAD; if no tags exist, search the last 20 commits:
if [ "<last-tag>" = "no-tags" ]; then
git log -20 --no-merges --format="%B"
else
git log <last-tag>..HEAD --no-merges --format="%B"
fi
If this command fails, stop and report the error.
If a tag exists but no commits are found since it, check if develop and master are on the same commit:
git rev-parse develop
git rev-parse master
If they match, tell the user:
"No commits found since the last release (
<last-tag>), and develop and master are on the same commit. There may be nothing to release. Should I still propose a patch bump ({major}.{minor}.{patch+1}), or skip?"
If they don't match, tell the user:
"No commits found since the last release (
<last-tag>) on develop. There may be nothing to release. Should I still propose a patch bump ({major}.{minor}.{patch+1}), or skip?"
Stop and wait for their answer:
If they choose patch bump: Continue to Step 4 and propose {major}.{minor}.{patch+1}
If they choose skip: Stop the skill. No version is proposed and no further action is taken. Tell the user:
"Skipping release preparation. No changes have been made. Re-run this skill when you have commits to release."
If no response is received within a reasonable time, stop and tell the user:
"No response received. Please re-run this skill when you're ready to continue."
Determine the bump type following Conventional Commits:
! (e.g. feat!:, fix!:) OR any commit body/footer contains BREAKING CHANGE: → majorfeat: or feat( → minorApply the highest-priority bump found:
{major+1}.0.0{major}.{minor+1}.0{major}.{minor}.{patch+1}Present the full picture to the user:
Current version: 1.52.2 (from azure-pipeline.yaml)
Last release tag: 1.52.2
Unreleased commits:
abc1234 feat: add new dashboard widget
def5678 fix: correct API timeout handling
ghi9012 chore: update dependencies
Proposed bump: minor → 1.53.0
Ask: "Should I proceed with version 1.53.0, or would you like a different version? (Must be MAJOR.MINOR.PATCH)"
Validate any user-provided version:
N.N.N pattern (three numeric parts separated by dots)If the format is invalid or the bump logic seems wrong, reject it and re-prompt:
"Version
X.Y.Zdoesn't look right. It should be higher than{current}and follow semantic versioning with single-increment bumps only. Please provideMAJOR.MINOR.PATCH(e.g., 1.53.0)."
If no response is received within a reasonable time, stop and tell the user:
"No response received. Please re-run this skill when you're ready to continue."
Once confirmed, tell the user:
"Version
1.53.0confirmed. When you're ready, I can run gitflow-release-start with version1.53.0to create the release branch and update the pipeline file. Would you like to proceed now?"
Wait for explicit user confirmation before invoking gitflow-release-start. Do not automatically trigger the next skill.
npx claudepluginhub enterspeedhq/agent-skills --plugin enterspeedStarts git-flow release branch: validates semver version, bumps in package.json/Cargo.toml/VERSION/etc., commits via git-agent, pushes to origin/release/<version>.
Determines the correct SemVer 2.0.0 version bump by analyzing git history and classifying changes as major, minor, or patch. Use when preparing a release, after merging changes, or resolving version disagreements.
Validates and executes software releases with changelog generation, version bumping, git tagging, and CI verification.