How to automate project updates from GitHub

Every software team owes somebody an update. A founder wants to know what shipped. A client wants to know what this week's invoice bought. And an engineering lead wants to know which pull requests are quietly going stale. In most teams, someone answers those questions by hand, again and again.

This guide is about automating that work with a digest instead of a notification stream. The example throughout is GitLoom: a Slack-first pull request notification tool that watches your GitHub repos and sends one quiet daily digest covering which PRs are stuck, what shipped, and what your team did this week.

Why updates keep getting written by hand

The raw material for a project update already exists. It is sitting in GitHub: merged pull requests, review comments, releases. The problem is translation. Turning "fix: race condition in webhook retry" into a sentence a non-engineer can read takes judgment, and doing it across a week of activity takes an hour or more.

So the update gets written manually, usually late in the week, usually by whoever feels most guilty about it. It tends to involve:

• Scrolling through merged PRs and trying to remember what mattered
• Rewriting technical language into plain English
• Checking whether anything is blocked, because someone will ask
• Formatting and sending the same information to different audiences

Why notifications are not the answer

The obvious first attempt is the official GitHub Slack app. Point it at a channel and every push, comment, review, and merge lands there in real time.

Anyone who has tried it knows how the story ends. The channel becomes a firehose, the firehose gets muted, and a muted channel is worse than no channel: everyone assumes the information is flowing while nobody reads it. Per-event notifications answer a question nobody asked ("what just happened?") instead of the questions people actually have: "what is stuck?" and "what shipped?" There is a quieter way to set up a GitHub Slack integration, and it starts with dropping the per-event firehose.

The digest model

A digest inverts the model. Instead of forwarding every event as it happens, it reads the activity, decides what deserves attention, and posts one short message on a schedule.

Two properties make this work where notifications fail. First, it is quiet by default: if nothing changed, no message is sent. Second, reminders are batched: an unchanged stuck PR comes up again after a few days, not every morning. The channel stays readable, so nobody mutes it.

Three reports that cover most updates

In practice, most of a team's update-writing collapses into three recurring reports.

Daily digest of stuck PRs

The short weekday-morning list above: PRs waiting on a first review, approved but unmerged, sitting on merge conflicts, failing CI, or simply forgotten. This is the internal report, for the team itself. (Full details: stuck PR alerts.)

Weekly digest

A plain-English summary of what the team shipped that week, written as prose rather than a list of commit messages. This is the one to share upward and outward: founders, clients, the rest of the company.

Release notes

Drafted automatically from merged work, whether you cut version tags or deploy continuously. Ready the moment someone asks what changed in this release.

GitLoom delivers all three to Slack, email, or Telegram, and each report accepts custom instructions (for example, "reference the Linear ticket IDs in PR titles") so the output follows your house style.

Setup takes about two minutes

1. Install the GitHub App and pick the repos to watch
2. Connect Slack (or email, or Telegram)
3. Choose a channel for each report

The first report arrives the next weekday morning. GitLoom detects your conventions on its own (version tags, a deploy branch, or continuous delivery to main), so there is no YAML to write, and you can send yourself a test report before the team sees anything. No code changes are needed, and GitLoom never reads your source code: it works from PR titles, commit messages, review comments, and metadata about which files changed.

Getting the most out of automated updates

• Write PR titles for readers: the digest quotes them, so "Add retry logic for failed webhooks" beats "fix stuff"
• Keep PRs small: small PRs get reviewed faster and summarize more cleanly
• Match each report to its audience: stuck PRs to the team channel, the weekly digest to the wider one
• Close or convert stale PRs to drafts: so the reminders that do arrive stay meaningful