One source, every surface
What Reed emits besides a website, and why it comes from one representation.
A documentation site is one way to read your docs. It is not the only one that matters
now: agents read llms.txt, tools call MCP servers, and Skill packs carry your prose into
an agent’s context.
Reed emits these from one intermediate representation — a per-page document plus an OpenAPI-derived capability layer — rather than deriving each surface from another.
Why that matters
Section titled “Why that matters”The alternative is what most stacks do: build the site, then scrape the site to make the machine-readable version. That works until the HTML changes, and it silently bakes presentation decisions into data.
Deriving every surface from one representation means the surfaces cannot disagree about what your documentation says. When a page changes, everything changes with it, in one build.
The surfaces
Section titled “The surfaces”Your whole site as one plain-text file, with a markdown mirror per page.
A tool set derived from your OpenAPI spec, written into your repository.
A Skill pack, optionally bundling pages of your own prose.
What is generated when
Section titled “What is generated when”llms.txt and the markdown mirrors are written by every reed build. They need no
configuration.
The MCP server and the Skill pack are generated by explicit commands, need their own config blocks, and write into your repository rather than into the built site. They are not part of a deploy.
The output is yours, in every case
Section titled “The output is yours, in every case”None of these surfaces calls back to Reed at runtime. The site is static files; the MCP server is source you own and host; the Skill pack is a directory you commit. This is the same property throughout: the artifact survives Reed.