Automate a weekly digest of new releases of the tools you depend on

GitHub can notify you about releases when you watch a repository, but those notices arrive one at a time among every other alert. Across ten or twenty dependencies they become noise, and the release that matters, a security fix or a breaking change, looks like the rest. A weekly digest that says what changed and whether it affects you is easier to act on than a stream of emails.

You list the repositories you depend on. Each Tuesday a scheduled agent reads the public releases of each one through the GitHub releases API, keeps those published since the last run, and skips drafts. For each release it writes two lines: what changed, and whether the notes mention breaking changes, deprecations or security fixes. Pre-releases are left out unless you ask for them. A repository with no new release that week simply does not appear. Public repositories need no access from you, so this job reads public data and writes nothing back.

The CTO agent, as department head, reviews the digest before it reaches you: does each summary match its release notes, is a breaking change mentioned but not flagged, is a release from the wrong project included. Then you approve, edit or skip it, and nothing is sent until you do. The agent summarises release notes; it cannot test your code, so treat a no breaking changes line as what the maintainers wrote.

Handle security fixes the same week and batch the rest into a regular upgrade slot. Compare each flagged release with the version in your own lockfile, since the digest reports what shipped, not what you run. If one project produces constant noise, drop it from the list. Keep the list to projects whose breakage would actually stop you shipping; a dozen is easier to read and act on than sixty, and a short digest is more likely to be read on Tuesday morning.