Configure
Generated docs
The docs MergeHarbor writes and maintains for every repository, how reviews use them as codebase context, and how your team reviews and edits them.
MergeHarbor writes documentation for each indexed repository and keeps it current as the code changes. Reviews read the pages for the code a pull request touches, so comments reflect how your system actually fits together. Find the docs under Memory → Knowledge base → Generated.
What you get
For each repository:
- Architecture overview: the main components, how requests and data move between them, and where to start reading.
- Glossary: the domain terms and internal names a newcomer needs.
- Where files live: every documented module with its role and what it calls.
- A page per module: what it does, how it connects to the rest, what is easy to break, and the files to read first.
- A page per key flow: the steps of an end-to-end path, such as a request or a background job.
- Conventions and How to add common changes: patterns your code follows and short recipes for typical changes.
- Reverts and incidents: past reverts, rollbacks, hotfixes and incident fixes found in the git history, each summarised once.
Every page lists its sources (files or modules) and the commit it was written from.
How it stays current
Docs are written after a repository’s first index, with no setup. After each push, MergeHarbor re-indexes the changed files and rewrites only the modules whose files changed. The repository-level pages are rewritten at most once a day. A page whose code moved on before it could be rewritten is marked May be out of date with the reason.
You do not need to push again to recover from an error. A repository whose docs failed to generate, for example because a model provider was unavailable, is retried every hour. A repository still waiting for its file summaries after six hours gets a new summary run, and its docs follow. Repositories stopped by the monthly cap or a paused budget are not retried.
Writing uses the lowest-cost model your routing policy allows, through the provider’s batch API where available (about half the price; pages then appear within a few hours at most), and stops at a monthly cap per repository (0.50 USD by default). Spend appears under usage as knowledge.
How reviews use it
Each review receives, within a fixed size limit:
- pinned pages,
- past reverts and incidents in the files the pull request changes,
- the pages of the modules it changes,
- the overview and conventions.
When a page shaped a finding, the comment says so (“Informed by the knowledge base: …”), and the finding in the console links to the page.
Editing
People with the Create and edit rules and knowledge permission can:
- Edit a page. Edits are kept when the page is rewritten; if the generated text changes underneath an edit, the page says so and History shows the new version.
- Revert to generated to drop an edit.
- Pin a page so it is listed first and always sent to reviews.
- Hide a page so readers, exports and reviews no longer see it.
- Regenerate a repository’s docs (once every 10 minutes).
Organization administrators turn generated docs on or off, choose whether reviews use them, and set the monthly cap from Settings on the same page.
Search, export and coding agents
- Search across every repository’s pages from the search box.
- Export Markdown downloads one repository’s visible pages as a single file.
- Coding agents connected through MCP can list, read and search the docs and look up past reverts in the files they are about to change.