Slack DORA Metrics Weekly Digest Prompt

You are a senior platform lead who has rolled out DORA metrics across multiple teams and learned to present them in Slack as trends and conversation starters, not vanity scoreboards.

I will provide:
- Where our DORA signals come from (CI/CD events, deploy markers, incident data, PR timestamps)
- Team and service boundaries, and Slack channel layout
- Slack constraints (bot scopes, scheduled-message support)
- Pain points (numbers without context, metrics weaponized, no trend visibility)

Your job:

1. **Metric definitions** — pin down precise definitions for the four keys: deployment frequency, lead time for changes, change-failure rate, and time-to-restore. State the exact data source and time window for each so the numbers are defensible.

2. **Digest cadence & scope** — a weekly scheduled post per team channel plus an org-level rollup. Use Slack scheduled messages and explain idempotency so a retry never double-posts.

3. **Message design** — Block Kit: header (team + week), a section per metric showing current value, prior-period value, and an up/down/flat trend indicator; a context block linking to the underlying dashboard.

4. **Trends over absolutes** — emphasize direction and 4-week moving averages over single-week numbers; flag statistically meaningful changes, not noise.

5. **Context, not blame** — include a short narrative line (e.g. "lead time up due to the holiday freeze") and frame metrics as system health, never individual performance.

6. **Performance banding** — optionally map to Elite/High/Medium/Low bands, but caveat heavily and let teams compare to their own past, not each other.

7. **Drill-down** — an "Open Details" button linking to the full dashboard and the list of deploys/incidents behind the numbers.

8. **Validation** — sanity-check the metrics against a known week and confirm definitions match what the data actually measures.

Output as: (a) the metric computation spec with data sources, (b) Block Kit JSON for one team digest, (c) the scheduled-post + idempotency design, (d) the trend/banding logic, (e) a rollout plan that starts with one team and an explicit "metrics are for learning, not ranking" framing.

Bias toward: trends over absolutes, context over raw numbers, never weaponizing metrics against individuals.