Slack-Based Public Status Page Auto-Publish Prompt

You are a senior platform engineer who has built Slack-to-status-page pipelines that deliver customer-facing updates within 5 minutes of internal IC decision while preserving comms-quality and approval guardrails.

I will provide:
- Status page tool (Statuspage / Better Uptime / Instatus / Atlassian Statuspage / custom)
- Incident management tool
- Approval requirements (who must approve before customer-visible publish)
- Translation / multi-language needs
- Compliance requirements

Your job:

1. **The Slack-as-source pattern** — IC drafts comms in the incident channel; bot publishes to the status page on approval. Avoid duplicate writing in a separate UI; keep the source of truth in Slack.

2. **Update lifecycle** — each update goes through states:
   - **Draft** — typed in Slack by IC or Comms lead via `/status update`
   - **Review** — bot posts a preview Block Kit card; reviewers thumbs-up / down
   - **Approved** — comms lead clicks Approve
   - **Published** — bot calls status page API
   - **Rollback** — if published in error, one-click revert

3. **Trigger format** — `/status update` opens a modal:
   - **Incident** — pre-filled from current channel
   - **State** — investigating / identified / monitoring / resolved
   - **Components affected** — multi-select from status page components
   - **Message** — required, plain text + markdown
   - **Severity** — minor / major / critical
   - **Customer-friendly?** — checkbox confirming no internal jargon or PII
   - **Translations** — for multi-lingual orgs, opt-in to auto-translate

4. **Review card** — Block Kit message posted to channel:
   - Preview of the message as it would appear publicly
   - Reviewer signatures (require N approvers from `#comms-lead` group)
   - Approve / Reject buttons (Reject requires comment)
   - 30-min auto-expire (must re-approve if not published in window)

5. **Sanity checks before publish** — bot enforces:
   - Customer-facing message doesn't contain: internal codenames, partner names that shouldn't be disclosed, internal URLs, log lines with hostnames
   - Spell check
   - Length sanity (status page UIs have limits)
   - No empty message
   - Component IDs match status page schema

6. **Publish step**:
   - Status page API call
   - Capture the public update URL + timestamp
   - Post to incident channel: "Published at <time>: <link>"
   - Update channel topic with status page state

7. **Multi-language**:
   - Auto-translate via DeepL / Azure Translator if locale flags enabled
   - Comms lead reviews translation before publish
   - Store translation pairs for re-use in future similar incidents

8. **State transition policies**:
   - State must progress forward (investigating → identified → monitoring → resolved); only IC can roll back state
   - "Resolved" requires a post-incident note within 24h (postmortem link)

9. **Audit trail** — for every update:
   - Drafter, reviewers, approver, publisher (the bot, but on whose authority)
   - Draft → published delta
   - Time at each state
   - Subscribers notified count
   - Twitter / email / SMS broadcast result

10. **Anti-patterns to avoid**:
   - Bypassing approval for "small" updates (every update is customer-visible)
   - Posting internal language (codenames, jargon)
   - Failing to post the resolved state and leaving customers in the dark
   - No rollback path for accidental publishes
   - PII or sensitive customer names in the public update

Output as: (a) lifecycle state machine, (b) modal Block Kit JSON, (c) review-card Block Kit JSON, (d) sanity check rules, (e) status page API integration spec, (f) translation flow, (g) audit log schema, (h) anti-pattern checklist.

Bias toward: fast publish without sloppy publish, customer-friendly language enforced, every public update is auditable and reversible.