I tried automatically generating daily recaps for Slack channels using Claude Cowork's scheduling feature

Introduction

In our project's Slack channels, various discussions progress within threads every day. However, it's difficult to keep track of information scattered across multiple threads, especially in cases where "there was a new reply to an old thread yesterday," which is easy to miss.

Therefore, I created a system that uses Claude Cowork's scheduling feature (cron) to automatically generate and post daily recaps of Slack channels every morning. I found it interesting that I was able to achieve this without writing a single line of code, just by refining requirements through conversation, so I'd like to introduce the process and key points.

What I Created

A bot that automatically summarizes the previous day's Slack channel activity every weekday morning at 9 AM and posts it to the channel in the following format:

Features include:

• Cross-monitoring of 2 channels: internal and client channels (Slack Connect), automatically merging identical topics
• Captures new replies to old threads without missing any
• Topic-by-topic display of channel source tags (internal ch / client ch / both)
• Output is posted only to the internal channel (not posted to the client channel)
• All recap content is in Japanese

Prerequisites/Environment

• Claude Desktop (with Cowork functionality available)
• Slack integration (Claude Desktop's Slack MCP connector) enabled
• Access rights to the Slack channels being monitored

Setup Process

1. Confirming Slack Integration

Claude Cowork has a Slack MCP connector that allows reading channels, sending messages, searching, etc. I'm using the following tools:

2. Designing the Task through Dialogue with Claude

Claude Cowork's scheduling feature allows you to create cron tasks just by explaining "what you want to do" in natural language. I refined the requirements through the following interactions:

First, I communicated what I wanted to do:

"I want to add a cron to read yesterday's threads and create a channel recap. I'd like it to include summaries and action items, and output in Japanese."

Claude responded with questions about execution time, posting destination, and thread handling, to which I answered:

• Execution time: Weekdays at 9 AM (JST)
• Posting destination: Same channel as the summary source
• Threads: Read all thread replies

With just this, the first version of the cron task was created.

3. Discovering and Fixing Problems with a Dry Run

When executing the first version, I discovered a problem: new replies to old threads were not being captured.

There were two causes:

Problem 1: Using slack_search_public for searching private channels

Since the target channel was a private channel, slack_search_public returned 0 results. I resolved this by changing to slack_search_public_and_private.

Problem 2: Channel timeline alone cannot catch replies to old threads

slack_read_channel returns the timeline of top-level messages in a channel, so replies posted yesterday to past threads are not included.

To solve this, I adopted a method that combines two approaches:

For thread replies found through Approach B, I use slack_read_thread to get the parent message and include it in the summary after understanding the context.

The actual difference this modification made was significant. On one test day:

• Approach A only: 1 item (top-level message)
• Approach A+B: 49 items (including thread replies)

4. Adding Client Channels

I added client channels connected via Slack Connect to the monitoring targets, in addition to internal channels. Key points:

• If the same topic is being discussed in both channels, merge them into a single section
• Display channel source for each topic (internal ch / client ch / both)
• Output is limited to internal channels only (never post to client channels)

This created a recap where you can see at a glance "what the client approved" and "what was discussed internally."

5. Improving Output Format

In the first version, the summary was compiled into one long paragraph, which was difficult to read on Slack. I made the following improvements:

• Divided topics into sections, visually distinguished by emoji markers
• Clarified structure with dividing lines (━━━)
• Made each topic scannable with a 1-2 line overview + bullet points
• Standardized staff names as "last name + san" (matching the natural tone of the team's Slack)
• Expressed action items with → for visual flow

📋 *〇〇 Project Daily Recap (YYYY/MM/DD)*

━━━━━━━━━━━━━━━

📩 *[Topic name]* `client ch` ([Context])
[1-2 line overview]
• [Point 1]
• [Point 2]

🏠 *[Topic name]* `internal ch` ([Context, e.g., continuation of 3/18 thread])
[1-2 line overview]
• [Point 1]
• [Point 2]

🔗 *[Topic name]* `both` ([Context])
[If the same topic was discussed in both channels, merge them under one heading]
• [Point 1 — from customer channel]
• [Point 2 — from internal channel]

━━━━━━━━━━━━━━━

✅ *Action Items*
• *[Last name]-san* → [Action content]
• *[Last name]-san* → [Action content]
(If none, write "None")
---

Scheduled Task Configuration

Overview of the final cron task:

Scheduled tasks can be checked and managed from the Claude Desktop sidebar, with manual execution via "Run now." After approving Slack MCP tool permissions during the first execution, no approval prompt appears for subsequent automatic executions.

Points of Consideration and Challenges

Handling Private Channels and Slack Connect

Slack MCP has two search tools: slack_search_public and slack_search_public_and_private. For private channels or Slack Connect channels, you must use the latter. Initially, I wasn't aware of this difference, resulting in 0 search results.

Necessity of Pagination

In active channels, messages from a single day may not fit into one page of search results (20 items). As long as pagination_info returns a cursor, you need to continue retrieving the next page.

Skipping Days without Activity

There's no point in posting recaps on holidays or days without activity, so if there are 0 human messages (excluding bot messages and automatic notifications), posting is skipped.

Conclusion

Using Claude Cowork's scheduling feature, I created a system to automatically generate daily recaps of Slack channels.

By communicating requirements through dialogue and repeating the cycle of discovering and fixing problems through dry runs a few times, I completed a practical Slack bot without writing a single line of code. In particular, the problem of "capturing replies to old threads" was something I wouldn't have noticed without actually doing a dry run, which highlighted the strength of the interactive development process.

In the future, I plan to consider improving recap accuracy (filtering unnecessary information, automatically following up on action items, etc.) and expanding to other channels.