---
title: OpenPlanr Release
description: Choose and maintain a product's versioning scheme, classify shipped changes, and write user-facing changelogs or release notes.
url: https://openplanr.dev/docs/skills/release
updated: 2026-10-06
related:
  - https://openplanr.dev/docs/skills/land.md
---

# OpenPlanr Release

Skill family: Land and release.

Pick the next version from what changed for users, and write release notes people can read. Release prepares everything locally and publishes only when you ask.

Choose and maintain a product's versioning scheme, classify shipped changes, and write user-facing changelogs or release notes. Use for SemVer or CalVer decisions, version bumps, release cadence, and preparing a versioned release after landing.

## Run it

- Claude Code: `/release`. If /release runs another command, use /planr:release.
- Codex: `$release`. With the OpenPlanr plugin for Codex, use $planr:release.
- Cursor: `@planr-release`. Cursor applies the planr-release rule when you mention it in chat.

## Use it to

- Choose the next SemVer or CalVer version and write user-facing release notes
- Set up or maintain a changelog, versioning scheme, and release cadence

## Not for

- Check whether unmerged work is ready to land without choosing a version
- Implement product code before release preparation

## Use instead

- [OpenPlanr Land](https://openplanr.dev/docs/skills/land.md)
- [OpenPlanr Ship](https://openplanr.dev/docs/skills/ship.md)

## Example prompt

Claude Code:

```text
/release Write user-facing release notes for everything since the last tag and update the changelog.
```

If /release runs another command, use /planr:release.

Codex:

```text
$release Write user-facing release notes for everything since the last tag and update the changelog.
```

With the OpenPlanr plugin for Codex, use $planr:release.

Cursor:

```text
@planr-release Write user-facing release notes for everything since the last tag and update the changelog.
```

Cursor applies the planr-release rule when you mention it in chat.

## Output

`CHANGELOG.md`:

```text
## [Unreleased]

## [1.4.0] - 2026-09-08

### Removed
- Entry, with the migration step inline.

### Added
- Entry.

### Changed
- Entry.

### Fixed
- Entry.
```

Release classifies every change by one question: does a user have to do, know, or expect something different now? That classification drives the version bump and the notes. A CLI or library that others install and pin follows SemVer strictly, and the scheme you agree on is saved in `.release/profile.md`, so later releases follow it instead of deciding again.

The notes lead with what users can now do, describe fixes by the symptom users saw, and leave internal work out. Release prepends the new section to `CHANGELOG.md`, bumps versions with your repository's release tool, and stops there: pushing tags, publishing packages, and deploying happen only when you ask.