GitHub + Slack: A Daily AI Pull Request Digest Instead of 200 Notifications

The standard GitHub and Slack integration forwards events: opened, commented, approved, merged, failed. For a team of eight that's a channel nobody reads by Wednesday, and the pull request that has waited three days for review scrolls past with everything else. This recipe replaces the stream with a morning digest. An agent reads your repositories, works out what actually needs someone, and posts one message to your team channel.

What you get

At 9:00 every weekday, in #eng:

PR digest, Tue 29 Sep. 3 need review: #482 Retry webhook delivery (Dana, waiting 2 days, reviewer: Sam), #487 Drop legacy auth path (Lee, 1 day, no reviewer assigned), #489 Fix CSV export encoding (Sam, 4 hours). 1 approved, not merged: #475 (Ana, approved yesterday). 1 failing checks for 2 days: #470 Upgrade Postgres driver (integration tests). Stale over 5 days: #455. Shipped yesterday: 4 PRs, including the new billing page and the rate-limit fix.

Each item links to its pull request. The agent also saves the digest to your drive, which gives you a running record to write release notes from.

Step 1: Connect GitHub and Slack

In Integrations, connect GitHub (choose the organization and repositories) and Slack. Damon discovers each tool's actions when you connect and classifies them:

• GitHub: listing and reading pull requests, reviews, commits and check runs are reads, auto-approved by default. This recipe doesn't use GitHub's write actions (commenting, merging, labeling), which require approval.
• Slack: posting a message is message.send, which requires approval by default. Step 3 covers loosening that.

Step 2: Run it once in chat

For the repos api and web: list open pull requests. Group them: waiting on review over 24 hours (who's the reviewer), no reviewer assigned, approved but not merged, failing checks, and no activity in 5+ days. Then list what merged in the last 24 hours, one line each. Name authors and PR numbers, no adjectives, under 150 words, and link every PR. Show me the message before posting it to #eng.

Tune the groups and thresholds to your team. Some teams care about draft PRs, others ignore them. Once the output is right, save the format as a skill so the same rules apply when anyone asks Damon about PRs in chat.

Step 3: Make it daily

The workflow:

1. Trigger: every weekday at 9:00.
2. Agent step:

• Builds the digest as above for the repositories named in the step.
• Saves the digest to Engineering/PR digests/<date>.md.
• Posts it to #eng.

3. Message step: opens a thread with you containing the same digest, so it's also in Damon, where you can ask follow-ups ("what's blocking #470?").

Two permissions are involved. Saving to the drive is file.write. Posting to Slack is message.send. Both require approval by default, so as it stands the digest would wait for your click every morning. For this workflow, auto-approve both. The digest goes to your own team's channel, which is the kind of send that's reasonable to automate. Policies apply per step, per workflow or workspace-wide, not per channel, so the channel is fixed in the step's instructions and the auto-approval covers only this workflow: Damon still asks before posting from chat or from any other workflow.

After cloning the template, set the repositories and channel in the agent step's instructions.

Variants

• Friday release notes. Add a weekly workflow that reads the week's digests in Engineering/PR digests/ plus the merged PRs, and drafts release notes grouped by feature, fix and internal change into Engineering/Release notes/. Keep it as a draft for a person to post.
• Nudges for reviewers. Send each person with a PR waiting on them a direct message instead of posting in the channel. Each DM is a message.send, so start with approval on and see whether the team wants it.
• Issues too. Connect Linear and add "issues moved to In Review with no linked PR" to the digest. The weekly status report recipe covers the project-management side.
• Keep the event stream. Keep the GitHub app's notifications for your own PRs and use the digest for the team view. They complement each other.

Common questions

Can it review the code?

It can read a pull request's diff when you ask in chat ("summarize the risk in #482"), and that's a useful first pass. This recipe deliberately doesn't comment on PRs: that's a GitHub write, and a comment from an agent in every PR is its own kind of noise.

Does it need access to all our repositories?

No. Grant GitHub access to the repositories the digest should cover, and name them in the step instructions. The agent reads only what the connection can see.

Will it post anything besides the digest?

The instructions post one message to one channel. The auto-approval is for message.send within this workflow, so keep the step's instructions narrow, or set the policy on the agent step alone rather than the whole workflow. Outside this workflow, every post asks first.

What about GitLab?

GitHub is what ships today. For GitLab, ask us, or bring it in through an MCP server.