Prepare and operate repository releases through a finite, approval-gated hosted workflow. Use when the user asks to inspect release status, check setup, record component impact, create a generated release PR, plan or approve publication, dispatch post-release evidence, or prepare the OpenAI handoff.
Scanned 9/1/2026
Install to Claude Code
npx -y skills add stark-ai-de/agent-skills --skill release-manager --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Release Manager?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/stark-ai-de-release-manager)More formats (shields.io, HTML) on the badges page.
---
name: release-manager
description: Prepare and operate repository releases through a finite, approval-gated hosted workflow. Use when the user asks to inspect release status, check setup, record component impact, create a generated release PR, plan or approve publication, dispatch post-release evidence, or prepare the OpenAI handoff.
license: Apache-2.0
metadata:
internal: true
author: stark-ai-de
category: repo-maintenance
version: "0.2.0"
---
# Release Manager
## Goal
Prepare and operate a release through repository-owned hosted workflows without creating local tags or releases.
## When to use
- The user asks to prepare, review, or draft a release.
- Release setup, component impact, generated version PRs, protected publication,
evidence, or OpenAI handoff needs review or execution.
## 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 repository has no explicit hosted release contract; first inspect its native
instructions and ADRs.
## Inputs
- Requested command and its exact arguments.
- Repository release configuration, manifest, component versions, hosted runs,
release environment policy, and publication evidence.
## Inputs to inspect
- Inspect the repository-native `release:manage` surface before selecting a route.
- Check accepted ADRs, current branch/SHA, release history, component versions,
hosted validation, environment policy, and evidence by layer.
## Process
1. Select exactly one supported workflow from the finite set below.
2. Verify repository identity, protected state, and the requested command's authority.
3. Run the repository-owned command. Read-only commands need no mutation approval;
every hosted dispatch or approval must include `--confirm`.
4. Report local, hosted, publication, evidence, and portal state separately.
5. Stop at the next approval or manual portal boundary.
## Workflow
The complete workflow set is:
- `status` — read-only release and workflow state.
- `setup-check` — read-only App, secret, lifecycle-label, environment, branch,
and workflow preflight.
- `impact --kind patch|minor|breaking [--skill <name>]` — read-only component-impact guidance.
- `release-pr --confirm` — dispatch Release Please to create or update its draft PR.
- `publish-plan --confirm` — dispatch the read-only hosted publication plan.
- `publish --confirm` — dispatch protected publication and wait for environment approval.
- `approve --run-id <id> --confirm` — approve the waiting `release` environment deployment.
- `post-release --tag vX.Y.Z --confirm` — dispatch tag-bound evidence on protected `main`.
- `openai-handoff --tag vX.Y.Z` — read-only handoff checklist after verifying the latest three-asset release and a newer successful exact-tag Evidence run.
On a bare or materially ambiguous invocation, show this set and ask which outcome
the user wants. When intent and authority are clear, announce the selected route
and proceed.
## Decision points
- Feature PRs raise affected component versions; Release Please alone changes the
root manifest, package version, and release changelog section.
- `publish-plan` proves readiness only; `publish` additionally crosses the protected
environment boundary.
- Post-release evidence and OpenAI portal publication are distinct completion layers.
## Safety rules
- Never create a tag or GitHub Release locally.
- Never bypass `--confirm`, the hosted workflow, or the protected environment.
- Do not include secrets or private incident details in release notes.
- Do not claim hosted validation, publication, evidence, or portal completion unless
verified at that exact layer and revision.
- OpenAI upload and portal asset edits remain manual external actions unless the
user separately authorizes them.
## 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. Selected workflow and exact command
2. Current state by evidence layer
3. Result or blocker
4. Next approval/manual action
## Failure modes
- Missing App, secret, Release Please lifecycle labels, or environment
configuration blocks hosted mutations.
- A missing successful Validate run blocks publication.
- Mismatched or immutable release assets block without clobber.
- If portal state cannot be inspected, mark OpenAI completion as manual and unverified.
## Completion criteria
- The requested finite workflow completed at its own evidence layer.
- Every later hosted, publication, evidence, and portal boundary remains explicit.
- No local tag or release was created.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!