Documentation, without the docs site

A three-page project does not need a static site generator, a Node toolchain, and a theme config. It needs three good pages.

# The honest amount of tooling

Documentation sites have a gravity of their own: install the generator, learn its config, pick a theme, wire the deploy, then keep the whole apparatus alive for what was supposed to be a README with ambitions. Most projects quietly give up, and their docs stay a wall of Markdown in a repo.

lucid.page collapses that to writing. Each page is published as it’s finished, at a link you can put in the repo, the package readme, or the release notes.

# When one page is not enough

Publish each part as its own page, then collect them in a binder: a getting-started guide, an API walkthrough, and a FAQ, in order, behind one link, each with a short note on what it covers. Every page keeps its own URL.

# Readable by people, and by their machines

Every page keeps its source. The rendered HTML is for humans; the Markdown is one request away for everything else:

curl https://lucid.page/raw/your-docs

That makes a page a fair input for scripts, for reviewers’ editors, and for the tools your team already talks to. Publishing itself is a plain HTTP API, so docs can ship straight from CI — the agent documentation covers the interface.

# Common questions

# Can documentation span multiple pages?

Yes. Publish each part as a page and collect them in a binder: one ordered list behind one link. Every page keeps its own URL.

# Do I have to deploy anything?

Nothing. Paste Markdown and publish; hosting, rendering, and the reading experience are the product.

# Is there an API for publishing docs?

Yes — publishing is a single HTTP POST, designed to be called from CI or by agents. See the agent documentation.