Slack triage posting skill

When to use

After the triage report is complete and the operator wants to post it to Slack.

Slack mrkdwn formatting rules

Slack does NOT support standard markdown. Use Slack mrkdwn:

• *bold* not **bold**
• _italic_ not *italic*
• `code` for inline code (works same as markdown)
• > for block quotes
• :emoji_name: for emoji
• <url|display text> for links
• No tables, no horizontal rules, no headers

Message template

Use this exact structure. It's optimized for scanning in a busy channel.

Line 1: Priority + one-line summary (the hook)

This is what appears in channel preview and notifications. Must convey severity and topic instantly.

:red_circle: `P1` *One-line problem description*

Priority emoji mapping:

• :red_circle: P1 Critical
• :large_orange_circle: P2 High
• :large_yellow_circle: P3 Medium
• :white_circle: P4 Low

Line 2: Metadata pills

Compact metadata as inline code blocks — acts as visual "pills".

`Bug` `Session Replay · iOS` `Enterprise · 8h SLA`

Format: `{issue type}` `{product area} · {platform}` `{plan tier} · {SLA}`

Line 3: Summary paragraph

2-3 sentences max. Plain text. What the customer is experiencing and the key context. No jargon.

Evidence section

Block-quoted with status emoji per finding:

• :white_check_mark: Confirmed finding
• :warning: Concerning finding or partial match
• :x: Dead end or no match

:mag: *Evidence*
> :white_check_mark: Finding from docs with key detail
> :white_check_mark: `repo#issue` — status, comment count, relevance
> :warning: SDK version outdated — `current` vs latest `new`
> :x: No matching issues for alternate symptom

Diagnosis section

Inline confidence indicator + one-line explanation.

Confidence mapping:

• `Confirmed` with :dart: — evidence proves it
• `Likely` with :thinking_face: — pattern match, not proven
• `Suspected` with :question: — needs human verification

:dart: *Diagnosis*  `Confirmed`  One-line root cause explanation.

Actions section

Numbered with inline code block numbers for visual weight.

:hammer_and_wrench: *Actions*
`1` First action with `specific details`
`2` Second action
`3` Third action

Footer

Compact single line for escalation, docs gap, and confidence.

`Escalation: none`  `Docs gap: specific suggestion here`  `Confidence: High (6/7 verified)`

Or if confidence is Low (<50%):

`Escalation: none`  `Docs gap: none`  `:warning: Confidence: Low (2/5 verified) — needs human review`

Or if escalating:

`:rotating_light: Escalation: Engineering — replay team`  `Severity: High`  `Follow-up: 4-8h`  `Confidence: High (5/5 verified)`

The confidence line uses the same score from the Evidence Pack. If confidence is Low, prepend :warning: emoji to make it visually stand out.

Full example

:large_orange_circle: `P2` *iOS replay OOM — iPhone 15 Pro Max*
`Bug` `Session Replay · iOS` `Scale · 24h SLA`

Customer app crashes with OOM ~5 min after enabling session replay on high-res devices. Disabling replay fixes it.

:mag: *Evidence*
> :white_check_mark: Docs confirm screenshot mode allocates full-res bitmaps — known memory hog
> :white_check_mark: `posthog-ios#18432` open — 34 comments, fix in progress
> :white_check_mark: Codebase: masking pipeline creates 2+ bitmaps/cycle via `UIGraphicsImageRenderer`
> :warning: Customer on `3.8.1` — latest `3.9.0` has partial fix

:dart: *Diagnosis*  `Confirmed`  Known bug in screenshot masking pipeline on high-res devices.

:hammer_and_wrench: *Actions*
`1` Upgrade to `posthog-ios 3.9.0`
`2` Increase `throttleDelay`
`3` Switch to wireframe mode
`4` Monitor next release for full fix

`Escalation: none`  `Docs gap: add device memory guidance to iOS replay troubleshooting`  `Confidence: High (4/4 verified)`

How to post

Default: use mcp__slack__slack_send_message_draft (draft mode). Only use mcp__slack__slack_send_message (direct send) when the operator explicitly says "post it" or "send it now."

Parameters:

• channel_id: The target channel ID (find with slack_search_channels)
• message: The formatted message following the template above

To find a channel ID:

mcp__slack__slack_search_channels(query="all-sandbox")

Thread replies

For follow-up findings, use thread_ts from the original message to reply in-thread. Keep the main channel clean — one message per ticket, details in threads.

Customer response thread reply (mandatory)

After posting the internal triage message, always post the customer response draft as a thread reply on the same message. This keeps the internal triage scannable in the channel while making the customer draft immediately accessible without opening the full report file.

Customer response thread template

:speech_balloon: *Draft Customer Response* — ready to copy into Zendesk/GitHub

---

[Full customer response text from the triage report's Draft Customer Response
section. Copy it verbatim — it's already been through the quality checklist
and voice check.]

---

:warning: _Review before sending. Check Evidence Pack in the full report for
confidence score and any spot-check flags._
`Report:` `{filename from triage-reports/}`

How to post the thread reply

1. Post the internal triage message first (draft or direct, per operator request)
2. Capture the thread_ts from the posted message response
3. Post the customer response as a reply using the same channel_id + thread_ts
4. If using draft mode: both the main message and the thread reply are drafts

Rules for the customer response thread

• Copy the Draft Customer Response verbatim from the triage report — do not re-summarize, shorten, or editorialize
• Scrub PII using the same rules as the main message (no project IDs, tokens, distinct IDs, session URLs, admin URLs)
• Never include the Evidence Pack in the thread — it stays in the report file
• Include the report filename so the reviewer can find the full evidence

Batch mode

When posting multiple triage reports at once, post each as its own main message (not as thread replies to a single message). Each ticket gets:

1. Main channel message (internal triage summary)
2. Thread reply (customer response draft)

This keeps each ticket independently scannable and threadable.

Saving to disk (always — not just on failure)

Always save Slack messages and customer responses to disk, regardless of whether Slack posting succeeds. These files are the audit trail and a fallback if Slack auth fails. All files go to triage-reports/ (gitignored).

Single ticket

Save two files per ticket:

Example filenames:

• 20260409-150012-slack-gh-53788.md
• 20260409-150012-response-gh-53788.md

Batch triage

Save two batch files:

Customer response file format

markdown
1# Response: {one-line issue title}
2**Issue:** {URL or ticket reference}
3**Date:** {YYYY-MM-DD}
4
5---
6
7{Full customer response text — verbatim from the triage report}

No evidence pack, no internal notes, no emoji. Ready to paste into Zendesk/GitHub.

Rules

• Always use mcp__slack__slack_send_message_draft by default. Only use mcp__slack__slack_send_message (direct send) when the operator explicitly says "post it" or "send it now." Draft-first prevents unreviewed reports from reaching channels.
• Always post the customer response as a thread reply after the main triage message. Two messages per ticket: triage in channel, customer draft in thread.
• Never post PII to Slack — scrub project tokens, distinct IDs, session IDs, API keys, and person properties before posting. Use the same redaction rules as the site inspector skill.
• Never post internal tool names (HogQL, MCP tool names) — customer-facing channel risk
• Always include the priority emoji + code on line 1 — it's the notification preview
• Keep main message under 3000 chars — longer messages get truncated on mobile
• Customer response thread replies can be longer (up to 4000 chars) since they're in-thread and won't clutter the channel
• Always save to disk — both Slack messages and customer responses, even when Slack posting succeeds