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.
Exception: A Document synced from an external source, such as a Confluence page, updates automatically when the source changes. Those upstream edits are published as new versions without going through Review.
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.
If your organization has exhausted its monthly credits, Dosu will skip the review and post a comment on the pull request or merge request explaining that the review was skipped due to reaching the credit limit, when your usage will reset, and a link to upgrade. This applies to both GitHub pull requests and GitLab merge requests.
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. Azure DevOps pull requests do not support reactions, so when the up-to-date behavior is emoji, Dosu posts a comment instead. New Azure DevOps Monitors save comment, and the CLI (libraries monitors list / update) reports a saved emoji on Azure DevOps as comment.
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.
Review in Slack#
When a Library has a Slack channel set under Slack Notifications in its settings, Dosu posts a digest of pending documentation updates there once the Library has been quiet for a couple of minutes, or 15 minutes after the first pending update, whichever comes first. Up to 10 updates are posted as thread replies on the digest message, each showing the Document title, whether it is new or an update (with a link to the triggering pull request), the agent's explanation, and an excerpt of what changed. Each reply offers the same three actions:
- Accept applies the edit directly from Slack.
- Decline rejects the update from Slack (with a confirmation dialog).
- Edit in Dosu links to the review interface in Dosu so you can change the draft before accepting.
When you accept or decline an update from Slack, the thread reply updates to show the outcome — for example, "✅ Accepted by @alice · Sep 25 at 3:04 PM" — and the same outcome appears on the Review page and in the pull request comment. If an update is held to publish when its pull request merges, the thread reply shows "⏳ Accepted by @alice, publishes when PR #42 merges". Slack threads stay synchronized: when a review is resolved in Dosu or GitHub/GitLab, the Slack thread updates to show the same outcome.
The Slack digest shows up to 10 pending updates. If a Library has more than that awaiting review, the last thread reply links to the Review page for the rest.
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.