release-manager v0.1.0A

Immutable. This exact content never changes and is served at /api/v1/blob/a982482c58ce45f4.

---
name: release-manager
description: Prepare repository releases. Use when the user asks to draft release notes, update changelog, check semver, verify CI, create a release checklist, or decide whether a public repo is ready to tag and publish.
license: Apache-2.0
metadata:
  internal: true
  author: stark-ai-de
  category: repo-maintenance
  version: "0.1.0"
---

# Release Manager

## Goal

Prepare a release with clear versioning, changelog coverage, validation status, release notes, and approval gates before any irreversible publish action.

## When to use

- The user asks to prepare, review, or draft a release.
- A changelog, semver bump, tag, or release note needs review.
- CI and package readiness need preflight checks.

## When not to use

- The user wants a PR review before merge; use `pr-review`.
- The user wants a repository-wide maintenance audit; use `repo-health-audit`.
- The user asks to publish immediately but version, changelog, or validation state is unknown.

## Inputs

- Changelog, package manifests, tags, commits since last release, and merged PRs.
- CI status, test results, docs changes, migration notes, and breaking-change signals.
- Publishing workflow and maintainer approval policy.

## Inputs to inspect

- Inspect release history, current version, changelog, package metadata, CI state, and validation output.
- Check docs or migration notes for user-facing changes.

## Process

1. Identify the last release and changes since then.
2. Classify changes as added, changed, fixed, deprecated, removed, or security.
3. Recommend a semver bump with reasoning.
4. Check changelog, docs, CI, package metadata, and release workflow.
5. Draft release notes and a preflight checklist.
6. Ask for explicit approval before tagging, pushing, publishing, or creating a release.

## Workflow

Follow the process above, then stop at a release-ready draft unless the user explicitly approves tag, push, publish, or release creation.

## Decision points

- Breaking changes require major version notes or explicit migration instructions.
- Security fixes require careful disclosure language.
- Failed or missing CI blocks release readiness unless the maintainer accepts risk.

## Safety rules

- Do not tag, publish, push, or create releases without explicit approval.
- Do not include secrets or private incident details in release notes.
- Do not claim CI passed unless verified.

## References

Read only when needed:

- `references/release-checklist.md` for preflight.
- `references/changelog-template.md` for changelog entries.

## Scripts

No bundled scripts.

## Output format

Return:

1. Release readiness verdict
2. Recommended version bump
3. Changelog draft
4. Release notes draft
5. Preflight checklist
6. Approval needed

## Failure modes

- If the previous release cannot be identified, say which tags or versions were inspected.
- If CI cannot be checked, mark release readiness as unverified.
- If the changelog and commits disagree, block release readiness until reconciled.

## Completion criteria

- Version, changelog, validation status, and risks are explicit.
- Release notes are ready for maintainer editing.
- Irreversible actions are gated behind approval.