Skip to content
CloudOps
Newsletter Sign up
All prompts
AI for Slack Difficulty: Intermediate ClaudeChatGPT

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

Free: the DevOps AI Incident-Triage Cheat Sheet

Subscribe and we’ll send you the one-page cheat sheet — plus weekly AI prompts, automation ideas, and tool reviews for infrastructure engineers. One email a week. No spam, unsubscribe anytime.

  • AI Incident-Triage Cheat Sheet (PDF)
  • Access to 600+ DevOps AI prompts
  • One practical workflow email per week