Claude Prompts for Slack (Messages, Threads, Announcements)

<context> Slack thread, copied with display names and timestamps: [PASTE FULL THREAD] Channel and purpose: [#channel-name, what it is for] My role: [owner, reviewer, bystander who just got tagged] </context> <task> Tell me the current state of this thread. What was settled, what is still open, what the last substantive message actually asked for, and whether anything is waiting on me specifically. </task> <format> Four short sections: Settled, Still Open, Waiting On Me, Suggested Next Message. No replay of the conversation in order. </format>

<context> What shipped: [feature, tool, process] Who it is for: [which teams or customers] What it replaces or changes: [old way] Where the docs live: [link placeholder] Owner for questions: [name] Channel: [#general, #product, #announcements] </context> <task> Write the announcement post. Lead with what people can now do that they could not yesterday, not with the project name. Name the change in behaviour you want, and give one place to ask questions so the thread does not fragment. </task> <format> Slack post: bold one-line headline, two sentences on what changed, a What This Means For You section by team, one line on docs, one line naming who answers questions in this thread. </format>

<context> Policy changing: [old rule, new rule] Effective date: [date] Why it changed: [the real reason, including the uncomfortable part] Who is affected and how: [groups] What I cannot say publicly: [confidential context] </context> <task> Write the announcement, then predict the five questions people will actually ask in the replies, including the cynical ones, and draft an honest answer for each. Do not use language that implies the decision is open for debate if it is not. </task> <format> Announcement post first. Then a separate FAQ block I can paste as the first thread reply, five questions with answers of two or three sentences each. </format>

<context> What is broken: [system, symptom] Who is affected: [customers, internal, scope] Started at: [time and timezone] Current status: [investigating, identified, monitoring, resolved] What we know and what we do not: [facts, unknowns] Next update due: [time] </context> <task> Write the status update for the incident channel. State impact in plain terms, separate confirmed facts from suspicion, and commit to a next update time. Do not speculate on cause or give an ETA we have not confirmed. </task> <format> Short post with these labelled lines: Status, Impact, What We Know, What We Are Doing, Next Update. Under 100 words so it reads on a phone. </format>

<context> Full postmortem document or notes: [PASTE THE POSTMORTEM] Audience: [whole company, leadership, affected teams] What we want them to take away: [confidence, a behaviour change, awareness] </context> <task> Condense this into a Slack post for people who will not read the full document. Keep the customer impact, the actual cause in one sentence, and the specific changes being made with owners. Strip blame and internal component names nobody outside the team knows. </task> <format> Post with four short blocks: What Happened, Impact, Why, What Changes Now with owner and date per item. Link placeholder to the full doc at the end. </format>

<context> Change: [new hire, internal move, someone leaving, reporting line change] Person and role: [name, title, team] What they own from now on: [scope] What changes for other teams: [who to ask about what now] Start or effective date: [date] Tone: [celebratory, matter of fact, sensitive] </context> <task> Write the announcement. Make the practical routing clear, which is the part colleagues actually need, and keep the personal detail to what the person would be comfortable seeing in a public channel. </task> <format> Post with a one-line headline, two lines on the person, a Who To Ask About What line, and a closing line inviting welcomes in the thread. </format>

<context> What is slipping: [deliverable] Old date and new date: [dates] Why: [the real cause] Knock-on effects: [what else moves, who is blocked] What we are doing about it: [mitigation] Who needs to hear it first: [stakeholders] </context> <task> Write the update. Give the new date in the first line, then the cause without defensiveness, then the downstream effects with names so people can plan. Do not open with an apology paragraph and do not promise a date the team has not agreed to. </task> <format> Post: new date first line, three lines of cause, a Knock-On Effects list naming affected people or teams, and one line on what changes so this does not repeat. </format>

<context> Change being rolled out: [what] Timeline: [key dates] Audiences and their channels: [leadership in #x, affected team in #y, whole company in #z, customer-facing team in #w] What each audience needs to do: [per audience] </context> <task> Build the comms plan and write every message in it. Decide the order so nobody important hears it second hand, and vary the message per audience instead of pasting the same text everywhere. </task> <format> Table first: Order, Channel, Audience, Timing, Purpose. Then each message written in full under a heading matching its row. </format>

<context> My messy notes from yesterday and today: [PASTE NOTES, COMMIT MESSAGES, TICKET NUMBERS, WHATEVER YOU HAVE] Team format: [yesterday, today, blockers] or [shipped, in progress, need help] Channel and who reads it: [#standup, my team plus my manager] </context> <task> Turn this into the daily standup post. Convert ticket numbers into plain descriptions of what the work does, state blockers as a specific ask with a named person, and cut anything that is just activity with no outcome. </task> <format> Slack post under 80 words in my team format, blockers last and phrased as a direct request to a named person. </format>

<context> Everyone's individual updates from the week: [PASTE ALL THE STANDUP POSTS OR REPLIES] Team: [names and what each owns] Who reads the roll-up: [my manager, department head, whole company] </context> <task> Merge these into one team update. Group by workstream rather than by person, note where two people worked on the same thing, and surface any blocker that appeared more than once during the week as a pattern rather than an incident. </task> <format> Post with a two-line summary, then one section per workstream with progress and status, then a Recurring Blockers section, then Next Week. </format>

<context> Project: [name, goal, deadline] Progress against plan: [what is done, what is behind] Risks: [known risks and their likelihood] Current colour I would give it: [green, amber, red] Who reads it: [stakeholders] </context> <task> Write the status post and challenge my colour rating first. If the evidence I gave points to amber and I said green, say so and explain what would have to be true for green to be honest. Then write the post using the defensible colour. </task> <format> Short challenge paragraph first, then the post: Status colour with one line of justification, Done This Period, At Risk, Decisions Needed From You, Next Milestone with date. </format>

<context> What we demoed: [list of items with who built each] Feedback given in the demo: [paste notes or chat] What did not make the sprint and why: [items] Audience: [team, stakeholders, whole company] </context> <task> Write the recap for people who missed the demo. Describe each item by what a user can now do, credit the builder by name, capture feedback as concrete follow-ups with owners, and be plain about what slipped without a defensive explanation. </task> <format> Post with a Shipped list (one line each, builder named), a Feedback And Follow-Ups list with owners, a Did Not Make It list with one-line reasons, and a link placeholder for the recording. </format>

<context> Blocker: [what is stopping the work] What I already tried: [attempts and outcomes] Who I already asked and when: [names, dates] Cost of it staying blocked: [delay, money, customer impact] Who I am escalating to: [name and role] Decision or resource I need from them: [specific ask] </context> <task> Write the escalation message. Prove I exhausted the normal path before escalating, quantify the cost of continued delay, and end with one decision they can make in under a minute. No blame directed at the person who did not respond. </task> <format> Message under 120 words: the ask first, then Tried Already as three bullets, then Cost Of Waiting as one line, then a yes or no question. </format>

<context> Dates I am away: [dates] What I own that runs while I am out: [projects, recurring duties, approvals] Who covers what: [name per area, confirmed or not] Things that might blow up: [known risks and what to do] Reachability: [not at all, emergencies only, and what counts as an emergency] </context> <task> Write the handover post for my team channel and a matching Slack status text. Make coverage unambiguous per area, define what an emergency actually is, and list the decisions that should simply wait until I am back. </task> <format> Post with a coverage table (Area, Cover, How to reach them), an If This Happens list, a Can Wait Until I Return list, and one Slack status line under 100 characters with a suggested emoji. </format>

<context> Two weeks of standup posts across teams: [PASTE THE POSTS] Teams involved: [names] Leadership audience: [who reads it and what they care about] Company priorities this quarter: [list] </context> <task> Write the digest for leadership. Map activity to the stated priorities, call out work that maps to nothing on that list, surface blockers only leadership can clear, and keep individual detail out unless it changes a decision. </task> <format> Digest under 250 words: Progress Against Priorities, Work Not Tied To A Priority, Blockers Needing Leadership, Trend Worth Watching. </format>

<context> Channel name: [#name] What actually gets posted there today: [paste a few sample messages] What it should be for: [intended scope] What belongs elsewhere: [the channel it should go to instead] </context> <task> Write the channel description and the topic line. The description defines scope and who should join, the topic carries the one thing a visitor needs right now. Include an explicit line about what does not belong here and where it goes. </task> <format> Two blocks: Description (under 250 characters) and Topic (under 250 characters). Then one suggested pinned message explaining how to use the channel. </format>

<context> Current channel list: [PASTE THE LIST OF CHANNEL NAMES] Company shape: [teams, functions, regions, clients, projects] Headcount and growth: [current, expected in a year] Problems today: [cannot find channels, duplicates, unclear ownership] </context> <task> Design a naming convention with prefixes that will still work at double our size. Map every existing channel to its new name, flag names that reveal confidential client or project detail, and list the renames that are not worth the disruption. </task> <format> Convention rules with examples, then a migration table: Current name, Proposed name, Rename or leave, Reason. </format>

<context> Channel export or list with stats: [PASTE CHANNEL NAME, MEMBER COUNT, LAST MESSAGE DATE, MESSAGES PER MONTH] Workspace size: [members] Retention rules we have: [any] </context> <task> Classify each channel as keep, archive, merge, or convert to a private channel, using activity and overlap in the names as evidence. Where you suggest a merge, say which channel survives. Flag any channel with one member and any duplicate pair. </task> <format> Table: Channel, Verdict, Reason, Merge target if any. Then a short paragraph on the pattern behind the sprawl. </format>

<context> Workspace size and timezones: [members, regions] What triggers a broadcast ping today: [paste real examples, good and bad] Complaints we get: [too many pings, missed urgent things, both] Culture we want: [async first, fast response, mixed] </context> <task> Write the notification policy. Define exactly when @channel is justified, when @here is, and what to do instead the rest of the time. Include what to do if something is genuinely urgent outside working hours, and make the rule specific enough to point at when someone breaks it. </task> <format> Short policy: When to use @channel (max three cases), When to use @here, Use instead of a broadcast, Genuinely urgent out of hours. Then a two-line version for a channel pin. </format>

<context> Team spread: [timezones and rough overlap hours] Current expectations, spoken or not: [what people actually assume] Problems: [evening pings, weekend messages, people feeling always on] Roles with genuine on-call duty: [who] </context> <task> Write the norms doc. Define response time expectations by message type, state that a message sent outside someone's hours does not carry an expectation of reply, and name the one escalation path that does mean drop everything. </task> <format> Doc with: Core overlap hours, Response expectations by type (DM, mention, channel post, on-call page), Sending outside hours, The one real escalation path. Then a Slack post announcing it. </format>

<context> Channels a new [role] should join: [list with one-line reasons] Our conventions: [threading, emoji meanings, naming, status use] Tools connected to Slack: [list] Things new joiners always get wrong: [paste real examples] </context> <task> Write the onboarding guide a new hire reads in their first hour. Cover which channels to join and why, how we thread, what our emoji reactions actually mean, and the unwritten rules that only show up when someone breaks one. </task> <format> Guide with sections: Join These First, How We Thread, What Our Emoji Mean, Unwritten Rules, Who To Ask What. Short enough to fit in one Slack canvas. </format>

<context> Channel being archived: [#name, what it was for] Why: [project ended, merged, dead] Where the conversation continues: [#other-channel or nowhere] Content worth keeping: [decisions, docs, recurring answers] Members: [how many, who will notice] </context> <task> Give me the archive plan. List what should be extracted into a document before archiving, write the farewell message that redirects people, and write the pinned note that explains where things moved for anyone who lands there later from an old link. </task> <format> Three parts: Extract Before Archiving as a checklist, the farewell post, and the final pinned message. Keep both messages under 60 words. </format>