بنقرة واحدة
changelog-version
Generate changelog entries and suggest semantic version bumps from git history
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Generate changelog entries and suggest semantic version bumps from git history
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Execute roadmap items iteratively with policy-aware vendor routing and learning feedback
Orchestrate the full plan-review-implement-validate-PR lifecycle with multi-vendor review convergence
OpenBao/Vault credential seeding and management scripts
Comprehensive project health diagnostic — collects signals from CI tools, existing reports, deferred issues, and code markers into a prioritized finding report
HTTP fallback bridge for coordinator when MCP transport is unavailable
Readiness gate for sync-point operations — inspect validation, rework, and active-agent state before merge
| name | changelog-version |
| description | Generate changelog entries and suggest semantic version bumps from git history |
| category | Git Workflow |
| tags | ["changelog","versioning","semver","release"] |
| triggers | ["update changelog","changelog","version bump","what version","release version","suggest version"] |
Generate changelog entries from git history and suggest semantic version bumps based on conventional commit types.
$ARGUMENTS - Optional flags:
--since <ref> (git ref or tag to start from; default: last changelog update or all commits)--bump (apply the suggested version bump to VERSION and CHANGELOG.md)--dry-run (show what would change without modifying files; default when no flags given)--format <keep-a-changelog|simple> (changelog format; default: keep-a-changelog)type(scope): message)VERSION file in project root (created automatically if missing)CHANGELOG.md in project root (created automatically if missing)Default analysis and --dry-run are read-only. Any invocation that applies a
version bump or writes VERSION / CHANGELOG.md MUST first enter a managed
worktree in local CLI execution:
CHANGE_ID="changelog-version-<version-or-date>"
eval "$(python3 "<skill-base-dir>/../worktree/scripts/worktree.py" setup "$CHANGE_ID")"
cd "$WORKTREE_PATH"
python3 "<skill-base-dir>/../shared/checkout_policy.py" require-mutation
The script analyzes commits since the last version tag or changelog entry and suggests a bump level:
| Commit Prefix | SemVer Impact | Examples |
|---|---|---|
feat | MINOR bump | New skill, new capability, new API endpoint |
fix | PATCH bump | Bug fixes, corrections |
docs | PATCH bump | Documentation-only changes |
refactor | PATCH bump | Code restructuring without behavior change |
chore | PATCH bump | Maintenance, dependency updates, archiving |
test | PATCH bump | Test additions or fixes |
perf | PATCH bump | Performance improvements |
BREAKING CHANGE | MAJOR bump | Footer or ! after type signals breaking change |
The highest-impact commit determines the suggestion. For example, if there are 5 fix commits and 1 feat commit, the suggestion is MINOR.
Run the changelog analysis script to scan commits and categorize changes:
python3 <agent-skills-dir>/changelog-version/scripts/changelog.py analyze \
--repo-root <project-root> \
--since <ref-or-tag>
This outputs:
VERSION filePresent the analysis to the user:
VERSIONAsk the user to confirm or override the suggested bump level before applying.
python3 <agent-skills-dir>/changelog-version/scripts/changelog.py apply \
--repo-root <project-root> \
--bump <major|minor|patch> \
--date <YYYY-MM-DD>
This will:
VERSION with the new version number[Unreleased] entries in CHANGELOG.md under a new version heading[Unreleased] sectionAfter applying, commit both files:
git add VERSION CHANGELOG.md
git commit -m "chore(release): bump version to <new-version>"
This skill is designed to be invoked:
/implement-feature — to preview what version bump the new feature warrants/cleanup-feature — to include the changelog entry in the merge PRWhen invoked after implementing a feature, the script automatically detects the OpenSpec change-id from the branch name and highlights commits related to that change.