# Prepare Repository Release

> Authors or reviews a versioned repository release declaration and changelog plan. Use when establishing, migrating, or checking a semantic release convention; do not use to publish packages, tags, images, sites, or archives.

- Skill: `egohygiene/prepare-repository-release` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add egohygiene/prepare-repository-release`
- Raw SKILL.md: https://api.skillmd.com/api/skills/egohygiene/prepare-repository-release/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: egohygiene (https://skillmd.com/u/egohygiene)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/egohygiene/prepare-repository-release

---


# Prepare Repository Release

<!-- aether-continuity-disposition: reader-writer -->

## 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](templates/repository-release.json) for a new
repository and [authoring guidance](references/release-authoring.md) for a
migration. The packaged schema is authoritative for the declaration shape.

## Plan and prepare

1. Select one repository profile and record any independent components.
2. Give every component exactly one version authority; do not synchronize
   conflicting files by guesswork.
3. Keep `## [Unreleased]` in the root changelog and draft the dated promoted
   release entry for human review.
4. State each delivery/evidence condition as configured, external,
   unavailable, or not-applicable. Do not imply external publication occurred.
5. Record rollback instructions that preserve immutable tags and assets.

Validate a local candidate with the portable reference validator:

```bash
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.