# A docs coverage board that catches what shipped undocumented

> See everything engineering shipped next to the docs pages that cover it, so the work nobody labelled stops slipping through.

- Workflow type: app
- Services: GitBook, GitHub, Slack Bot
- Categories: Engineering, Product
- Published: 2026-08-22

## What it does

- Lists everything your engineering team shipped in a period, pulling merged pull requests and tagged releases from GitHub.
- Gives every item a coverage verdict by searching your GitBook documentation for that feature, naming the pages that mention it and when each was last updated, or flagging that no coverage exists.
- Shows a single coverage rate for the selected period, so the team can watch the number improve week to week.
- Adds a Draft the docs update button that hands the work to a background agent, which writes the update, opens it as a draft change in GitBook, and tells your docs channel in Slack.

## What you'll need

- A GitHub account with access to the repositories you want to track.
- A GitBook account where your documentation lives.
- A Slack workspace, so the board can post to your docs channel when a draft is ready.
- A short list of the repositories that count as shipped work for your team.

## Prompt

Build me a docs coverage board that shows what engineering actually shipped and whether anyone documented it. I am a docs lead and right now I guess at this. I want one screen that lists recent shipped work, gives each item a coverage verdict, and shows a single coverage rate for the period I am looking at, so my team can watch that number move week to week.

The board lists what shipped. Pull merged pull requests with GitHub List Pull Requests, requesting closed pull requests for each configured repository and keeping only the ones that actually merged, and pull tagged releases with GitHub List Releases. Group pull requests under the release that contains them where that is clear, and list them on their own where it is not. Use GitHub Search Issues and Pull Requests when I search the board by keyword or need a cross repository lookup instead of paging every repository.

For every shipped item, work out a coverage verdict. Derive search terms from the pull request title, body, labels, and the names of changed files, then run GitBook Search Organization Content for those terms. When pages come back, show them as the coverage evidence: name each page, the space it lives in, and when it was last touched, reading page detail with GitBook Get Page By ID and using GitBook List Pages In Space and GitBook List Organization Spaces to resolve where a page sits in the tree. Mark the item covered when a page genuinely discusses the feature, stale when the only matching pages were last updated before the pull request merged, and no coverage found when nothing relevant comes back. Show the reasoning on the card so a reviewer can disagree with it.

Let me filter by repository, label, release, date range, and coverage status. The headline at the top of the board is the coverage rate for the selected period, meaning the share of shipped items that are covered, counting items marked docs not needed as resolved rather than as holes. Show the previous period beside it so the direction is visible.

Reviewers work out of this board, so persist their decisions per item in the app's own storage. A reviewer can mark an item docs not needed with an optional reason, and assign an owner from the team. Those decisions stick across refreshes and feed the coverage rate. Record who made each call and when.

Each item gets a Draft the docs update button that starts a background agent. The agent reads the full pull request with GitHub Get a Pull Request to get the body and the diff summary, lists spaces with GitBook List Organization Spaces and walks the page tree with GitBook List Pages In Space to pick the right space and the nearest existing page, reads that page with GitBook Get Page By ID so the draft matches the surrounding voice and structure, writes the documentation update, and opens a draft with GitBook Create Change Request. When it finishes, it links the change request back onto the item on the board so I can see it there, and posts a note to our docs channel with Slack Bot Send a Message naming the shipped item, the space it drafted into, and a link to the change request. Show the agent's progress and its result on the card.

Two details matter. When reading GitBook page bodies for the agent, request markdown with stable references, so the drafting agent gets clean prose instead of raw document structure. And do not build this around a needs docs label. The whole point is catching the pull requests nobody remembered to label, because unlabelled work is exactly where the coverage holes come from, so scan everything that merged in the period and let the verdict come from searching the docs rather than from what someone tagged.

## How to customize

- Choose which repositories and date ranges the board covers, and whether releases or individual pull requests are the unit your team reviews.
- Adjust how strict the coverage verdict is, for example treating a page that has not been touched since the change shipped as stale rather than covered.
- Pick the Slack channel that gets pinged, and decide who on the team can mark items as docs not needed.

## FAQ

### How does it decide whether something is documented?

It takes the wording of each shipped change and searches your documentation for it, then lists the pages that came back along with when each was last updated. If nothing relevant turns up, the item is flagged as having no coverage. The reasoning is shown on the card, so you can disagree with it and mark the item yourself.

### Will it catch work that nobody labelled?

Yes, and that is the whole point. The board looks at everything that merged in the period rather than only the items someone remembered to tag as needing docs. Unlabelled work is where most coverage holes come from.

### Does it change our live documentation automatically?

No. The drafting agent opens a draft change in GitBook for a person to review and approve. Nothing reaches your live docs without someone approving it.

### What if our documentation is split across several spaces?

The board searches across every space you have access to, and the drafting agent picks the space and the nearest existing page that fit the change before it writes anything.

### Can we tell whether our coverage is actually improving?

The headline coverage rate is worked out for whatever period you select, so you can compare one week against the next and see the direction of travel.

Use this prompt in General Input: https://www.generalinput.com/prompts/a-docs-coverage-board-that-catches-what-shipped-undocumented