← All craftbooks

Version Bump

Ship and releaseevalv1.1.1released 2026-09-01workflow: build-loop

Steps

Entry step: scope. Each step names the specialist role it wants; the full working prompt is expandable.

1. Scope the bumpplannerentry

   pick the semver level and enumerate every version-bearing file

   Show working prompt

   1. Read the change set since the last release (changelog Unreleased, merged PRs, git log) and decide the semver level: MAJOR for any breaking/incompatible change, MINOR for new backward-compatible functionality, PATCH for backward-compatible fixes only — state the deciding change. 2. Compute the exact new version string from the current one (find the current version first; respect any pre-release/build suffix convention). 3. Enumerate EVERY location that stamps the version: package manifest(s) (and workspace members if a monorepo), any VERSION constant in source, the lockfile, README/docs badges, and the changelog header. 4. Note any inter-package version constraints that must move together. 5. Good looks like: the chosen new version with a one-line semver justification and a complete, file-by-file list of every place that must change with its current and target value. Write this as an acceptance-criteria checklist ('semver level matches the change set', 'every version-bearing file is listed with old→new', 'monorepo/peer constraints accounted for', 'changelog header updated to the new version') plus the analysis to the notes file via write_task_note AND to {{workPath}}/scope.md.
   
   The deliverable `{{workPath}}/scope.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.

2. Apply the bumpdeveloper

   update every version location in lockstep

   Show working prompt

   1. Open {{workPath}}/scope.md and update the version string in EVERY enumerated location to the exact target value — do not eyeball one and miss another. 2. Update package manifest(s) and any workspace members, the source VERSION constant, the lockfile (regenerate if the tooling requires it), docs/badges, and the changelog header. 3. Keep any pre-release/build suffix convention intact. 4. Do not change anything unrelated to the version stamp. 5. After editing, grep the repo for the OLD version string to confirm no stray occurrence remains (except historical changelog entries, which are correct to leave). 6. Produce a manifest of what changed: for each file, the path and the old→new version, plus the result of the stale-version grep. 7. Good looks like: every location from scope.md now reads the new version, the old version survives only in historical changelog entries, and the manifest records each edit. Write the change manifest (JSON with one entry per file) to version-bump.json.
   
   Before working, open the artifact input `{{workPath}}/scope.md` with `read_artifact`; do not look for it in the workspace.

3. Verify consistencyreviewer

   confirm no location drifted and the bump is consistent

   Show working prompt

   1. Open version-bump.json and confirm every file from {{workPath}}/scope.md was bumped to the SAME target version — no drift between manifest, constant, lockfile, and docs. 2. Independently grep the repo for both the old and the new version strings: the new version should appear in every expected place; the old version should remain only in historical changelog entries. 3. Verify the semver level still matches the change set described in scope.md. 4. Confirm the changelog header was updated and nothing unrelated changed. 5. Write a PASS/FAIL per acceptance criterion with the grep evidence, and list any missed or inconsistent location. 6. Any failure routes back to the bump phase. Write findings to {{workPath}}/verify.md.
   
   Before working, open the artifact input `{{workPath}}/scope.md` with `read_artifact`; do not look for it in the workspace.
   
   The deliverable `{{workPath}}/verify.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.

4. Evaluatereviewer

   Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.

   Show working prompt

   Review `{{workPath}}/verify.md` against the original scope: every claim cites a real path, the severities and priorities are defensible, and nothing important in scope was skipped. Open the underlying files for at least the top findings; do not grade from the report's own summary. If a finding cannot be verified, say so explicitly.
   
   Write your review to the artifact `{{workPath}}/review.md` with one `write_artifact` call: what you checked, what held, what did not (as a findings table with columns `| Severity | File | Line | Problem | Fix |` when anything needs fixing), ending with exactly `Verdict: PASS` or `Verdict: REVISE`. The gate enforces the verdict: a well-formed REVISE is routed back to the `verify` step automatically with your findings. On PASS, `advance_task_step` to `finish`.

5. Finishdeveloper

   All acceptance criteria met. Stamp a short summary and report DONE.

   Show working prompt

   Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.

Triggers

Phrases that suggest this craftbook to a crew.

• bump the version
• release a new version
• set version to 2.0.0
• prepare a version tag
• semver bump

Source

View this craftbook on GitHub · MIT license