Introducing the What's New page

With the modular architecture of OpenEverest v2 we ended up with a good-to-have problem: new providers and plugins, each with their own release cadence. We needed a way to tell users that new releases are out — not just for the core product, but for all of these components too.

We first tried to solve this with a blog post — OpenEverest Pulse: August 2026. The problem with that approach is that it does not scale. With more than 15 plugins and providers today it is already easy to miss an interesting feature or update. What happens when there are hundreds?

That is why we introduced the What’s New page. To be frank, we borrowed the idea from aws.amazon.com/new: concise feature updates that cover the breadth of the product lines, all in one place, with filters and an RSS feed to subscribe to.

Under the hood

The interesting part is how these pages are built. Manually watching the releases of the core, every provider, and every plugin does not scale either. Good thing we live in the age of AI.

We built a skill that our OpenClaw bot runs every day. It scans for new releases of OpenEverest and of every extension listed in the Hub, then turns each user-facing change into its own announcement. It works as a three-stage pipeline where two deterministic scripts bookend a single AI step:

1. Fetch. A lightweight script queries GitHub for releases published that day — the core repo plus every extension in the Hub index — and writes a compact manifest.
2. Decide and write. The LLM reads the release notes and splits them into individual customer-facing features, writing one concise, AWS-style page per feature. This is where judgement matters: dependency bumps, refactors, and CI chores are skipped, and only user-facing changes make the cut.
3. Open the PRs. Another script stages the pages and opens one pull request per page, so each announcement can be reviewed and merged independently.

Large Language Models are used only where judgement is needed — to write the announcement and to dig deeper when a release is thin on detail. When an issue or pull request referenced in a release does not explain the change well enough, OpenClaw reads the code itself and decides whether it is worth announcing and how to describe it.

Once the pages are ready, the PRs are opened for review. Maintainers review, edit where needed, and merge — nothing is auto-published.

And of course there are filters on the page and an RSS feed to subscribe to changes.

We would love to hear what you think and how this can be improved.