Bump package version, generate changelog docs, commit, tag, and create GitHub release. Use when: (1) User says 'version bump', 'bump version', 'release', or 'zudo-doc-version-bump', (2) User wants to create a new release of this project.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Bump package version, generate changelog docs, commit, tag, and create GitHub release. Use when: (1) User says 'version bump', 'bump version', 'release', or 'zudo-doc-version-bump', (2) User wants to create a new release of this project.
user-invocable
true
disable-model-invocation
true
argument-description
Optional: major, minor, or patch to skip the proposal step
/zudo-doc-version-bump
Bump the version, generate changelog doc pages, commit, tag, and create a GitHub release.
Preconditions
Before doing anything else, verify ALL of the following. If any check fails, stop and tell the user.
Current branch is main
Working tree is clean (git status --porcelain returns empty)
At least one v* tag exists (git tag -l 'v*'). If no tag exists, tell the user to create the initial tag first (e.g. git tag v0.1.0 && git push --tags).
Find the latest version tag:
git tag -l 'v*' --sort=-v:refname | -1
head
Analyze changes since last tag
Run:
git log <last-tag>..HEAD --oneline
and
git diff <last-tag>..HEAD --stat
Categorize each commit by its conventional-commit prefix:
Breaking Changes: commits with an exclamation mark suffix (e.g. feat!:) or BREAKING CHANGE in body
Only show sections that have entries. Wait for user confirmation before proceeding.
If this is a major version bump, ask the user whether they want to archive the current docs as a versioned snapshot (i.e. run with --snapshot). Explain that this copies the current docs to a versioned directory for the old version.
Run version-bump.sh
Run the existing version bump script to update package.json and create changelog entry files:
./scripts/version-bump.sh {NEW_VERSION}
# Or with snapshot for major bumps:
./scripts/version-bump.sh {NEW_VERSION} --snapshot
Each entry should be the commit subject with the short hash in parentheses
Build and test
Run the full build and test suite to make sure everything is good:
pnpm b4push
If anything fails, fix the issue and re-run. Do not proceed with committing until all checks pass.
Commit changes
Stage and commit all version bump changes — include any files modified by b4push formatting fixes:
git add package.json src/content/docs/changelog/{NEW_VERSION}.mdx src/content/docs-ja/changelog/{NEW_VERSION}.mdx
# Also stage any other modified files (e.g. formatting fixes from b4push)
git diff --name-only | xargs git add
git commit -m "chore: Bump version to v{NEW_VERSION}"
Push and wait for CI
Push the commits first (without the tag) and wait for CI to pass:
git push
Then check CI status. Use gh run list --branch main --limit 1 --json status,conclusion,headSha and verify the headSha matches the pushed commit. Poll every 30 seconds, with a maximum of 10 minutes. If CI is still running after 10 minutes, ask the user whether to keep waiting or proceed.
If CI fails, investigate the failure with gh run view <run-id> --log-failed, fix the issue, commit, and push again.
Do not tag or publish until CI is green.
Tag, push tag, and create GitHub release
Ask the user for confirmation before tagging.
git tag v{NEW_VERSION}
git push --tags
After pushing the tag, create a GitHub release. Use awk to strip only the YAML frontmatter (first --- to second ---) from the changelog file:
