bump-version

Files (1)

• SKILL.md

SKILL.md (first lines)

# Bump Version Workflow

Use this skill when preparing a version bump for the project. The repository's current
release flow is defined in `AGENTS.md`; this skill only covers choosing the bump,
updating version files, and running the baseline validations that make the version-bump
change ready for normal review. Do not duplicate commit, tag, push, or pull workflow
steps here.

## Workflow

1. **Version Selection**

   - Use the version or bump already specified by the user, including an accepted
     decision from earlier in the session. Otherwise select a bump using the release
     pattern below. Ask only when the release intent cannot be inferred from the change
     and session context.
   - Use the current repository release pattern when advising:
     - Prefer `patch` by default for fixes, small UX improvements, refactors, docs
       updates, model/config changes, and other incremental work within the current
       `0.y` line.
     - Use `minor` for milestone cuts: new top-level workflows, pages, modes, or
       cross-cutting runtime/protocol changes that feel like a new product phase.
     - Treat this as a pragmatic pre-`1.0` policy. The changelog history shows patch
       releases may still include additive features or removals while the project
       remains below `1.0.0`.
   - When the change is not clearly milestone-sized, select `patch`.

1. **Version Bump**

   - Update `[workspace.package].version` and every versioned internal path dependency
     under `[workspace.dependencies]` in the root `Cargo.toml` to the selected version.
     Leave unrelated external dependency versions alone.
   - Update `Cargo.lock` and any generated metadata affected by the bump. Check that no
     internal workspace dependency still pins the previous version.

1. **Changelog**

   - Update `CHANGELOG.md`.
   - Resolve the current date in Pacific time before writing the changelog date
     (`TZ=America/Los_Angeles date +%F`), so late-day release work follows the
     repository's PST/PDT release calendar.
   - Ensure there is an entry for the new version with the Pacific date:
     `## [vX.Y.Z] - YYYY-MM-DD`.
   - Ensure content adheres to [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
   - Add a `### Contributors` section under the new release entry with a bullet list of
     GitHub usernames (example: `- @minev-dev`).
   - Build the contributor list from commits since the previous tag and deduplicate
     names.

1. **Base Validation**

   - Run the baseline repository validations from the `prek` hook catalog in
     `.pre-commit-config.yaml`:
     - `prek run --all-files`
     - `prek run test-workspace --all-files --hook-stage manual`
   - If validation fails, fix the underlying issue and rerun the failing hook before
     handoff.

From agentty-xyz/agentty, Apache-2.0.

More from agentty-xyz/agentty