Knowledge Reviews are how Dosu keeps your published Documents accurate as the code moves. A Monitor watches a Source for changes, flags Documents that look stale, drafts a fix, and sends it to Review so your team can Accept, Edit, or Decline it.
What it is#
Documentation goes out of date quietly. A function is renamed, a flag is removed, an endpoint changes shape, and the Document that described it is now wrong. A Knowledge Review is the work of catching that drift and fixing it, in three parts:
- Detect. A Monitor on a Source reads each pull request or merge request and checks the change against your published Documents.
- Propose. For any Document that looks stale (or a gap that warrants a new Document), Dosu drafts a targeted edit.
- Decide. The draft waits for a person at Review, who can comment on the pull request and Accept, Edit, or Decline it.
Nothing changes your knowledge base on its own. Dosu drafts, your team decides.
Why it matters#
Across many repositories and teams, stale documentation is the default, and the people who knew the old context have often moved on. Knowledge Reviews turn maintenance into a side effect of normal development instead of a separate chore nobody owns.
- Drift is caught at the source. A Document is flagged on the pull request that changed the underlying code before the change is merged, not in a quarterly audit.
- Hygiene scales. The review load tracks actual code changes rather than a fixed schedule, so a shared source of truth stays up to date as your organization grows.
- Cleaner input for coding agents. Documents that feed the MCP Server stay current, which cuts the cost of running coding agents on stale context.
- Your team stays in control. Every proposed change passes through Review, so nothing reaches your knowledge base without a human signing off on it.
How it works#
A Knowledge Review runs against the published Documents in a Library.
- A pull request or merge request is opened or marked ready for review in a monitored Source. Draft pull requests are ignored until they are ready.
- The Monitor compares the code changes against published Documents that reference the affected code.
- For each Document, Dosu determines whether it is still valid, needs an update, or no longer applies, and drafts a targeted edit for anything that looks stale.
- Dosu posts a single Knowledge review comment on the pull request and lists the same drafts on the Review page.
The Monitor reruns when new commits are pushed to an open pull request, with a short debounce to prevent rapid pushes from triggering a flood of checks. To run a check on demand, comment /dosu-refresh on the pull request.
When a Monitor reviews a change and finds nothing to update, you choose how it signals that. It can react with an emoji, post a short comment, or stay silent.
Reviewing a proposal#
Each flagged Document offers the same three actions, in the pull request comment and on the Review page.
- Accept applies the edit as written.
- Edit lets you change the draft first, then apply it.
- Decline dismisses the draft without making any changes.
What Accept does depends on where the knowledge lives. For Documents synced to a tool like Notion or Confluence, accepting pushes the edit back to the upstream page. For documentation stored in a Git repository, Dosu opens a docs pull request with the change rather than writing directly to your default branch, and adds the original code author as a reviewer.
Your decisions persist across commits, so you do not re-review the same suggestion every time a new commit lands on the pull request. The comment updates in place to show what was accepted, declined, or pushed.
Scope and requirements#
For Dosu to flag a Document, three things must be true:
- The Document is published. Drafts and pending Documents are not watched.
- The tool is connected as a Source with Monitor turned on.
- The Library is set up to review changes, which is on by default.
You can narrow what a Monitor watches with Monitored Paths, a set of glob patterns (for example src/** or docs/**). The default watches all paths. Use a narrower set to focus on the directories that map to your Documents and skip build or test files. You manage Sources, Monitors, and Monitored Paths inside a Library, which you can open or create at Libraries.
Whether accepted edits publish automatically on merge or wait for a person is configurable. Hold updates for manual review when you want every change approved before it lands.
A Knowledge Review needs a Document to compare against. If a Library has no published Documents for the changed code, there is nothing to flag, so build that baseline first with Generate Docs and Save This Answer.
