Slack Lightweight Change Approval (CAB-Lite) Prompt
Design a Slack-native change approval workflow — request card, approver routing, freeze-window enforcement, audit trail, and rollback hook — without the bureaucracy of a heavy CAB.
- Target user
- SRE / platform engineers replacing slow CAB processes with Slack-native flow
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior SRE who has replaced a 5-day-lead-time weekly CAB meeting with a Slack-native change-approval flow that maintains audit + freeze-window compliance with sub-1-hour approval times.
I will provide:
- Existing change-management process (ServiceNow CAB / weekly meeting / nothing)
- Compliance requirements (SOX, ISO 20000)
- Risk taxonomy (low / medium / high / emergency)
- Approver groups
- Freeze windows (e.g. holidays, peak season)
Your job:
1. **Why Slack-native instead of ServiceNow CAB**:
- Lower lead time
- Approver context-switching reduced
- Discussion happens with the request, not in a parallel meeting
- Audit-trail still possible via Slack export + ServiceNow record
2. **Risk classification first** — not every change needs the same gate:
- **Low** (most config / version bumps) — peer review on PR is sufficient
- **Medium** (prod deploys, dependency updates) — 1 approver from approval group
- **High** (DB migrations, IAM changes, large refactors) — 2 approvers + service owner
- **Emergency** (incident-driven) — fast track with retroactive review
3. **Request format** — Block Kit modal opened by `/change <service>`:
- **Title** — one-line
- **Service / Component**
- **Environment** — radio: dev / staging / prod
- **Risk class** — radio: low / med / high / emergency (with definitions)
- **What's changing** — text
- **Why now** — text
- **Validation plan** — text
- **Rollback plan** — text (required for high risk)
- **Blast radius** — text
- **Customer impact** — boolean + text if yes
- **Linked PR / RFC** — required
4. **Routing rules**:
- Low → auto-approve, post to change log
- Medium → DM service owner + post to `#change-approvals`
- High → DM 2 approvers + post + require 2 thumbs-up reactions before proceeding
- Emergency → notify but proceed; require retroactive write-up within 24h
5. **Freeze windows**:
- Configurable: dates, time of day, environment
- Apply rule: during freeze, only emergency allowed; require additional approver + IC sign-off
- Pre-freeze warning: 1 week, 1 day, 1 hour before, post to `#change-approvals`
- Post-freeze announcement
6. **Approval workflow**:
- Approver clicks Approve / Reject in the message
- Approval logged with timestamp + approver oid
- Reject requires comment ("blocked because X")
- On approval: post to `#change-approvals` + post to service channel + notify requester
- On reject: post + notify requester
7. **Audit log** — every request includes:
- Requester
- Risk class (and any auto-routing decisions)
- Approvers + decisions + timestamps + comments
- Final outcome (approved / rejected / withdrawn)
- Implementation timestamp (from CI integration)
- Outcome (success / partial / rolled back)
8. **Rollback hook** — when a change is approved, log the rollback procedure. On post-deploy issues:
- One-click "Initiate rollback" button in the request thread
- Triggers the documented rollback procedure
- Posts result back to the thread + change record
9. **Integration with CI**:
- CI checks for an approved change request before deploying to prod
- PR-to-request linking — the PR carries a change ID; CI fetches the request, verifies status
- If approval expires before deploy (e.g. > 24h), require re-approval
10. **Anti-patterns to avoid**:
- Slack-native means "no audit" (false — capture everything)
- Skipping freeze window for "trivial" changes
- Approvers rubber-stamping (require comment for non-trivial)
- Lost in DM (require channel post for high risk)
- Approval that doesn't gate CI (still possible to bypass)
Output as: (a) risk-class taxonomy with examples, (b) Block Kit modal JSON, (c) routing rule matrix, (d) freeze window policy, (e) approval workflow + audit schema, (f) CI integration design, (g) rollback hook, (h) auditor-evidence checklist.
Bias toward: speed of approval without losing audit, risk-tiered approval, every change is traceable, freeze-windows are honored not winked-at.