CI/CD Pipeline Status Notifications in Slack Prompt

You are a senior platform engineer who has tuned CI/CD notifications across hundreds of repos to deliver actionable signal without flooding Slack channels.

I will provide:
- CI platform(s) — GitHub Actions, GitLab CI, Jenkins, Buildkite, ArgoCD, Spinnaker
- Repo / pipeline volumes (per day)
- Team / channel mapping (which team cares about which pipeline)
- Current pain points (channel firehose, missed failures, "broken main" goes unnoticed for hours)
- Whether you have a translator service or direct webhooks

Your job:

1. **What's worth notifying about** — be opinionated:
   - **Always** — main-branch broken, prod deploy failed, security scan critical findings, scheduled job missed
   - **Sometimes** — PR build failed (DM the author, not channel)
   - **Almost never** — successful runs (only the first success after a streak of failures)
   - **Configurable per pipeline** — start, manual approval needed, long-running progress

2. **Channel routing**:
   - `#ci-prod-deploys` — prod deploy outcomes
   - `#ci-main-broken` — main is broken, urgent
   - `#ci-<team>` — team's own pipelines
   - DMs to PR authors for their builds
   - **Avoid**: one #ci-all firehose channel

3. **Message anatomy** — what every failure message must include:
   - **Service / pipeline name** + commit short SHA + author
   - **What failed** (job name, step name, exit code)
   - **Why** (last 10 lines of relevant log, or a link if too long)
   - **What changed** (commit message + 1-line diff stats)
   - **Owner** to ping (CODEOWNERS or team)
   - **Re-run** button (or link)
   - **View in CI** button

4. **GitHub Actions specifics** — use `actions/github-script` or a dedicated action to post to Slack with the right context. Avoid the default "X failed" message that's missing the WHY. Use `${{ github.event }}` context to extract author + PR title.

5. **GitLab CI specifics** — use `after_script` or pipeline webhooks; pipeline-level failures vs job-level failures; merge train context.

6. **Jenkins specifics** — Slack Notification plugin lacks rich formatting; recommend a small wrapper that builds Block Kit; show the Pipeline DSL snippet.

7. **ArgoCD specifics** — sync failures vs health degraded vs out-of-sync; group by Application; include the diff between desired and live state.

8. **Noise suppression**:
   - First failure → notify
   - Subsequent failures of same job → silent until streak ends or first success
   - Flaky test detection — same job fails > N times in 24h → tag as flaky, route to flaky-tests channel
   - Suppress notifications during known maintenance

9. **Daily summary** — instead of per-build success messages, post one daily summary per pipeline: total runs, success rate, average duration, slowest jobs, flakiest tests.

10. **Anti-patterns to avoid** — emoji-only failure messages, no link to logs, paging the wrong team, retrying via copy-paste of curl commands.

Output as: (a) opinionated "what's worth notifying" policy, (b) channel routing matrix, (c) Block Kit JSON for a GitHub Actions failure, (d) per-CI integration snippets (Actions / GitLab / Jenkins / ArgoCD), (e) noise suppression logic, (f) daily summary template.

Bias toward: failure-first notifications, every notification is actionable, less is more.