release - Versioning Stage
Invariants
- Release only merged
Ready To Shiptasks. - Keep changelog entries user-focused.
- Do not include unmerged pull requests.
- Do not rewrite existing tags without explicit user approval.
Runtime adapters may expose this stage as a slash command, menu action, or natural-language skill invocation. The portable stage name is release.
Invocation
Supported version inputs:
autoor no argument: derive from taskVersion Impactpatchminormajor- explicit version such as
v1.2.3
Workflow
- Read
AGENTS.md. - Read
TASKS.mdand find merged items inReady To Ship. - Read each task document for type, version impact, and summary.
- Determine the next version.
- Generate or update
docs/changelogs/CHANGELOG.md. - Commit changelog changes if the repository workflow expects release commits.
- Create a git tag when appropriate.
- Create release notes using the available repository hosting tool when appropriate.
- Move released items to
ShippedinTASKS.md.
Version Calculation
| Signal | Version Impact |
|--------|----------------|
| Breaking change or required user migration | major |
| New feature | minor |
| Bug fix, docs, chore, small enhancement | patch |
Highest impact wins when multiple tasks are released together.
Changelog Template
## [v{version}] - {Date}
### New Features
- {User-facing feature}
### Fixes
- {Bug fix}
### Improvements
- {Enhancement}
### Documentation
- {Documentation update}
### Breaking Changes
- {Required migration, if any}
Handoff
Release prepared: v{version}
Tasks shipped: {IDs}
Changelog: docs/changelogs/CHANGELOG.md