Prepare Repository Release
Repository continuity composition
For repository-scoped work, compose maintain-repository-continuity in
Resume mode before selecting work. After an authorized repository change
passes domain validation, compose Refresh and Verify immediately before
presenting the pull request, and include the reconciled root CONTINUITY.md in
the same change. A policy-permitted no-change or exemption result must be
documented instead of fabricating an edit.
- Contribute: Version authority, release candidate, changelog plan, exact verification, limitations, and rollback
- Never claim: That a tag, release, package, image, site, or archive was published without external evidence
Create or review a repository release plan governed by repository-release.
This skill makes the release decision inspectable; it does not grant tag,
registry, deployment, signing, or archival authority.
Inspect first
Read the repository's .egohygiene/release.json, CHANGELOG.md, version
authority files, current immutable tags, and release workflow before proposing
a change. Treat commit messages as bump recommendations only. The declared
version authority and a reviewed release plan decide the version.
Use the declaration template for a new repository and authoring guidance for a migration. The packaged schema is authoritative for the declaration shape.
Plan and prepare
- Select one repository profile and record any independent components.
- Give every component exactly one version authority; do not synchronize conflicting files by guesswork.
- Keep
## [Unreleased]in the root changelog and draft the dated promoted release entry for human review. - State each delivery/evidence condition as configured, external, unavailable, or not-applicable. Do not imply external publication occurred.
- Record rollback instructions that preserve immutable tags and assets.
Validate a local candidate with the portable reference validator:
python3 "scripts/validate-release-declaration.py" \
--repository "." \
--release-version "v1.2.3" \
--format "json"
Handoff boundaries
Use release:plan, release:prepare, and release:verify to create and
check a reviewed candidate. release:publish hands off only an approved,
current-default-branch candidate to the repository-owned manual workflow.
Relay can preserve immutable GitHub Release evidence, but registry, container,
site, DOI, archive, and signing adapters remain separately authorized.
Never force-update an exact version tag, overwrite release assets, publish from an ordinary pull request, or treat missing external evidence as success.