# Changelog Slack Announcement

> 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.

- Skill: `warpdotdev/changelog-slack-announcement` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add warpdotdev/changelog-slack-announcement`
- Raw SKILL.md: https://api.skillmd.com/api/skills/warpdotdev/changelog-slack-announcement/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: warpdotdev (https://skillmd.com/u/warpdotdev)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/warpdotdev/changelog-slack-announcement

---


# Changelog Slack Announcement

Draft a short internal Slack announcement from the latest <BRAND> 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 <BRAND> release changelog entries, fetch channel metadata:

```bash
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:

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

and, for dev release changelog JSON:

```bash
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:

```bash
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:

```bash
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 <BRAND> (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

```text
<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.