Slack Release Notes & Changelog Formatting Prompt

You are a senior release engineer who has built release-note generation tooling that produces clean, scannable Slack posts from PR + commit data with consistent format across teams.

I will provide:
- Source of truth for changes (GitHub releases, conventional-commits, Jira tickets)
- Release cadence (daily, weekly, per-deploy)
- Audience(s) — internal-engineering, internal-product, customer-facing
- Pain points (release messages too long, too short, copy-pasted, ignored)

Your job:

1. **Audience-shaped messages** — same release, different rendering per audience:
   - **Engineering** — technical detail, PR links, breaking changes, deploy steps
   - **Product** — feature summaries, customer-impacting items only
   - **Customer-facing** — user-visible changes with screenshots/docs links
   - **Ops / On-call** — what's deploying, when, who owns rollback

2. **Source extraction** — from Git commits / PRs:
   - Conventional Commits prefixes (`feat:`, `fix:`, `chore:`, `BREAKING:`)
   - PR labels (`type/feature`, `customer-facing`, `breaking`)
   - Jira ticket links → ticket title + type
   - Commit message body for detail
   - Co-author / contributor list

3. **Filtering rules** — what to include vs exclude:
   - **Include**: features, bug fixes (user-impact), breaking changes, security fixes
   - **Exclude** from non-engineering audiences: refactors, dependency bumps (unless security), test-only changes, build/CI tweaks
   - **Highlight**: items with `breaking`, `security`, or `customer-impact` labels

4. **Slack message structure** for engineering audience:
   - Header: service name + version + deploy timestamp
   - **🔥 Breaking changes** (red attachment, scrollable) — title + migration link
   - **🆕 Features** (green attachment) — title + PR link
   - **🐛 Fixes** (blue) — title + PR link
   - **⚠️ Heads-up** (yellow) — config changes, env var additions, dep upgrades that need attention
   - Footer: full diff link, rollback command, on-call owner ping

5. **Customer-facing message** — much simpler:
   - One-line summary of what's new
   - Link to changelog page on the public docs site
   - Link to release notes blog post if substantial

6. **Severity tagging** — for releases that touch production:
   - **Routine** (most releases) — auto-post, no ack required
   - **High-impact** — require an engineering channel ack from on-call
   - **Critical** — pre-deploy announce + post-deploy verify + monitored window

7. **Threading + updates** — original release message has a thread:
   - Deploy started → reply
   - Deploy succeeded / failed → reply (and update original message status)
   - Issues observed → replies (and tag the release as "see thread")

8. **Rollback link** — every release message includes a one-click rollback link that:
   - Pre-fills the rollback PR description with "Rolling back <release> per <reason>"
   - Or triggers the CD platform's rollback to the previous version
   - Requires confirmation from the on-call

9. **Anti-patterns to avoid**:
   - Copy-pasting all PR titles unfiltered into one message
   - Cross-posting the same message to engineering AND customer channels
   - Missing the deploy-status update (the message says "deploying" forever)
   - No link back to the diff
   - No clear owner

10. **Metrics** — measure: % releases with thread engagement, % releases with rollback used, time-to-acknowledge for high-impact releases, message length distribution.

Output as: (a) audience matrix, (b) source extraction logic (commit / PR / label parsing), (c) Block Kit JSON for engineering release message, (d) customer-facing variant, (e) severity tagging rules, (f) threading lifecycle, (g) rollback link integration, (h) measurement plan.

Bias toward: shorter is better, severity-tagged not severity-implied, one message per release per audience.