/
DE

⚡ Promptolis Original · Productivity & Systems

💬 Slack Thread Summarizer & Actioner

Reads a long Slack thread + produces the summary, the decisions made, the action items with owners + dates, and the 3 things still unresolved that nobody noticed.

⏱️ 2 min to try 🤖 ~45 seconds in Claude 🗓️ Updated 2026-04-28

Why this is epic

Most Slack threads of 30+ messages are a graveyard of half-decisions, drift, side-conversations, and 'wait, did we agree on that?' moments. This Original surfaces the ACTUAL decisions, the ACTUAL action items, and the things that were debated but never resolved.

Outputs a structured artifact you can paste in a doc, post in another channel, or use as the formal record. Includes who-owns-what with dates — actionable, not just descriptive.

Catches what humans miss in long threads: contradictions ('John said X early, then later said Y'), unresolved questions buried in side-comments, scope drift, and the implicit decisions nobody named.

Calibrated to 2026 Slack: Canvas, Huddles transcripts, threaded replies, channel-vs-DM context. Picks the right output format for where the summary will live.

The prompt

Promptolis Original · Copy-ready
<role> You are a thread synthesizer with 5+ years summarizing Slack discussions for distributed teams. You have read 5000+ threads + extracted what mattered. You catch contradictions humans miss, unresolved questions buried in side-comments, and implicit decisions nobody named. You are direct. You will tell a reader 'this thread didn't actually decide X — they debated and moved on' if that's what happened. You refuse to write a summary that papers over disagreements or pretends a question got answered when it didn't. </role> <principles> 1. Decisions are explicit; if not stated as a decision, mark as 'discussed, not decided.' 2. Action items have owners + dates. 'Someone should look into X' is not an action item. 3. Catch contradictions: 'A said X at 10:30, then said Y at 14:15' is signal. 4. Unresolved questions are surfaced explicitly — easily missed in long threads. 5. Summarize in the thread's own voice level (technical / casual / formal). 6. If the thread is incoherent, say so — don't fabricate structure. 7. Anonymize only when explicitly asked; otherwise preserve names for accountability. </principles> <input> <thread-content>{paste the full thread — include timestamps + sender names + message text. Threaded replies marked clearly.}</thread-content> <purpose>{decision-record / status-update / onboarding / retrospective / action-items / 'recommend'}</purpose> <audience>{who will read the summary}</audience> <thread-channel>{which channel — gives context: #engineering vs #incidents vs #leadership-private}</thread-channel> <additional-context>{anything not in the thread the reader needs to know — related Linear ticket, prior discussion, etc.}</additional-context> <format-preferences>{markdown / plain text / structured for paste-into-doc / 'recommend'}</format-preferences> </input> <output-format> # Thread Summary: [topic in 8 words or less] ## TL;DR (3 lines) The shortest possible version. What happened, what was decided, what's outstanding. ## Context 2-3 sentences. What the thread was about. Channel. When it started. Major participants. ## Decisions Made Numbered list. For each: the decision, who decided / who agreed, when (timestamp). ## Action Items Numbered list. For each: action, owner (named person), deadline (specific date or 'unspecified — needs follow-up'). ## Discussed but NOT Decided Things that came up + got debated + thread moved on without resolution. The 'wait, did we ever decide X?' section. ## Open Questions Questions raised that nobody answered. Differs from 'not decided' (those are debates); these are unanswered questions. ## Key Context / Why The reasoning behind major decisions. Useful for onboarding mode + decision-record mode. ## Contradictions / Drift If the thread has internal contradictions ('A said X then Y'), name them. Be careful + diplomatic. ## Sentiment / Tone Brief read on tone: aligned, in-conflict, frustrated, excited, etc. Useful for managers. ## What's Missing What the thread DIDN'T cover that probably should have. The 'we need to talk about X' note. ## Suggested Next Steps 2-4 specific recommendations for follow-up — meeting, doc, decision deadline, etc. </output-format> <auto-intake> If input incomplete: ask for thread content (full text), purpose, audience, channel, additional context, format preferences. </auto-intake> Now, summarize the thread:
🚀 Open in ChatGPT ✨ Open in Claude 💎 Open in Gemini

Example: input → output

Here's how this prompt actually performs. Real input below, real output from Claude Opus 4.

📝 Input
<thread-content>
(In #engineering channel, started by @sarah on Apr 21 09:14)

Sarah (PM) [09:14]: Hey team, want to discuss the database migration we've been planning. Need to decide approach + timeline.

Mike (Eng Lead) [09:18]: Yeah, this has been on the backlog for 3 months. We need to migrate from Postgres 14 → Postgres 16 and also restructure the orders table — it has 8M rows and the indexes are wrong.

Sarah [09:20]: Ok so 2 things in one. Should we do them together or separate?

Alex (Senior Eng) [09:25]: Together. They both need downtime; doing them in 2 separate maintenance windows means 2x the comms + 2x the customer disruption.

Mike [09:27]: Disagree slightly. Pg upgrade is well-trodden. Restructure-orders is novel + risky. If we do them together and something breaks, hard to know which caused it. Vote separate.

Lisa (Backend Eng) [09:30]: I'm with Mike on splitting. Pg 14→16 first. Confidence high. Then orders restructure as a separate project with proper testing + canary.

Sarah [09:33]: Ok so split it is. Pg upgrade first. When?

Alex [09:35]: Next maintenance window is May 5 (Sunday 3am Pacific). Could fit Pg upgrade.

Mike [09:37]: Concerns: we have a customer demo Monday May 6. If migration runs long + we don't roll back fast enough, demo at risk.

Sarah [09:39]: Demo is at 2pm Pacific. If migration window is 3-7am Sunday, we have ~30hrs buffer. Should be fine.

Mike [09:41]: Fair. Ok if migration is OVER by 7am Sunday I'm fine.

Lisa [09:42]: I can lead the migration. Ran the staging Pg 14→16 last month. ~3hr runtime, no issues.

Sarah [09:43]: Great. Lisa leads. Mike on standby. Alex on app-side validation post-migration.

Alex [09:46]: Question: do we want to update our connection pool config too? Pg 16 has different defaults.

Mike [09:48]: Good catch. Yes, but we can do that after the migration once we see actual behavior.

[At 10:15, side conversation about whether to use pgvector for embeddings — 8 messages, ends inconclusively]

Sarah [10:30]: Ok wrapping. Pg 14→16 migration on May 5 Sunday 3am Pacific. Lisa leads. Mike standby. Alex validates post-migration. We'll update connection pool after we see Pg 16 behavior live. Orders table restructure as separate project — Mike will scope this week.

Mike [10:32]: 👍

Lisa [10:33]: 👍

Alex [10:33]: 👍 — and remind me to test the pgvector thing in dev before the call about it next week.

[End of thread]
</thread-content>
<purpose>Decision record — going to paste this in our /decisions Notion doc</purpose>
<audience>Future engineers + PMs who'll need to know what we decided + why</audience>
<thread-channel>#engineering</thread-channel>
<additional-context>The orders-table-restructure has been blocked for 3 months due to ambiguity on whether to do it together with Pg upgrade. This thread breaks that ambiguity.</additional-context>
<format-preferences>Markdown, structured for Notion paste</format-preferences>
🤖 Output

Thread Summary: Postgres 14→16 Migration + Orders Table Restructure Decision

TL;DR

Decided to split work: Postgres 14→16 migration first on May 5 (Sunday 3am Pacific), led by Lisa with Mike on standby and Alex validating. Orders table restructure becomes a separate project that Mike will scope this week. Connection pool updates deferred until post-migration.

Context

#engineering thread on April 21, 09:14-10:33. Sarah (PM) opened to align on database migration approach. Major participants: Sarah (PM), Mike (Eng Lead), Alex (Senior Eng), Lisa (Backend Eng). Topic had been blocked for 3 months due to ambiguity on coupling vs splitting the two changes.

Decisions Made

1. Split the work into two separate projects — Postgres upgrade first, orders-table restructure as a follow-up project. Decided 09:30 (Mike + Lisa argued for split; Alex initially argued together; Sarah decided split at 09:33).

2. Postgres 14 → 16 migration scheduled for May 5, Sunday 3am Pacific. Decided 09:43.

3. Lisa leads the migration; Mike on standby; Alex on post-migration app-side validation. Decided 09:43.

4. Connection pool config updates deferred until post-migration. Decided 09:48 (we'll observe Pg 16 actual behavior first).

5. Orders table restructure becomes a separate scoped project. Mike to scope this week. Decided 10:30.

Action Items

1. Mike: scope the orders-table-restructure project as a separate effort. Deadline: by end of week (April 25).

2. Lisa: prepare May 5 migration runbook (based on her staging run from last month). Deadline: implicit before May 5.

3. Alex: prepare app-side validation checklist for post-migration. Deadline: implicit before May 5.

4. Alex (self-noted): test pgvector in dev before next week's separate pgvector call. Deadline: 'next week' — needs explicit calendaring.

Discussed but NOT Decided

  • pgvector for embeddings — 8 messages of side conversation around 10:15 ended inconclusively. Alex flagged he wants to test in dev. Marked for separate call next week (no concrete date in this thread).

Open Questions

  • What's the rollback plan for the May 5 migration? Lisa mentioned ~3hr runtime + no issues in staging, but no explicit rollback procedure was discussed in the thread. Worth confirming before the migration.
  • What customer comms go out before May 5? No comms plan discussed — likely needs to be added to action items.
  • What happens if something fails post-migration but before customer demo on May 6? Mike raised this concern; the consensus was '30hr buffer should be enough' but no escalation plan was named.

Key Context / Why

Why split (not combine) the migrations: Mike argued the Postgres upgrade is well-trodden + low-risk while the orders-table restructure is novel + high-risk. Doing them together would make root-cause analysis difficult if something breaks. Lisa concurred. The decision reflects a 'separate concerns to enable clear root-cause' engineering principle.

Why May 5: Next available maintenance window with sufficient buffer before the May 6 customer demo. Alex initially proposed; Mike concerned about demo proximity; Sarah verified the 30-hour buffer was sufficient.

Why Lisa leads: She ran the Postgres 14→16 upgrade in staging the previous month with 3-hour runtime + no issues. Concrete experience > theoretical knowledge for migration leads.

Contradictions / Drift

None significant in this thread. Alex initially argued for combining the migrations, then accepted the split decision without further pushback. Healthy disagreement → consensus pattern.

Sentiment / Tone

Aligned + collaborative. The thread had real disagreement (Alex vs Mike+Lisa on combine-vs-split) but it was substantive, resolved on merits, and the team moved on. No frustration signals. Confidence in the migration plan is high — Lisa's prior staging experience is the anchor.

What's Missing

  • Customer comms plan — when do customers get notified about the May 5 maintenance window? Not discussed.
  • Rollback procedure — referenced casually but not formalized.
  • Success criteria for post-migration validation — what does Alex check? Not specified.
  • The pgvector question — got 8 messages and a vague 'next week call.' Worth setting an actual meeting time.

Suggested Next Steps

1. Mike: Calendar a 30-min 'Migration Plan Review' meeting before May 5 to formalize rollback + comms + validation criteria.

2. Sarah: Add the orders-table-restructure scoping to next week's planning meeting agenda (since Mike committed to scope by April 25).

3. Alex: Send a calendar invite for the pgvector discussion next week so 'next week' becomes a real date.

4. Lisa: Draft a customer-comms email about the May 5 maintenance window for review by Sarah this week.

Common use cases

  • Engineer who joined an in-progress project + needs to catch up on the channel history
  • PM running cross-functional discussion in a thread, needs to formalize decisions
  • Manager doing weekly retrospective on a #incidents or #project-X channel
  • New team member onboarding to a project's recent decision context
  • Anyone who DM'd with their boss about a major topic and wants the canonical record
  • Founder synthesizing a long board-Slack discussion into a board-meeting prep doc

Best AI model for this

Claude Sonnet 4.5 or Opus 4. Thread synthesis is well within Sonnet's range. Opus better for very long threads (200+ messages) or threads with technical decisions to extract.

Pro tips

  • Paste the FULL thread including timestamps + senders. The Original needs to know who said what + when. Anonymizing weakens analysis.
  • Specify what kind of summary you need: decision-record, status-update, onboarding-summary, or retrospective. Each produces a different shape.
  • Always check for the 'unresolved questions' section — the Original specifically looks for things debated but never decided. This is where surprises hide.
  • If the thread has Huddle/audio transcripts, paste those too. Decisions in voice often don't get echoed in chat.
  • Don't paste DM threads with strong privacy concerns. Use general AI hygiene; this isn't legal advice.
  • Use the output as a starting point, not the final word. Confirm key actions with people named.
  • For recurring channels, run this weekly. Patterns emerge — same questions, same blockers — that one-shot summaries miss.

Customization tips

  • Paste the FULL thread with timestamps and senders. Anonymizing or trimming weakens the analysis — the Original needs to know who-said-what-when.
  • Specify the purpose precisely. A decision-record summary differs structurally from an onboarding summary or an action-items-only extract.
  • If the thread is in a sensitive channel (#leadership-private, #incidents-confidential), respect that — don't paste into shared AI tools without authorization.
  • Always check the 'discussed but not decided' section. This is where the most useful insight hides — debates that drifted without resolution.
  • Provide additional context. Knowing 'this has been blocked for 3 months' shifts the summary's framing significantly.
  • Use the Incident Retrospective Mode variant for #incidents threads — adds timeline-extraction and prevention-task framing.

Variants

Decision Record Mode

Optimized for capturing formal decisions — extracts decisions, rationale, dissent, and timeline.

Onboarding Mode

For new team members catching up — emphasizes the 'why' behind decisions and key context, not just what was decided.

Incident Retrospective Mode

For #incidents threads — extracts timeline, root cause, action items, prevention tasks.

Action Items Only Mode

For threads with lots of social chat + a few action items buried in — extracts JUST the actionable bits.

Frequently asked questions

How do I use the Slack Thread Summarizer & Actioner prompt?

Open the prompt page, click 'Copy prompt', paste it into ChatGPT, Claude, or Gemini, and replace the placeholders in curly braces with your real input. The prompt is also launchable directly in each model with one click.

Which AI model works best with Slack Thread Summarizer & Actioner?

Claude Sonnet 4.5 or Opus 4. Thread synthesis is well within Sonnet's range. Opus better for very long threads (200+ messages) or threads with technical decisions to extract.

Can I customize the Slack Thread Summarizer & Actioner prompt for my use case?

Yes — every Promptolis Original is designed to be customized. Key levers: Paste the FULL thread including timestamps + senders. The Original needs to know who said what + when. Anonymizing weakens analysis.; Specify what kind of summary you need: decision-record, status-update, onboarding-summary, or retrospective. Each produces a different shape.

Explore more Originals

Hand-crafted 2026-grade prompts that actually change how you work.

← All Promptolis Originals
P

Curated by

Every Promptolis Original is hand-crafted and reviewed before publishing — built from scratch for 2026-grade LLMs.

Last reviewed on · About Promptolis