# Plan every library upgrade across all your repositories

> See which libraries every repository is stuck on, get a migration brief written from real documentation, and track who owns each upgrade.

- Workflow type: app
- Services: Context7, GitHub, Linear
- Categories: Engineering, Operations
- Published: 2026-08-17

## What it does

- Pick the repositories you care about from your GitHub organisation and see one combined table of every library they depend on, with the version each repository is pinned to
- Shows how many repositories sit on each version of a library, so you can see instantly where your codebase is fragmented and which upgrades touch the most teams
- Select any library to get a migration brief covering breaking changes, renamed or removed APIs and the recommended upgrade path, written from the real documentation for both the version you are on and the version you are moving to
- Set a status and an owner on every library and file a Linear issue with one click, so the plan you make in a session is still there the next time you open it

## What you'll need

- A GitHub account with access to your organisation and the repositories you want to review
- A Context7 account, which supplies the version specific documentation behind each migration brief
- A Linear workspace, so you can turn any upgrade into a tracked issue
- Repositories that use a Node style dependency list, since that is what the board reads to build the table

## Prompt

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.

## How to customize

- Change which repositories are in scope at any time, so you can plan for one team's services or the whole organisation
- Set the target version per library instead of accepting the newest one, which is useful when you are deliberately moving one major version at a time
- Adjust the default sort and filters, for example starting from the libraries you own rather than the ones affecting the most repositories
- Choose which Linear team upgrade issues are filed into

## FAQ

### How is this different from a tool that reviews upgrade pull requests?

A pull request reviewer reacts to one version bump at a time, after a bot has already raised it. This board is the opposite. You open it during planning to survey many repositories at once, see where you are fragmented, decide what is worth doing, and assign owners before any pull request exists.

### Where do the breaking changes in the migration brief come from?

They come from the actual published documentation for the specific versions involved, retrieved for both the version you are pinned to and the version you are moving to. The source snippets are shown underneath the brief so an engineer can check the reasoning rather than take it on trust.

### Do my statuses and owners stick around after I close the app?

Yes. Status and owner are saved in the app, so the board reflects your last planning session when you come back to it. That is the point of the board rather than a one off report.

### What happens if a library has no documentation available?

The board tells you that no documentation library was found for that package and skips the brief for it. It will not invent an upgrade path. You still see the version spread across your repositories and can plan the upgrade manually.

### Can I review private repositories?

Yes, as long as the GitHub account you connect has access to them. The board only reads the repositories you select.

Use this prompt in General Input: https://www.generalinput.com/prompts/plan-every-library-upgrade-across-all-your-repositories