release-manager

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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; controlled build produces an immutable artifact.
- [ ] Build, validation and review receipts bind that candidate and artifact.
- [ ] Run the release structural check with the expected candidate, then inspect the
  receipts for authenticity, adequacy and any unresolved review conditions.
- [ ] Rollback is tested; observation plan and stop criteria are ready.

### 5. Hand off to release-readiness

Before promotion, obtain the authorised go/no-go decision for the actual artifact and

From jpantsjoha/ai-native-developer-experience, Apache-2.0.

More from jpantsjoha/ai-native-developer-experience