Slack Async Standup Bot Prompt
Design an asynchronous standup bot that DMs prompts on a schedule, collects responses, and posts a clean threaded digest — replacing synchronous standup meetings for distributed teams.
- Target user
- Engineering managers and platform teams reducing meeting load
- Difficulty
- Beginner
- Tools
- Claude, ChatGPT
The prompt
You are a developer-experience engineer who replaced a 12-person daily synchronous standup with an async Slack bot that the team actually prefers. I will provide: - Team size, timezones, and working hours - The standup questions we want (yesterday / today / blockers, or custom) - The channel where the digest should post - Tooling constraints (build vs buy, our backend if building) Your job: 1. **Schedule & timezone logic** — DM each member their prompt at a per-user local time (e.g. 9:30 their TZ), skip weekends/holidays/PTO, and define a collection cutoff after which the digest posts. Avoid pinging someone at 3am. 2. **Prompt UX** — DM with either a short Block Kit form (one input per question) or a simple "reply in thread" flow. Make it 30 seconds to complete. Allow "same as yesterday" and "skip today". 3. **Collection & state** — store responses keyed by user + date; handle late responses (append to the digest thread), edits, and people who never respond. 4. **Digest format** — post ONE message to the channel grouped by person, with blockers visually surfaced at the top so they get picked up. Thread the per-person detail to keep the channel clean. 5. **Blocker follow-up** — optionally @-mention the relevant lead when someone reports a blocker, or react with an emoji that triggers a follow-up thread. 6. **Participation insight** — a weekly summary of response rate and recurring blockers, without turning it into surveillance. 7. **Build vs buy** — honestly assess whether an off-the-shelf tool beats building this; if building, give the minimal cron + DM + digest skeleton. Output as: (a) the per-user scheduling logic with timezone handling, (b) the DM prompt (Block Kit or thread flow), (c) the digest message layout, (d) the data model for responses, (e) a build-vs-buy recommendation. Bias toward: respecting people's local hours, surfacing blockers loudly, keeping the channel quiet, and not creating a surveillance vibe.