Every engineering organisation has the same quiet problem. A page in Confluence describes how a service is configured. The service changed eight months ago. The page did not. Nobody is lying and nobody is lazy: the page was correct when it was written, and there is no moment in anyone's week that is "go and check whether the docs still match the code".
The failure is invisible by construction. A wrong page looks exactly like a right one. You find out when a new engineer follows it, or during an incident, which is the worst possible time to learn that the runbook describes a flag that was removed two releases ago.
Why chat-with-your-docs makes this worse
The obvious move is to point an AI at Confluence and ask it questions. That category is saturated and Rovo now does a version of it at no extra cost, so this is not a pitch against it. It is a note that it does not solve this problem, for a structural reason:
A chatbot reading your documentation inherits the documentation's mistakes. If the page says the timeout is 30 seconds and the code says 90, asking the bot gives you 30, delivered fluently and with confidence. The answer is wrong and now it sounds authoritative. You have added a layer that launders a stale fact into a trusted one.
The job is not retrieval. It is maintenance: comparing the page against the code it claims to describe, and saying which one moved.
The do-it-yourself loop
This is buildable today and worth doing even if you stop here.
- Decide what each page documents. A page is about a path:
services/billing/, or a single file. Without that link there is nothing to compare against, and this step is most of the value. - Get the page in a diffable form.
GET /wiki/api/v2/pages/{id}?body-format=storage. - Run an agent against both in CI. In a job with the repository checked out, give Claude Code or Codex the page body and the path, and ask for a specific output: not "is this right" but "return the corrected page body, list what changed and why, and cite the files you read".
- Put a human in front of the result. Never write it straight back. An agent that is confidently wrong about a page is worse than a stale page, because now it is stale and recently edited, which looks trustworthy.
The hard parts are not the API calls. They are pinning the comparison to a commit so the result is reproducible, keeping the proposal somewhere reviewable, and not losing a concurrent human edit.
The app
Repo Docs Sync for Confluence packages that loop. Link a page to the repo path it documents. On demand from the page byline, or on a daily or weekly schedule, your own CI runs the agent against the checked-out repo, and a proposal comes back: the corrected body, a change summary, and the commit it was checked against.
Proposal first by default. A person opens the dialog, reads the summary, applies it. Direct apply is opt-in per page, and if a human edited the page while the agent was working, the human wins and the result is kept as a proposal instead.
Said plainly because it is the point of the architecture: this app calls out of your tenant, to your CI and nowhere else, so it does not carry the Runs on Atlassian badge that most of our apps do. Your repository is never cloned by us and your model API key never reaches us. The egress is the product. App details and screenshots.
Written by Abaho Katabarwa at Katabarwa Labs. We build small, single-purpose Atlassian and Azure tools that run entirely inside your own tenant. Questions: support@katabarwalabs.dev.