OverviewA reader for the documentation
A reader for the documentation
you already wrote.
Not a wiki with a git integration bolted on — the other way round. Your repository is the source of truth, the folder structure is the navigation, and there is no file you have to write first.
01
Discovery
It already knows where your documents are
The first screen is not a setup wizard. Connect a repository and the tree is there, in an order somebody would have chosen, with titles somebody would have written.
- Where it looks
- docs/, then documentation/, then doc/, then .github/docs/ — then the adr/, architecture/, specs/ and rfc/ folders at the root, all as top-level sections. If none of those exist it reads every markdown file in the repository instead. Whatever it settles on is recorded, so later syncs are deterministic.
- What it ignores
- node_modules, .venv, vendor, target, build, dist, .next and a dozen more. A sidebar full of dependency READMEs is the first thing that makes a docs tool feel unmaintained.
- How a page gets its name
- Front matter title, then the first H1, then the filename de-slugified — auth-flow.md becomes Auth flow, 01-intro.md becomes Intro. A raw filename with its extension is never displayed.
- How the order is decided
- README or index first and it becomes the folder's landing page. Then numeric prefixes in numeric order. Then everything else alphabetically by title. Sub-folders after files. No list to maintain.
- Where the noise goes
- CHANGELOG, LICENSE, CONTRIBUTING, SECURITY and their siblings collapse into a Repo files group at the bottom — unless one of them is the only markdown in the repository, in which case hiding it would leave you with nothing.
- The escape hatch you should never need
- There is an override file. It is never required, it is not mentioned anywhere in the product, and a repository that needs one to read well is our bug rather than your task.
02
The reading surface
Built for a spec you read end to end
Most documentation tools are built for scanning. This is built for the forty-minute read — a measure that does not move, a table of contents that tracks you, and code that follows the theme.
- The lit path
- The rail beside the tree lights the ancestry of the document you are in, shading across the levels. It is the one moment of visual drama in the product, and it exists because knowing where you are in a corpus is the thing a folder tree usually fails at.
- A measure that does not move
- Prose is capped at 78 characters at every breakpoint. You can change it if you want a wider or narrower column, and that choice follows you.
- Dark first, light complete
- Both themes are designed rather than inverted, each with its own accent, its own shadow weights and its own six syntax colours. Applied before the first paint, so there is no flash on load.
- Diagrams that match the page
- Mermaid reads the live palette rather than shipping a stock theme, and re-reads it when you change theme. Neither it nor the syntax highlighter is loaded for a document that has neither.
- Copy for LLM
- The reason people open a spec is often to paste it somewhere. Take one document or a whole folder as clean markdown — front matter and badges stripped, relative links rewritten — with the token count before you settle on it.
03
Staying current
The whole pipeline, stage by stageReading has no publish step. A push is the update.
The repository is the source of truth and stays that way. Nothing is copied, nothing is imported, and merging is the only thing you do to update a document.
- Never cloned
- One API call returns the whole folder structure plus a blob SHA for every file. No git binary, no working copy, nothing on disk. Only markdown blobs are ever fetched, and nothing outside the docs root is fetched at all.
- An unchanged file costs nothing
- The blob SHA is the change detector. Same SHA and the file is skipped entirely, so a repository where one paragraph moved does one file's worth of work.
- A move keeps its identity
- A renamed file is recognised as the same document, so its review state, its notes, its read receipts and its health findings all move with it. This is git's own exact-match rule and needs no similarity scoring.
- Your tab finds out from the database
- The worker commits the change and announces it on the same connection, inside the same transaction. No polling loop — and a document you have open offers to reload rather than swapping its paragraphs under you.
04
The workflow layer
Knowing whether a document is still true
A docs host can tell you a page exists. It cannot tell you whether anybody agrees with it, whether it has been built, or whether it has quietly stopped describing the system.
- Two axes, moving independently
- A review state — draft, in review, validated, rejected, not applicable — and an implementation state, because a spec everyone agrees with and nobody has built is a different situation from one half-built and disputed.
- Drift is content, never a date
- A status remembers the exact version it was set against. Edit the document and it reads validated · drifted rather than keeping a badge that has stopped being true. A timestamp would report drift every time a worker touched a row.
- No row until somebody decides something
- An untriaged document has no status at all, and renders no pill. A corpus nobody has looked at costs nothing and looks like what it is, rather than like a wall of drafts.
- Notes on a heading
- Feedback is anchored to the section it is about. If that heading disappears the note fails visibly rather than relocating itself onto text that says something else.
- Read receipts you can believe
- Counted after ten seconds of visible reading, never on a click in the tree, and only against the current version.
- Docs health
- Broken relative links, documents whose content has not changed in too long, and documents naming a source file that changed after they did. Three checkable signals, no opinions, and nothing that calls a model.
05
Agents
Every tool, and the four that cannot existAn agent is a first-class reader
Your team writes documentation partly so a model can read it. This is the surface that lets one, without a copy-paste step and without letting it rewrite anything.
- One endpoint, tools withheld by scope
- A stateless MCP endpoint your agent points at with a key scoped to one project. A read-only key is never shown the write tools at all — not merely refused when it calls them.
- It can produce, not dispose
- An agent files artifacts into a namespace of its own, versioned, beside the documentation. It cannot touch a repository file, cannot delete an artifact, and cannot close a note.
- The asymmetry
- An agent may claim that feedback is addressed. Only a person may close it. Relax that and a reviewer's objection disappears the moment the agent asserts it has been handled — silently, at scale, in the exact system a team adopted to stop that happening.
06
Access
Roles, teams and invitationsNothing is readable by default
Joining an organization hands out no documents. That sounds strict until you remember the alternative is that inviting a contractor gives them the whole workspace.
- Membership is the organization; access is the project
- A Member reads a project through a team grant or a direct one. Somebody in no team with no grant reads nothing at all, and a Guest never even sees the project list.
- Resolved server-side, every request
- One query answers whether you may read something, and a project you have lost access to answers exactly as one that never existed. No role comparison is ever made in the browser.
- Keys outlive people
- An API key belongs to the organization and names one project, so a CI job does not break the day the person who created it changes team.
- Withdrawing works
- Revoking a key bites on the next request. Signing out every device is one action. Disconnecting GitHub invalidates the sessions that carried its token rather than leaving them working until they expire.
Point it at a repo. Read the handbook you didn’t write.
Connect in three minutes. Disconnect in one click.