A reading room for the changelogs of every tool you depend on

Build me a reading room for the changelogs and release notes of every third party API and SaaS tool our product depends on, so my engineers stop finding out about deprecations from a production outage. The app keeps a watchlist of vendor changelog pages, refreshes them when someone opens it, and shows each one with an unread count, an assigned owner, and the entries that are new since that person last read it.

The main view is the watchlist: one row per watched vendor showing the product name, the changelog page being watched, the engineer who owns it, my personal unread count, when it was last checked, and the classification of the newest unread items (breaking, deprecation with a deadline, or informational). Each row also shows any Linear issues already raised against that vendor, fetched with the Linear List Issues action filtered by the vendor name, so nobody opens a ticket that already exists. Sort so vendors with unread breaking changes come first, then vendors with a stated deprecation deadline (soonest deadline first), then everything else by unread count.

When I open the app, refresh every watchlist entry with the Firecrawl Scrape URL action against its stored changelog URL, taking the page as markdown. The app owns the stored snapshot: compare the fresh scrape against the snapshot saved on the previous check, split the page into dated entries (title, date, body text), and persist any entry that was not present in the previous snapshot as a new entry stamped with the time it was first seen. Then save the fresh scrape as the new snapshot. Refreshes should run in parallel with a per vendor status so one slow or failing page does not block the rest, and a vendor whose page cannot be read should show a clear could not read this page state on its row rather than silently looking unchanged.

Read state is per person, not per team. Store a read marker for each viewer and each vendor, and compute the unread count as the entries first seen after that viewer's marker. A Mark as read button in the vendor detail view moves only my own marker. This is the whole point of the surface, so two engineers do not both triage the same release. Show on the row who else has already read the current entries.

Adding a vendor should be easy: I type a product name into an Add vendor box and a background agent finds the page for me. The agent uses the Firecrawl Search Web action to locate the vendor's official changelog or release notes page, and the Firecrawl Map Website URLs action on the vendor's domain to list candidate paths (changelog, releases, release notes, updates, what is new), then scrapes the best candidate with Firecrawl Scrape URL to confirm it really contains dated entries. It proposes one URL with a short reason and one or two example entries it found, and I confirm or reject before anything is added. On confirmation, ask me who owns it, save the entry, and take a first snapshot as the baseline so I do not get a flood of a hundred historical entries marked unread.

Opening a vendor shows the new entries since my last read in plain readable text, newest first, with the date and full body of each, plus any impact note the app has already written. Older, already read entries stay available below in a collapsed list. Include a link out to the source page and an Assess impact button at the top.

Assess impact kicks off a background agent that reads the new entries for that vendor and, for each one, decides whether it is a breaking change, a deprecation with a deadline, or merely informational, pulling out the stated deadline date where there is one. It writes a short plain English impact note back into the app against the vendor and against each entry, saying what changes, who it affects, and what we would have to do about it. For anything genuinely breaking it files a Linear issue with the Linear Create Issue action, titled with the vendor and the change, described with the impact note and the deadline, and assigned to the owner of that vendor, then attaches the source changelog page to that issue with the Linear Add Link to Issue action. Before filing, it checks the issues already listed for that vendor with Linear List Issues and skips anything already raised. Be conservative: informational entries get an impact note only and never a ticket. Show the run in progress on the vendor row and refresh the view when the notes and issues land.

A Share button composes the week's real changes: every vendor with new entries in the last seven days, grouped by vendor, each with its classification, its deadline where there is one, its owner, a link to the source page, and any issues raised. Post it to our engineering channel with the Slack Bot Send a Message action, letting me pick the channel and review the message before it goes. If nothing actually changed this week, say so in one line rather than posting an empty digest.

Persist the watchlist (product name, changelog URL, owner, date added), the latest page snapshot per vendor, the derived entries with their first seen timestamps, per person read markers, and the impact notes. Every watched vendor needs a named owner, so show unowned vendors with a prompt to assign one and use that person as the default assignee on issues filed from that vendor. Nothing in this app runs on a schedule: the refresh happens because a person opened it, and the agents run because a person pressed a button.