AI Digest from Official Sources

An installable agent skill that gathers announcements, changelogs, model cards, and release notes from first-party AI company channels — and returns a linked, factual digest. It keeps collection separate from interpretation so readers can inspect the source and decide what matters.

01The product boundary

Trace a typical AI digest back to its origin and it runs four hops: the company publishes something, a trade outlet writes it up, an aggregator summarizes the write-up, a newsletter summarizes the summary. Each hop drops technical detail and adds framing. The result is often delayed and shaped by downstream editorial priorities.

This project skips the chain. Two rules define it.

Input: official sources only. If a company did not publish it on its own channel, it does not go in. No trade press, no aggregators. This has a real cost — leaks, investigations, and unannounced changes are permanently out of scope. I accept that trade, and in exchange every line traces to something a company put its own name on.

Output: traceable facts, not interpretation. Every item keeps the company, publish date, direct link, and a short factual description. The skill does not rank announcements or tell the reader what they mean. That boundary is the central product decision.

Source architecture

Once "official sources only" is the rule, the question is what counts as official. Sources are grouped by what kind of claim each one can support:

The technical tier is the most useful and the least read. A changelog is the least promotional document a company produces — it exists to serve developers. Model names often appear there before the announcement post.

02Auditing the source layer

I audited the initial source registry in September 2026. The table below is a representative nine-source sample from the 18 official channels now tracked. Feed availability and page access change, so these are dated observations rather than permanent guarantees.

In this sample, six of nine sources exposed a usable feed. The other three had to be read as web pages. Company sites change structure, so the skill supports both collection methods and records source-specific quirks instead of assuming one route works everywhere.

03How it's built

From a weekly to a reusable source layer

The project began as AI Signal Weekly: a recurring editorial workflow. The reusable part turned out to be the source-collection layer underneath it. Separating that layer into an installable skill made the immediate job simpler — gather what the labs published — while keeping the newsletter as an optional publishing path.

Two layers, kept separate

The repo contains two things, and they are deliberately not combined:

• The collection layer — SKILL.md and sources.json. Reads the sources, returns a list. This is what most people install.
• The write-up layer — AGENTS.md, the static site, a worked example issue. Only needed if someone wants to publish a newsletter from the collected list.

Keeping them separate follows from the second rule. Collecting is the product; writing it up is an optional extra step, and bundling them would have meant the tool does interpretation by default.

Collection methods

sources.json tags each entry with how to read it. Feeds are fetched and parsed. Pages without feeds are fetched as HTML, with the index read first and individual posts second. Social sources are read only when the host agent has authorized platform access; otherwise they are skipped and disclosed. The skill does not scrape or silently substitute a third-party account.

What was left out

Trade press, excluded rather than demoted. The alternative was to keep it as a "context only, never lead" tier. A tier that exists but must never be cited will get cited eventually.

Instagram. Meta's API cannot read accounts that have not authenticated into your own app. But the access difficulty was not the deciding factor. What AI companies post on Instagram is visual presentation. My judgment was to stay with the launch post on the company's own site.

What shipped

• An installable skill — packaged for Claude and Codex, with no required API keys.
• A source registry — 18 official channels plus official X accounts, in plain JSON so anyone can add or remove entries without touching code.
• An editorial rulebook — for the optional write-up layer: structure, voice, what belongs where.
• A worked example issue and static site — plain HTML and CSS, no build step, deploys to GitHub Pages.
• A personalization script — replaces names, handles, and links in one command, plus a checklist for the metadata a script cannot infer.

04What would change with real usage

The current design assumes one person running it. Three things would need to change:

• Shared collection. Right now each installation reads every source itself. A single scheduled job publishing a static feed would mean less duplicated fetching and fewer requests hitting each company's servers. The trade is a single point of failure.
• Separating collection from delivery. Both happen in one pass today, so the collection window determines how often you can read. Continuous collection with an on-demand read would decouple them.
• Knowing what gets read. Source selection is currently based on my judgment with no feedback. Which links people actually click would be a better guide to what belongs in the list than my reasoning about it.