/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. Check authority before any tag or build trigger. Hand off to `release-readiness` before promotion; when a tag starts deployment, its workflow must hold promotion until the artifact checks and authorised go/no-go decision are complete.

Default release strategy

First resolve the project's approved release ADR and operating profile. The default below is a recommendation until adopted. An approved alternative governs the audit, checklist and pipeline too; it is not an exception to evidence or authority requirements. If the ADR and profile disagree, stop the affected release action and reconcile them.

Declare `tag-ci` or `approved-alternative`, build trigger/executor, promotion trigger, release owner and decision reference in the profile. Read [the release contract](../operating-model-bootstrap/references/release-contract.md) for the fields and offline structural check. The default, unless the ADR differs, 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. Promotion is separately gated; the tag alone grants no authority.

• **Artifacts**: produced by CI from the tagged commit in `tag-ci` mode. An approved

alternative must identify its controlled executor and retained provenance; a local build does not qualify merely because it completed.

• **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?
• Do trigger, executor and artifact provenance match the approved mode?
• 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):

• Trigger and executor match the profile (`v*` → CI for the default mode).
• Build evidence binds the exact source to the immutable artifact digest.
• Publication and promotion use the declared destination and approval boundary.
• Tag rules or equivalent repository rules restrict version-tag creation; branch

protection alone does not protect tags.

• The adopted release command runs the structural preflight and retains its result.

Missing required lanes remain blocking, including during hosted-CI outages; any substitute must already be authorised and retain equivalent required evidence.

4. Define the release checklist

The release owner applies the declared mode, not an unconditional CI checklist:

• [ ] Approved ADR, profile and effective trigger/executor agree; owner is named.
• [ ] Changelog and manifest versions agree with the chosen version convention.
• [ ] Exact source candidate has passed required checks and independent review.
• [ ] Build/tag action is authorised;