Release a milestone¶
This page explains how to close a fully implemented and verified Milestone as one release. SpecBind releases the whole Milestone or none of it; it does not release only a subset of participating Specs.
When to release¶
Before starting:
- every participating Spec has completed implementation and
sb-validate-implementation, and the CLI has accepted its completion evidence; and - you have decided to publish this Milestone.
For an initial trial, you may stop after implementation validation and begin a new Milestone later instead of exercising release immediately.
1. Establish the release policy¶
Project-specific Prepare, Publish, Verify, and cleanup instructions live as
natural language in .specbind/settings/adapters/release.md.
- If the adapter is still a scaffold,
sb-releaseinvestigates release workflows, version manifests, build scripts, and release documentation and proposes concrete instructions. After approval it saves and locally commits onlyrelease.md, then stops without binding or publishing a version. - Changing
release.mdis an ordinary project change and makes accepted completion evidence stale. Revalidate completion before running release again. - If no project-specific work is required, retain the Front Matter and leave the body empty to state that explicitly.
See Customize SpecBind for adapter ownership and editing.
2. Run sb-release¶
The Skill orchestrates the flow from release binding through finalization, while all lifecycle state changes go through the CLI. You confirm each external or otherwise significant boundary.
Bind the release¶
Release labels are opaque and case-sensitive: v1.4.0 and 1.4.0 are
different values. The Skill never invents the value. Binding only
target_release, including an explicit rebind, preserves completion freshness.
Changing Roadmap scope, body text, or project version files at the same time
does not receive that exception.
The bound Roadmap is a normal Git change. The Skill follows the Git adapter and checkpoints that file before preflight. You may also bind ahead of time:
Preflight, Prepare, Publish, and Verify¶
After preflight succeeds, the Skill follows the adapter in order:
- Prepare is repeatable and local. A failure stops before anything is published.
- Publish fixes the release identity or crosses an external boundary. The Skill states the exact action and version and asks for confirmation even when the original request was broad.
- Verify obtains fresh evidence that the intended version is actually published and usable. Re-reading the publish command output is insufficient. If no independent verification is possible, the result is unverified, not successful.
If publishing succeeds but verification fails, the Milestone remains active and SpecBind artifacts remain intact. The workflow reports the state and asks how to proceed rather than rolling back or retrying blindly.
Finalize¶
After verification, the Skill summarizes what each participating Spec actually
delivered and asks the CLI to finalize the whole Milestone. The CLI owns the
structured log.md update; do not edit it in advance. Finalization is retry-safe
and does not duplicate history.
3. After finalization¶
- The Roadmap moves to the release archive, while durable Specs remain and return to idle state.
- Each Spec's
log.mdreceives the Milestone record. - The Milestone closes and the next
sb-discoverymay start another. - When configured, the Git adapter checkpoints finalization metadata separately from the published product revision.
If the Milestone added a Spec, changed a Contract, or released before any
Steering existed, run sb-steering once. Steering is freely editable
again after finalization.
Inspect readiness directly¶
Both commands are read-only: