A technology radar board your architecture group works out of

Build me a technology radar board that our architecture review group works out of. The board has four rings, and every library we care about sits as a card in exactly one of them. Show the ring definitions as help text on the board so newcomers read the same rules we do: Adopt means high confidence, widely used in production, low risk. Trial means proven on real projects but knowledge and support are limited to a small group. Assess means worth investigating. Hold means we trialled it and do not recommend it, or it is legacy and high maintenance in production.

The main view is the radar board itself. Each card shows the library name, the ring it is in, its category (things like ORM, queue, auth, frontend framework, observability), the owner from our group, and the date it was last evaluated. I want to drag a card from one ring to another and pick an owner from a dropdown, and both of those need to save in the app so the placement sticks for everyone. Ring placement, owner, category, evaluation text and evaluation date are all app side persistence, not writes to any connected tool. Let me filter the board by category and by owner, and show a count per ring.

To add a library, I type its name and the app resolves it against Context7 using Search for Libraries, showing me the matching library IDs so I can pick the right one. Store that library ID on the card along with the GitHub repository behind it in owner/repo form. Use GitHub List Organization Repositories to let me pick our own organization once in settings, so the code search below knows where to look.

Opening a card gives me a live picture of that library, fetched when the card opens rather than from a stale copy. From Context7, use Get Documentation Context against that library ID to pull what the library actually does and its core API surface, asking a specific evaluation question rather than a vague one. From GitHub, use Get a Repository for stars, last push date, open issue count and whether it is archived, Get Repository Community Profile for the health score and which community files exist, Get Repository License for the license it carries, and List Repository Issues for recent issue activity so I can see whether maintainers are responsive or the tracker is a graveyard. Lay all of that out as a readable panel, not a JSON dump.

The same card also has to tell me where we already use this library today. Use GitHub Search Code scoped to our organization, searching for the package name in import statements and manifest files, then group the hits by repository and show which repositories touch it and how many matches each has. If there are no hits, say so plainly, because a library nobody uses yet is a very different conversation from one that is already load bearing.

Put an Evaluate this library button on the card that kicks off a background agent. The agent gathers everything above, then does the part a person would do: it compares this candidate against the other libraries already sitting in the same category on our board, for example the other ORMs or the other queues or the other auth libraries, using their stored details and their own repository stats. It then writes a recommendation back onto the card containing a short verdict, the risks, license notes, how it stacks up against the alternatives we already have, and a suggested ring. Save that write up on the card so the whole group can read it, stamp the card with the evaluation date and who ran it, and show a clear running state on the button while the agent works.

A second button, Record the decision, kicks off an agent that writes an architecture decision record into our Notion decisions database using Create a Page. The record follows the standard shape: context (what we were choosing between and why it came up now), the decision (which library and which ring), and the consequences (what this commits us to, what it rules out, what we will have to revisit). It should draw on the evaluation already on the card rather than starting from scratch. When the page comes back, save its URL on the card and show it as a link, so the card and the decision record always point at each other.

Flag staleness prominently. Any card whose last evaluation date is more than a quarter old gets a stale badge, and cards that have never been evaluated are marked as never reviewed. Put a count of stale cards at the top of the board and let me filter down to just those, because a radar is a timeboxed inventory and it only works if it gets re-reviewed on a cycle.

Finally, give me a compare view. I select two or three cards in the same category and see them side by side in columns: ring, owner, what the library does, stars, last push date, community health, license, how many of our repositories already use it, and the headline of the latest recommendation. This is for the moment in a review session when the group is deciding between real candidates, so keep it dense and readable on one screen.

The audience is architects and staff engineers during planning cycles, so keep the tone and the copy aimed at people making an adoption decision. Nothing here writes to GitHub, and the only thing written outside the app is the Notion decision record.