/release-manager

name: release-manager
description: Govern the SemVer release process — versioning discipline, tag-based GitHub releases, changelog hygiene, and the ADR that confirms the release strategy is agreed. Trigger when setting up a release process, before a first public release, or when release practice has become inconsistent. Owned by delivery-orchestrator.

Release Manager

> **A release without a confirmed process is a deployment. A deployment without a rollback plan is a gamble.**

This skill governs the release process itself — not a specific deployment (that is `release-readiness`) and not the CI infrastructure (that is `github-manager`). It ensures the team has agreed, documented, and is consistently following a versioning and release strategy, anchored by an ADR.

When to use

• Setting up the release process for a new repository
• Before the first public or production release of a project
• When release practice has become inconsistent: manual uploads, skipped tags, changelog

gaps, or no named release owner

• As part of the bootstrap workflow, when the automation area is being defined
• When `delivery-orchestrator` identifies a release-process gap during R2/R3 classification

Operating model context

Three release-adjacent skills exist in this harness with distinct responsibilities:

| Skill | Responsibility | |---|---| | `github-manager` | CI trigger configuration, runner cost, branch protection, tag-event wiring | | `release-manager` (this skill) | Process governance: SemVer discipline, changelog, ADR, deviation authority | | `release-readiness` | Go/no-go gate for a specific deployment: failure modes, rollback, monitoring |

Use all three in sequence for a new project. Use `release-manager` alone when auditing or repairing an existing process. Always hand off to `release-readiness` before the tag is pushed.

Default release strategy

Unless a team ADR explicitly records a different approach, the default is:

• **Versioning**: Semantic Versioning — `MAJOR.MINOR.PATCH`
• `PATCH` — backwards-compatible bug fixes
• `MINOR` — backwards-compatible new capability
• `MAJOR` — breaking changes
• **Tagging**: `v{MAJOR}.{MINOR}.{PATCH}` tags on the default branch trigger release

builds in CI. No other event produces a release artifact.

• **Artifacts**: produced by CI from the tagged commit — never from a local workstation.
• **Changelog**: `CHANGELOG.md` updated before every release; format follows

[Keep a Changelog](https://keepachangelog.com/en/1.1.0/).

• **GitHub release**: created by the CI pipeline, linked to the tag, with the changelog

entry as its body.

• **Release authority**: the named release owner (recorded in the operating profile)

approves and pushes version tags. No one else pushes `v*` tags to the default branch.

• **Source of record**: this repository's issues, ADRs, and architecture docs are the

source of truth unless a team ADR explicitly records otherwise.

Procedure

1. Confirm or create the release ADR

An ADR must exist that records:

• The chosen versioning scheme (default: SemVer)
• The tagging convention and who holds release authority
• How hotfix or patch releases outside the normal cycle are handled
• Any deviations from the default strategy and the reason for them

If no ADR exists, create one using `the-architect`. The ADR is the authority record — process enforcement without one is informal and will drift.

2. Audit current practice against the ADR

Check the repository for evidence of adherence:

• Are version tags following the declared convention?
• Is `CHANGELOG.md` up to date for every tagged release?
• Are release artifacts produced by CI, not locally?
• Are GitHub releases linked to tags and changelog entries?
• Does a single named release owner control version-tag pushes to the default branch?

Flag every gap between declared ADR and observed practice. Gaps are findings, not acceptable workarounds.

3. Wire the release pipeline

Confirm the following are in place (coordinate with `github-manager` for CI config):

• A CI workflow triggers on `v*` tags
• The workflow produces and uploads the release artifact
• The workflow creates a GitHub release with the changelog entry as its body
• Branch protection prevents unauthorised pushes of `v*` tags

4. Define the release checklist

The release owner runs this checklist before every release:

• [ ] `CHANGELOG.md` entry written, reviewed, and committed
• [ ] Version identifier bumped in all manifests and committed
• [ ] `v{version}` tag pushed to the default branch
• [ ] CI release workflow completed and artifact verified
• [ ] GitHub release created and linked to tag and changelog
• [ ] Downstream consumers notified if the release contains breaking changes

5. Hand off to release-readiness

Once the release process confirms the candidate is ready to tag, invoke `release-readiness` for the go/no-go deployment gate. The release checklist above is an input to that gate, not a substitute for it.

Outputs

• Release ADR (or gap: ADR missing, with named owner and required-before trigger)
• Audit report: declared practice vs. observed practice, with gap list
• Wired release pipeline confirmation
• Release checklist for the team to own going forward

Guardrails

• **No release process without an ADR.** Conventions without a decision record drift.
• **Tags trigger releases; local builds do not.** A release artifact that cannot be

reproduced from a tag is not a release.

• **The changelog is not optional.** Every release without a changelog entry is invisible

to users and to future maintainers.

• **Release authority must be named.** Shared ownership of version tags is no ownership.
• **Deviations require an ADR amendment.** "We'll do it differently this time" is drift,

not a decision.

Anti-rationalization table

| Excuse | Counter | |---|---| | "We all know the release process" | Tribal knowledge drifts. An ADR does not. | | "The changelog is a nic