Release Notes & Changelog Generator

What it does

/release is a Cursor slash command. Type it in chat to run a saved workflow: Release Notes & Changelog Generator.

Summarizes git commit history into customer-facing changelogs: categorizes features, bug fixes, and improvements with clear release notes.

Converts git commit histories into customer-facing changelogs. Unlike a skill, a command is something you invoke on purpose. The agent does not decide to run /release for you.

Why it exists

Founders retype the same multi-step prompt until it rots. /release exists so the pipeline, all 4 steps of it, is a file in .cursor/commands, versioned with the repo.

It ships in the Engineering Kit. It is wired to the API & Technical Documentation Writer (technical-writer) and Technical Lead & System Architect (tech-lead) agents. Required skills: Technical Documentation & OpenAPI Spec Design; Project Conventions & CURSOR.md Standards.

When to use it

• Use before deploying production updates to publish changelogs and release notes.
• Use /release when you want that pipeline, not a freeform chat. If you only need one step, use a narrower command or a single agent.
• Start a new chat. Do not run this command in a thread that just wrote marketing copy.

When not to use it

• Do not run /release as a substitute for reading the diff. The command produces files; you still gate them.
• Do not chain it into a 40-turn chat. Fresh context is part of the design.
• Do not run it if you have not filled CURSOR.md. The pipeline will invent a stack.

Example workflow

1. Parse git log since last semantic release tag
2. Categorize changes into Features, Enhancements, Bug Fixes, and Breaking Changes
3. Format customer-friendly descriptions highlighting user benefits
4. Update CHANGELOG.md and create GitHub Release announcement draft

Example usage

Type this in Cursor chat: /release Generate changelog for v2.4.0 release based on git commit history

The command file tells the session which agents to adopt and which skills to read. You should see phase headers, not a single dump of code.

If a phase fails its gate, stop. Do not add 'just continue'.

Example output

• Expected artifact: CHANGELOG.md
• Expected artifact: docs/releases/vX.X.X.md

Best practices

• Keep the prompt specific. /release Generate changelog for v2.4.0 release based on git commit history is the shape: object, constraint, and outcome.
• Let the listed agents work in order: technical-writer → tech-lead.
• Save outputs in the repo. Chat-only answers evaporate.
• Engineering commands should leave tests or an audit note, not only implementation files.

Common mistakes

• Typing /release with no object ('do the thing'). The pipeline will guess.
• Re-running the command in the same chat after a failed gate instead of fixing the failing file.
• Editing the command file to skip review so it 'goes faster'.
• Skipping the Technical Documentation & OpenAPI Spec Design skill that the command depends on.