# Release Operator

> Run a CLI or app release: verify, version, test, publish, and verify installs.

- **Type:** Skill
- **Install:** `agentstack add skill-carlkibler-agent-skills-release-operator`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [carlkibler](https://agentstack.voostack.com/s/carlkibler)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [carlkibler](https://github.com/carlkibler)
- **Source:** https://github.com/carlkibler/agent-skills/tree/main/skills/release-operator

## Install

```sh
agentstack add skill-carlkibler-agent-skills-release-operator
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Release Operator

A release is not done when the commit is made. It is done when a fresh consumer can install/update and the remote host agrees.

Third-order stance: a release is a trust event with an exit door. Verify not just the happy path, but leakage, rollback, stale consumers, and the support email this version would generate if it went sideways.

## When to Use

- The user says release, deploy, publish, `cpd`, or "do that release"
- A packaged CLI/app needs version bump, changelog, tag, and verification
- A remote host such as `vesta` should validate the install/update path

## When NOT to Use

- Pure local prototype work with no publish surface
- The repo has its own release automation and the user only asked for a small code fix
- There are unreviewed failing tests that need debugging first

---

## Phase 1: Establish Release Facts

Read the repo instructions and existing release docs/scripts. Determine:

- current version and target version
- package manager / build tool
- release target: npm, GitHub release, app notarization, static deploy, etc.
- required changelog format
- whether install/update must be verified on a remote host

Run:

```bash
git status --short
git tag --list --sort=-version:refname | head
```

## Phase 2: Quality Gates

Run the repo's standard checks. For Node CLIs, default to:

```bash
npm run check
npm pack --dry-run
```

For packaged CLIs, inspect the dry-run tarball contents and confirm support scripts advertised by doctor/live checks are included.

Run a leak audit against the artifact list: no `.env`, tokens, local logs, private notes, nested `.git`, test-only fixtures advertised as live features, or generated files that encode local paths.

## Phase 3: Version and Changelog

- Move changelog entries from Unreleased to the target version/date.
- Bump package metadata and lockfiles together.
- Keep changelog user-facing, not just commit-shaped. Include changed trust semantics explicitly: install path, migration, telemetry/logging, permissions, reversibility, and support impact.

## Phase 4: Commit, Tag, Push, Publish

Use the repo's release script if present. Otherwise:

```bash
git add 
git commit -m "Release vX.Y.Z"
git tag vX.Y.Z
git push
git push origin vX.Y.Z
```

Then publish using the configured channel. Do not invent a publish command; inspect docs/scripts first.

## Phase 5: Post-release Verification

Verify the published artifact, not just the local checkout:

```bash
 --version
 doctor --smoke
 update
```

If a remote host was named:

```bash
ssh vesta ' update;  --version;  doctor --smoke'
```

Classify any warnings. Release blockers are install failure, wrong version, missing packaged files, broken smoke test, or stale remote config pointing at the wrong binary.

Do a rollback drill when feasible: confirm the previous version/tag can be reinstalled or the deployment can be rolled back. A release is only safe if the exit door opens.

## Phase 6: Report

Return concise evidence:

- version/tag published
- checks run
- package/publish verification
- local install/update result
- remote install/update result
- rollback/exit-door evidence, or why it was not applicable
- any follow-up issues filed

- Use `remote-host-verifier` for local/remote command comparison.
- Use `status-copy-trust-audit` before release when CLI status text changed.
- Use `changelog-writer` when changelog wording needs user-facing translation.
- Use `support-storm` or `status-copy-trust-audit` when the release changes setup, billing, permissions, status output, or failure modes.
- Use `remote-host-verifier` after release to catch stale package sources and hidden host drift.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [carlkibler](https://github.com/carlkibler)
- **Source:** [carlkibler/agent-skills](https://github.com/carlkibler/agent-skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** yes
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-carlkibler-agent-skills-release-operator
- Seller: https://agentstack.voostack.com/s/carlkibler
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.