Draft client-facing release notes from a Requivo session's model, in this Claude session, and save them as a tracked artifact. Use when the user wants an announcement a non-technical stakeholder can read to understand what they are getting.
Installs into .claude/skills of the current project.
Are you the author of Release?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/jbkkz-release)
---
name: release
description: Draft client-facing release notes from a Requivo session's model, in this Claude session, and save them as a tracked artifact. Use when the user wants an announcement a non-technical stakeholder can read to understand what they are getting.
allowed-tools: Bash(requivo doctor:*), Bash(requivo model show:*), Bash(requivo status:*), Bash(requivo artifact save:*), Read
---
# /requivo:release
Write **release notes** — client-facing, for a non-technical stakeholder to understand what they're
getting and why it matters. Not a changelog, not a spec. **You** write it; Requivo tracks the
document. This mirrors `src/requivo/assets/prompts/release.md` and the `ReleaseNotes` contract in
`core/contracts.py`, at commit `969cfd9` — the same rules the CLI's `requivo release` gives its own
reasoning call, restated here because the plugin cannot import that file at runtime (`decision:
plugin-skills-mirror-a-pinned-cli-commit`). Read `${CLAUDE_PLUGIN_ROOT}/REASONING.md` unless you already hold it from an earlier
`/requivo:*` in this conversation — and read it again whenever you are unsure you still do.
## 0. Preflight
Run the shared **preflight** from REASONING.md before anything else: `requivo doctor --json`, checking
whether the command ran *at all* rather than what it reported. If it could not run, the `requivo` CLI
is not installed — follow REASONING.md's missing-CLI flow. Nothing has been saved at this
point, so there is no half-written release note to find.
## 1. Load the model
```
requivo model show <slug>
requivo status <slug> --json
```
Note the `revision` — call it `N`. It is the model these notes will rest on, and you will state it
when you save.
## 2. Reason → write the notes
- `title`: the feature name as a user would recognise it. Leave `version` for the caller to add later
unless the model states one.
- `summary`: 2–3 sentences, plain language — what is now possible that wasn't before. Lead with the
user outcome, not the mechanism.
- `highlights`: headline capabilities, each phrased as something the user can now *do* ("Submit a
leave request in a few clicks", not "Implemented request submission endpoint"). Concrete,
benefit-led.
- `known_limitations`: what this release does **not** yet cover — pulled from the deferred or
uncertain parts of the model. Honest but neutral; it manages expectations, it doesn't apologise.
- `notes`: anything a stakeholder must act on or be aware of (a permission to grant, a one-time setup,
a configuration choice). Omit if the model implies none.
- Never invent a capability the model doesn't support. One resting on a proposal nobody confirmed
(`proposed:` evidence) is not announced as delivered: it is a choice to confirm under *Before you
start*.
**Voice.** This is the most client-facing artifact — write like a PM announcing a feature to a client.
**Never** expose internals: no slot ids, completeness percentages, confidence labels
(explicit/inferred/empty), or dev jargon (endpoint, schema, migration, backend). Warm, clear, concrete.
**Language.** Release notes anchor English whatever language the request arrived in — they feed the
same build/announcement chain as the other saved artifacts, unlike the mirrored conversation
(`docs/requirements-model.md`, *The language of the outputs*).
Write it as Markdown:
```
# <title>
> Release notes — generated by Requivo
<summary>
## What's new
- <highlight>
## Not included yet
- <known limitation>
## Before you start
- <note>
```
## 3. Save it as a tracked artifact
```
requivo artifact save <slug> --type release --file - --revision N --json
```
`--revision N` is the revision you read in step 1. Read `stale` back from the save output: if it is
`true`, the model moved while you were writing — say so plainly and offer to redo it.
## 4. Point at the next step, once
Release notes are usually the last document in the set: once they read right, `/requivo:status <slug>`
shows the whole set's freshness at a glance. If the scope changed since, `/requivo:run <slug>` is
where that goes back into the model first.