--- name: slack-incident-summary description: "Every 30 minutes during an incident: the incident channel boiled down to status, customer impact, a timeline and the follow-ups for the postmortem. Use when the user asks for this, or when it runs on a schedule." --- # Slack incident summary Every 30 minutes during an incident: the incident channel boiled down to status, customer impact, a timeline and the follow-ups for the postmortem. "What is the status?" gets asked a dozen times in every incident channel, and the person who knows is the one fixing it. Writing stakeholder updates during an incident is a job of its own, and it usually falls to whoever is least able to stop. The agent reads the incident channel from its first message, builds a timeline of what was noticed, tried and changed, states the impact and status in two lines, and keeps a list of the follow-ups people mentioned. The same card updates every half hour until the channel says resolved, and the last version is the first draft of the postmortem timeline. ## Two ways to get the data Use the API or MCP route when you have an MCP server, a CLI or an API token for the app. Otherwise, if you can drive a browser the user is signed in to (Claude in Chrome, a Playwright or Chrome DevTools MCP server), use the browser route. Say which one you used. ## Route A: API or MCP server ### What you need - A Slack app with `channels:read`, `channels:history`, `groups:read`, `groups:history`, `pins:read` and `users:read`, invited to incident channels, or a Slack MCP server or connector acting as you. - Your incident channel naming convention, for example `inc-` followed by a date and a short name. If something is missing, say what and stop; do not invent numbers. ### Steps 1. **Find open incident channels** (Slack): `conversations.list` with `types=public_channel,private_channel` and `exclude_archived=true`, keeping channels whose name starts with your incident prefix (such as `inc-`) and whose `created` is within 7 days. Read each one's topic from `conversations.info` and its pins from `pins.list`. 2. **Read the whole channel** (Slack): `conversations.history` from the first message, plus `conversations.replies` for every thread. Reading it in full each run keeps the timeline consistent from one update to the next. 3. **Build the timeline**: Pull out the first report, the declaration and severity, each mitigation tried, deploys or rollbacks, customer messages and the all-clear. Convert each `ts` to local time and keep each event to one sentence naming who did it. 4. **State impact, status and follow-ups**: Impact: who is affected, how, and since when. Status: investigating, identified, mitigated, monitoring or resolved, from the latest messages and the channel topic. Follow-ups: messages that say "follow-up", "action item" or "after this", with an owner where one was named. 5. **Post one card per incident**: Use the channel name as the `item_key`, `work_state: in_progress` until resolved and `done` after. Stop updating an hour after the channel declares it resolved. ## Route B: the browser ### What you need - Signed in to the Slack workspace as a member of the incident channels; a private incident channel needs an invite before anything shows. If something is missing, say what and stop; do not invent numbers. ### Steps Start at https://app.slack.com/client. The user is signed in already; never type passwords or codes, and ask if a sign-in page appears. 1. **Find the open incident channels**: In the workspace, open the channel browser (**More > Channels**, or click **Channels** in the sidebar) and type `inc-` in the search box. Open each channel created in the last 7 days whose topic does not say resolved. 2. **Read the topic and pins**: Click the channel name at the top to read its topic and description, then open **Pins** from the channel header; the declaration, the severity and the incident commander are usually there. 3. **Read the channel from the start**: Scroll to the top until **This is the very beginning of the channel** shows, then read down to the latest message, opening every **N replies** thread in the side panel. Reading all of it each time keeps the timeline consistent between updates. 4. **Build the timeline and the status**: Note the first report, the declaration and severity, each mitigation tried, deploys or rollbacks, customer messages and the all-clear, one sentence each with the time shown on hover and the person. Status is investigating, identified, mitigated, monitoring or resolved, from the latest messages and the topic. 5. **Collect the follow-ups and write**: Messages that say "follow-up", "action item" or "after this" go on the follow-up list with an owner where one was named. Write impact in two lines, the status with when it last changed, the timeline and the follow-ups. Note: A long incident channel with many threads takes minutes to read in a browser, so this route fits an update on demand rather than every 30 minutes. Message times show in your Slack time zone; say which one the timeline uses. ## The report - **Status** in one word, with the time it last changed. - **Impact**: who is affected, how, and since when. - **Timeline**: detection, declaration, each mitigation and the resolution, with times and names. - **Follow-ups** for the postmortem, with owners where named. - **Who is on it**: the incident commander and the people active in the channel. ## Post it to Briefkin When `BRIEFKIN_TOKEN` is set, or `~/.config/briefkin/env` exists (the installer from https://briefkin.dev/docs writes it), also send the result to the user's Briefkin board as one card. Keep the `item_key` the same on every run so the card updates in place, use a new `event_id` per run, and put today's real numbers in place of the example ones. If the request fails, say so once and carry on. ```bash [ -n "${BRIEFKIN_TOKEN:-}" ] || . ~/.config/briefkin/env curl -sS -X POST "${BRIEFKIN_URL:-https://briefkin.dev}/v1/events" \ -H "authorization: Bearer $BRIEFKIN_TOKEN" \ -H "content-type: application/json" \ -d @- <<'JSON' { "v": 1, "event_id": "slack-incident-summary/", "item_key": "slack-incident-summary", "project": "Acme", "source": "Slack incident summary skill", "kind": "update", "title": "Checkout incident mitigated, monitoring", "summary": "From 13:52, about **8% of card payments** failed in the EU. A rollback at 14:31 brought failures back to normal; the team watches for an hour before resolving.", "work_state": "in_progress", "widget": [ { "type": "Steps", "props": { "items": [ { "label": "13:52 Alert on payment failures in eu-west", "state": "done", "note": "Picked up by Ana, on call" }, { "label": "14:03 Declared SEV-2, Kofi is incident commander", "state": "done" }, { "label": "14:12 Cause narrowed to the 13:40 payments-api deploy", "state": "done" }, { "label": "14:31 Rolled back payments-api to v3.18.4", "state": "done", "note": "Failure rate under 0.5% by 14:40" }, { "label": "Monitoring until 15:40, then resolve", "state": "active" }, { "label": "Email to affected merchants", "state": "pending", "note": "Lena is drafting it with Support" } ] } }, { "type": "Table", "props": { "columns": [ "Follow-up", "Owner" ], "rows": [ [ "Add a canary stage to payments-api deploys", "Rui" ], [ "Alert on the EU card failure rate, not only the global one", "Ana" ], [ "Postmortem document by Tuesday", "Kofi" ] ] } } ] } JSON ``` Widgets come from the Briefkin catalog (https://briefkin.dev/v1/catalog). Without a token, just give the user the report. ## Run it on a schedule Suggested: Every 30 minutes (`*/30 * * * *`). From cron, with the agent signed in on that machine: ```bash */30 * * * * claude -p "Run the slack-incident-summary skill" # Codex: codex exec, Gemini CLI: gemini -p, Copilot CLI: copilot -p, OpenCode: opencode run ``` Or use the agent's own scheduler (Claude Code routines, Codex automations, Claude or ChatGPT scheduled tasks): https://briefkin.dev/skills/slack-incident-summary#schedule Source: https://briefkin.dev/skills/slack-incident-summary