changelog-slack-announcement

name

changelog-slack-announcement

description

Draft concise, Slack-ready internal announcement messages from the latest <BRAND> changelog, focused on major shipped features and verified external-contributor highlights. Use this when the user asks for a changelog announcement, weekly shipped summary, internal Slack launch/update post, external community contribution highlights, or asks to turn recent <BRAND> changelog entries into a short message for Slack.

Changelog Slack Announcement

Draft a short internal Slack announcement from the latest changelog. The goal is not to reproduce the changelog; it is to pick the few most meaningful stories from the last 7 days and make them easy for teammates to copy into Slack.

Voice

Voice should be excited, but informative. No em dashes.

Default output

Return only the Slack-ready message unless the user asks for analysis. Keep it concise:

• Opening line that describes the headlining feature.
• A short intro line or header like "Here's what launched:" followed by 2-3 product bullets. The first bullet covers the headliner; the rest cover other notable features.
• 2-3 verified external-contributor highlight bullets.
• Closing line with build.your-brand.example.

Use normal Markdown-ish Slack formatting that survives manual copy/paste:

• Use - or • bullets.
• Use backticks for GitHub handles and slash commands: @handle, /feedback.
• Use bare PR URLs, not Slack API link syntax.
• Put multiple PR links inline after the sentence when that is more compact: ... fixes: https://github.com/your-org/your-repo/pull/<PR_ID>, https://github.com/your-org/your-repo/pull/<PR_ID>
• Avoid <url|label> links unless the user is posting through Slack API or Block Kit.

Inputs

Optional:

• Lookback window — default 7 days.
• Channel/version — default latest stable changelog, with recent dev entries allowed only if the user explicitly asks.
• Style reference — a pasted prior Slack message or user edits in the conversation.
• Community focus — contributor names, themes, or specific PRs to emphasize.

Clarify only if the timeframe or audience is ambiguous enough that it changes the result. Otherwise use the defaults and proceed.

Source data

Prefer generated release changelog data over guessing from commit history. For release changelog entries, fetch channel metadata:

python3 - <<'PY'
import json, urllib.request
data = json.load(urllib.request.urlopen('https://app.your-brand.example/client_version?include_changelogs=true', timeout=10))
print(data['stable']['version'])
print(json.dumps(data['changelogs']['stable'][data['stable']['version']], indent=2))
PY

If the user asks for a non-stable or very recent dev-only summary, inspect the relevant release artifacts:

gh release list --repo your-org/your-repo --limit 10

and, for dev release changelog JSON:

python3 - <<'PY'
import urllib.request
tag = 'v0.YYYY.MM.DD.HH.MM.dev_00'
print(urllib.request.urlopen(f'https://storage.googleapis.com/your-releases-bucket/dev/{tag}/changelog.json', timeout=10).read().decode())
PY

For the community section, only use merged PRs explicitly labeled external-contributor; do not infer external status from GitHub handles, memory, or author names. Search GitHub first:

gh search prs --repo your-org/your-repo --merged --label external-contributor --sort updated --order desc --limit 30 --json number,title,author,url,closedAt,labels

For PR links behind product entries or specific changelog phrases, use exact phrase search when needed:

gh search prs "some changelog phrase" --repo your-org/your-repo --json number,title,author,url,closedAt --limit 5

Selection rules

Product highlights

Pick only major, user-visible themes. Do not highlight tiny features just because they are new.

Good candidates:

• Meaningfully improves a core product area or a common workflow.
• Meaningfully fixes long-standing issues in (performance, platform support, reliability).
• Makes a workflow possible that was previously awkward or impossible.
• Ties to a current product narrative the team cares about. Use our roadmap: https://github.com/your-org/your-repo/issues/<ISSUE_ID>

Usually skip:

• Small slash commands or shortcuts unless they support a larger story.
• Narrow bug fixes in the product section.
• Internal refactors, telemetry, CI, tooling, or release mechanics.
• Long lists of unrelated fixes.

Bug fixes

By default, do not include a dedicated bug-fix highlights section. Mention bug fixes only if:

• The user explicitly asks for bugs.
• There is a major security, crash, or widely reported stability fix.
• The bug-fix theme is part of the community story.

Community highlights

Highlight external community work as a story, not a directory listing. Prefer 2-3 bullets:

• One standout contributor or theme.
• One integration/ecosystem theme.
• One platform-quality or reliability theme.

Handle formatting:

• Named contributor bullets (starred individuals): use backticks — @contributor_a, @contributor_b
• Aggregate "contributions from" list at the end of the community section: plain @handle without backticks is fine there, since it reads as a list rather than a direct mention.

Headliner pattern

Pick the single most interesting shipped thing and name it in the opener. The opener should be a short, direct line that calls it out.

Good headliners:

• A new interaction model (queueing, a new mode, a workflow change)
• A long-awaited capability that was previously impossible
• Something that visibly changes the daily loop for most users

Not headliners:

• Internal plumbing, telemetry, or config changes
• A bug fix, unless it's a major crash or security issue
• A narrow improvement to a rarely-used surface

Closers

End with a short line pointing to build.your-brand.example. Use your judgment on the exact wording — keep it human and direct.

Style

Match this tone:

• Direct and human.
• Short enough to read quickly in Slack.
• Specific, but not a changelog dump.
• Excited without sounding like marketing copy.

Avoid:

• "Major bugs were landed" phrasing; say "fixes landed" if needed.
• Over-explaining implementation details.
• More than 5 total bullets unless the user asks for a comprehensive post.
• Dense PR link formatting that will not paste into Slack.

Template

<opener that names the headliner>

<line introducing everything that launched>
- <headliner bullet with enough detail to be useful>
- <second notable feature>
- <third notable feature, if there is one>

<something about the community. `/changelog` has the full list of changes>

- `@github-handle` <external-contributor highlight with PR URLs inline>: <url>, <url>
- `@github-handle` <external-contributor highlight with PR URLs inline>: <url>, <url>
- External contributors tightened <theme>, with contributions from `@handle`, `@handle`, and `@handle`.

<closer asking to track community progress on build.your-brand.example>

When using GitHub handles, always use backticks. @contributor_a, not @contributor_a.