Plan every library upgrade across all your repositories

I want an upgrade planning board that shows which libraries our repositories are behind on and what it would actually take to move each one. This is the surface I open during an upgrade planning session to survey the whole portfolio at once, assign owners and track progress. It is deliberately not a pull request reviewer, so do not build it around a single version bump or a bot raised pull request.

When I open the board I pick which repositories to include from our GitHub organisation, listed with List Organization Repositories. Remember my selection between sessions so I do not have to choose again every time, and let me change the selection later.

For each selected repository, read its package.json with Get a File and decode the Base64 content that GitHub returns. Combine everything into a single table with one row per library, showing the version each repository pins and a count of how many repositories sit on each distinct version, so I can see at a glance how fragmented we are. If four repositories pin the same library at three different versions, the table should make that obvious without me doing the arithmetic.

Selecting a library opens a detail view. Resolve the library name to a Context7 library ID with Search for Libraries, then pull version specific documentation with Get Documentation Context twice, once for the version we currently pin and once for the target version. A Context7 library ID is a path like /vercel/next.js and a version is appended with a slash or an at sign, for example /vercel/next.js/v15.1.8, so build the versioned ID from the resolved ID rather than guessing it. Default the target version to the newest version Context7 lists for that library, and let me override it when we are deliberately moving one major version at a time.

From those two sets of documentation, present a migration brief covering breaking changes, renamed or removed APIs and the recommended upgrade path, with the source snippets Context7 returned shown underneath so an engineer can verify the brief instead of trusting it. Handle the two failure cases explicitly. If Context7 responds with a 301 canonical redirect, follow it to the new library ID. If it responds with a 404, show that the package has no Context7 library and skip the brief for it rather than inventing an upgrade path from memory.

Every row carries a status I set myself, one of Not started, Planned, In progress or Done, and an owner. Save both in the app so the board survives between planning sessions. Show status and owner in the main table, not only inside the detail view, because the table is what I run the session from.

Give me a button on each library that files a Linear issue with Create Issue, containing the migration brief and the list of affected repositories with the version each one pins. Let me pick the Linear team, populated with List Teams, and remember the team I used last. Once an issue is created, store its link on the row so I can see that library has already been filed and can jump straight to it.

Default the table to sort by how many repositories are affected, highest first, and give me a filter that shows only the libraries where the pinned version is behind the target version. I also want to filter by owner and by status so I can pull up just my own upgrades or just everything still Not started.