| name | feature-start-version-bump |
| description | Prompt for a semantic version bump before starting implementation of a new feature, fix, or change — whether tracked via OpenSpec or not. Use at the very start of a new unit of work, before making the first code edit, to decide if/how to bump the version with npm run release:prepare. Not for continuing already-started work or trivial one-line tweaks. |
| license | MIT |
Ask about a version bump before the first line of code is written for a new feature, fix, or change — regardless of whether it's tracked as an OpenSpec change or just a plain implementation request.
When this applies
- The user is asking to start building/implementing something new (a feature, fix, or OpenSpec change), and no code has been written for it yet in this conversation.
- An OpenSpec change is about to be applied for the first time (progress shows 0 tasks complete).
When this does NOT apply
- Continuing or resuming work already in progress (some code/tasks already done for this unit of work).
- Trivial one-off tweaks, typo fixes, or exploratory/throwaway edits that aren't a planned feature/change.
- This has already been asked once for this feature/change in the current conversation — don't ask twice.
Steps
-
Confirm this is genuinely the start of new implementation work (see above). If unsure, err on the side of asking.
-
Ask with the AskUserQuestion tool:
"Starting implementation of <feature/change name>. Want to bump the version now?"
Options:
- Minor (new feature) (Recommended) — new functionality, backwards compatible (
x.Y.0)
- Patch (fix/tweak) — backwards-compatible fix or small change (
x.y.Z)
- Major (breaking change) — incompatible API/behavior change (
X.0.0)
- Skip — don't bump now (e.g. bundling with other changes, or will do it later)
-
If the user picks patch/minor/major, run:
npm run release:prepare <type>
Do not append -- --commit. release:prepare intentionally leaves package.json/manifest.json unstaged so the version bump rides along with the feature commit rather than becoming a standalone commit (see openspec/specs/release-prepare-commit-flag/spec.md).
-
If the user picks Skip, continue without bumping.
-
Proceed with the implementation (or, if this was triggered from an OpenSpec apply flow, continue that flow's normal steps).
Guardrails
- Ask at most once per feature/change per conversation.
- Don't block on this — if the user is mid-flow and clearly wants to keep moving, ask once, then proceed regardless of their answer.
- This skill only decides whether/when to bump — it doesn't replace or duplicate OpenSpec's own change-tracking steps.
