Introducing olwibaDOCS: documentation as a pattern

Documentation is the first thing users need and the last thing projects build. olwibaDOCS exists to remove the excuse: every Genesis project ships with a working docs site from the moment it is scaffolded. You are reading proof, these docs run on it.

What it is

olwibaDOCS (@olwiba/docs) is the shared documentation framework: layouts, sidebar navigation, MDX rendering, and the docs shell components used across the whole ecosystem. The same pattern documents olwibaCN's components, olwibaUI's blocks, and your product.

In a Genesis project, docs are MDX files in a content folder. Add a file, it appears in the sidebar. Write a guide with code blocks, callouts, and structure, and it renders with the same theme as the rest of your application.

One pattern, everywhere

The pipeline matters here. Docs shell components originate in olwibaCN, flow through olwibaDOCS, and are consumed downstream by every project. There is exactly one implementation of the docs layout in the ecosystem, which means one place to improve it and zero per-project re-implementations drifting apart.

For a product, this consistency does quiet work: your marketing site, your application, and your documentation share tokens, typography, and navigation behavior. Users never feel the seam.

Docs as part of the product

A SaaS without docs generates support tickets; a SaaS with docs generates self-serve customers. By making documentation a zero-setup part of the template, Genesis moves docs from "phase two, maybe" to something you naturally fill in as you build, the same way you would a route or a schema.

The content lives in your repo, versioned with the code it documents. When a feature ships, its guide ships in the same pull request.

Where it sits in the stack

olwibaDOCS depends on olwibaCN and serves every layer above it. It is open source under MIT, and it carries the documentation pattern for the whole ecosystem, this site included.