Release notes

Release notes

Invocation: user only.

Workflow

1. Scope the release

From $ARGUMENTS, extract the version tag or date range. If GitHub MCP is connected, map version → PR set. Otherwise ask the user for either:

• A list of merged PR numbers
• A Notion release page with the ship list
• A date range, and we'll pull from both Slack #ship and Notion

2. Gather changes

In parallel:

• GitHub (if enabled): PRs merged in the window, titles, labels, linked issues.
• Notion: the release page if one exists, any spec pages marked shipped in this window.
• Slack: #ship or equivalent channel messages in the window — often has context PRs don't capture.

3. Filter

Discard from the release-notes draft:

• Internal-only changes (infra, CI, tests, internal tools) — if a customer can't see or feel it, it doesn't belong
• Bugfixes of bugs that never hit production
• Refactors with no behavior change

Keep everything that changes what a user sees, does, or gets.

4. Group and write

Group by user-visible theme, not by team. Typical buckets:

• New — new capability or surface area
• Improved — existing things that work better
• Fixed — bugs customers reported or would have hit

Writing rules:

• One line per item. If you need two lines, the item is too big — split or expand into a blog-post intro.
• Lead with the user outcome, not the feature. "Find past meetings in 2 clicks" beats "Added search to meeting history page."
• Link to deeper docs when available, don't inline them.
• No internal codenames.
• No "we" if it can be avoided — users care what changed, not who did it.

5. Output

# <Product name> <version> — <date>

<One-paragraph intro. What's the theme of the release?>

## New
- <item> — <link if any>

## Improved
- <item>

## Fixed
- <item>

---

<Optional: "What's next" tease — only if the user has a specific next thing to point to.>

6. Confirm before publishing

Ask the user where these go:

• Blog post (draft a Notion page, don't publish)
• In-app changelog (draft, don't push)
• Email to customers (draft, don't send — use /team-core:draft-email flow)
• Slack announcement (draft, don't post)

Offer to produce a 200-char version for social/email subject line.

Don't

• Don't mix audiences. Customer notes ≠ internal ship log.
• Don't include metric improvements unless the customer can verify them independently ("40% faster" without context is noise).
• Don't publish anywhere without explicit approval.