Track every documentation source your team has indexed
Know what is in your documentation index, who owns each source, and how stale it has gone, then prove which sources actually answer real questions.
Context7EngineeringOperationsResearch & MonitoringBuild me an internal app that works as a registry for every documentation source our platform team has indexed into Context7. Right now nobody knows what is in there, who owns it, or how stale it has gone. The whole app runs on Context7. The fields Context7 does not track for us, meaning the owning team, a short description, and our spot check verdicts and notes, live in the app's own storage keyed by library ID.
The main view is a table of every indexed source, one row per source. Each row shows the source type (Confluence space, GitLab repository, Bitbucket repository, or llms.txt file), the Context7 library ID, when it was last refreshed, the owning team and short description from our own storage, and the current processing state. Use Search for Libraries to resolve and confirm library IDs. Let me sort and filter by type, owning team and staleness. Flag anything not refreshed in the last 90 days as stale, and flag any row with no owning team as unowned, since a source nobody owns is the one that rots first. Keep the staleness threshold defined in one place so it is easy to change.
An Add source form submits a new source by type. Give me a single form with a type picker backed by the four Context7 operations: Add a Confluence Space, Add a GitLab Repository, Add a Bitbucket Repository and Add an llms.txt File. Show only the fields that the chosen type needs, and capture the owning team and a short description alongside every submission, saving those to the app's storage against the returned library ID as soon as Context7 accepts the source. Add a Confluence Space requires a Confluence account connected on the Context7 side and a team project, so when that is missing, say exactly that in the form rather than failing silently.
Every row gets a Refresh a Library button. Context7 answers 202 Accepted while a library is still processing, so treat that as a real state and not an error: show the row as processing, keep checking, and move it to a finished state with a new last refreshed timestamp once it resolves. I want to watch that resolve on screen instead of guessing whether it worked. Show an in flight indicator on the row, disable that row's button while a refresh is running so nobody double submits, and surface rate limit responses with the retry hint rather than a generic failure.
Add a spot check panel. I type a question a new engineer would genuinely ask, pick two or three indexed sources, and the app calls Get Documentation Context once per selected source with that same question, then shows the results side by side in columns so I can compare what each one actually returns. Under each column, let me save a verdict (useful, thin, or useless) and a free text note, stored in the app against that source and question, so we build a record over time of which sources never return anything useful and can be retired. Surface the saved verdict history on the source's row or detail view, and make it obvious when a source returns nothing at all.
Show the current Teamspace Policies on the page as well, in a panel an admin can read before anyone tries to add a source that will be rejected. Pull it from Get Teamspace Policies and lay out which source types are allowed and which public repository filters apply. If a source type is disallowed by policy, disable that option in the Add source form and explain why, so the policy is visible at the moment it matters.
Several Context7 endpoints require the API key to belong to a member of the teamspace that owns the library. When a call comes back forbidden, show a clear permission message naming the source and what access is missing. Never leave a blank panel or an empty table that looks like there is simply no data. Keep this app to Context7 only. There is no second system here, and I do not want chat or ticketing bolted on to pad it out.
What does this prompt do?
- One table listing every documentation source your team has indexed, with its type, its owning team, and the date it was last refreshed, so stale and unowned sources stand out immediately.
- An add form for new sources, covering a Confluence space, a GitLab or Bitbucket repository, or an llms.txt file, with the owning team and a short description captured alongside each one.
- A refresh button on every row that shows the live processing state as it resolves, instead of leaving you to guess whether the refresh actually worked.
- A side by side spot check where you ask a real question, compare what two or three sources return, and save a verdict and note so you can retire the ones that never help.
What do I need to use this?
- A Context7 account and an API key for the workspace that holds your indexed documentation
- An API key belonging to a member of the teamspace that owns the sources, since some views and actions are restricted to members
- A Confluence account connected on the Context7 side, plus a team project, if you want to add Confluence spaces
- A rough idea of which team owns each source, so the registry starts out useful
How can I customize it?
- Change the staleness threshold so sources turn amber or red on whatever review cycle your team actually runs
- Adjust the verdict options or add your own fields next to each source, such as a review date or a backup owner
- Preload the spot check with the questions new engineers genuinely ask in their first week, so the panel is useful the moment someone opens it
FAQs
Where does the owner and description information live?
Why does a new source show as still processing?
Can I add a private Confluence space?
What happens if my key does not have access to a source?
Do I need any other tools connected?
Related templates
Every library you have adopted, are trialing, are assessing or have put on hold, on one board, with live research and a written recommendation on each card.
See which libraries every repository is stuck on, get a migration brief written from real documentation, and track who owns each upgrade.
Every time you publish a release, we refresh your public documentation library and tell you which changes you shipped but never wrote down.
When a bot opens a version bump pull request, we read the real documentation for that exact version and tell you whether it is safe to merge.
When someone asks a library or framework question in your help channel, they get a straight answer with working code and a source link, right in the thread.
Every Monday, we find your new engineering hires, write each one a guide to your actual tech stack from current documentation, and send it to them in Slack.
Stop guessing what is in your documentation index.
Open one screen that shows every indexed source, who owns it, how stale it has gone, and whether it actually answers the questions your engineers ask.