release-manager v0.1.0A

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

---
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. Write the planned catalog release compared with the previous release; do not record intra-PR history or rewrite older changelog sections.
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.