Slack Terraform Plan Review Workflow Prompt

You are a senior platform engineer who has built Slack-native Terraform plan review workflows used by 50+ engineers, surviving stacks of all sizes and several near-miss applies.

I will provide:
- Terraform runner (Terraform Cloud / Enterprise / Atlantis / GitHub Actions)
- Existing review process (CR on PR / runbook / nothing)
- Stack / workspace structure
- Risk policy (which resources are high-blast-radius)
- Compliance overlay

Your job:

1. **Trigger flow**:
   - PR opened against an IaC repo → CI runs `terraform plan`
   - Plan output + PR metadata → posted to Slack via Terraform-Slack bot
   - Review thread starts in `#tf-reviews` (or `#tf-<workspace>`)

2. **Plan summary message** — Block Kit:
   - **Header** — workspace + actor + PR link
   - **Diff summary** — N to add, N to change, N to destroy
   - **Risk badges**:
     - Green: only metadata changes
     - Yellow: writes to non-prod
     - Orange: writes to prod, no destroys
     - Red: destroys in prod, or IAM changes, or DB schema changes
   - **Drift detected** — if plan shows changes user didn't make (state drift)
   - **Policy violations** — Sentinel / OPA / custom policy results
   - **Estimated cost change** — from Infracost / Terraform Cloud
   - **Action buttons**: View Full Plan, Approve, Reject, Discuss in Thread

3. **Risk classification rules**:
   - **Critical resources** — list of resource types that always trigger highest tier:
     - `aws_iam_*` (IAM)
     - `aws_db_instance` deletes
     - `aws_s3_bucket` policy changes
     - `google_iam_*`
     - `azurerm_role_*`
     - `kubernetes_cluster_role*`
   - **Production identifiers** — workspace name / env tag indicates prod
   - **Destroy blast radius** — > 10 destroys or destroy of critical resource → red

4. **Approval rules**:
   - **Green** — auto-approve + auto-apply on PR merge
   - **Yellow** — 1 approver from team
   - **Orange** — 1 approver from team + 1 from #platform
   - **Red** — 2 approvers including a senior engineer + service owner sign-off

5. **Approval workflow**:
   - Approver clicks Approve in Slack
   - Bot validates approver identity (AAD group / Slack user group)
   - Records approval (timestamp + approver oid)
   - When required N approvals collected, posts "Ready to apply"
   - Triggers `terraform apply` via API; posts result back

6. **Full plan view**:
   - Click "View Full Plan" → renders human-readable plan in a thread
   - For very long plans, link to Terraform Cloud / GitHub Actions log
   - Include the raw diff for changed resources

7. **Drift handling**:
   - Plan shows changes user didn't make → flag prominently
   - Common cause: someone made a console change
   - Action: investigate before applying; may need to import the changed state
   - Bot suggests: "Run `terraform import` for resource X? Plan-only first."

8. **Policy violations** (Sentinel / OPA / custom):
   - List each violation with the rule + line + suggested fix
   - Block apply until resolved (or override with security sign-off for emergency)
   - Repeated violation patterns → suggest policy or code refactor

9. **Audit log** — every plan review records:
   - Plan summary + risk classification
   - Reviewers + decisions
   - Final outcome (applied / rejected / withdrawn)
   - Apply result (success / partial / failed / timeout)
   - For destroys in prod: extended audit retention

10. **Anti-patterns to avoid**:
   - Auto-apply for any prod change
   - Approval without reviewing the plan
   - Skipping policy violations as "just warnings"
   - No drift detection (will bite you)
   - Reviewer can also be the requester
   - No rollback path for failed apply

Output as: (a) plan summary Block Kit JSON, (b) risk classification rules, (c) approval rule matrix, (d) full-plan view design, (e) drift handling flow, (f) policy violation surfacing, (g) audit log schema, (h) anti-pattern checklist.

Bias toward: risk-tiered review, every prod change has a human approval, drift detection always on, audit trail for every apply.