Zero-config docs, tested for real

What building real docs with Blume took

A zero-config documentation framework, tested on a real Salesforce open-source project instead of a demo: 39 pages, native Mermaid diagrams, a theme system, and an agent skill bundled into the same npm install.

The shipped hero image for the Nebula Logger docs rebuild: a nebula star field resolving into three log lines reading the tag API, multi-surface coverage, and the Setup > Debug Logs contrast.
The hero that shipped, after dropping a build-metric graphic in favor of what the docs cover — see the Theming section for the token system that replaced it.

The starting point

Nebula Logger's docs lived on a GitHub wiki

Nebula Logger is a Salesforce open-source logging framework for Apex, Lightning components, Flow, and OmniStudio. Its documentation lives on a GitHub wiki: a sidebar list, no search, no way to tell a beginner page from a reference page at a glance. Blume is a zero-config documentation framework from Hayden Bleasel that shipped to npm a few days before I tried it. I wanted a real body of content to test it against — a project with genuine documentation debt already stacked up — so I picked Nebula Logger and rebuilt its docs from the ground up.

First build

Zero-config, for real

npx blume init scaffolded the project in under a minute — no config file to write before anything rendered. Six pages went up that first afternoon: an overview, one page each for developers, admins, and architects, a tagging reference, and an about page. Every one of them used Blume's built-in components — Tabs, CodeGroup, CardGroup, Panel — without a single import statement, and every one rendered correctly on the first try. The full static build finished in under four seconds.

Takeaway

Six real pages, four components, no config file, under four seconds to build — the entire cost of trying Blume fit inside one afternoon.

Past the demo

Scales past a toy example

Six pages doesn't prove a framework holds up past a demo. So I cloned Nebula Logger's actual source repository and its wiki repository, and fanned out 33 subagents — a mix of Sonnet and Haiku — to write against the real material, one subagent per page, nothing pulled from memory. Twenty-six of the wiki's pages got rebuilt from their original content. Seven reference pages were built from the project's own ApexDocs output and its object metadata. Combined with the six start-here pages from the first afternoon, that's 39 pages, one working build.

The wrong numbers

Forty pages, 148 classes, both wrong

The first published README said 40 pages and 148 Apex classes. Both were wrong — the real numbers are 39 and 53. Two review agents caught the page count on a cold read; the class count took one more step, tracing it back to the project's own generated docs.

Takeaway

Blume's site is markdown in a git repo, so fixing both numbers was two file edits and a push — the same process as fixing a typo.

Theme tokens

Theming without ejecting

Theming is a small set of config tokens — accent color (a named preset or any CSS value), corner radius, color mode, and separate fonts for headings, body, and code — plus a theme.css escape hatch for anything the tokens don't cover. No ejecting into a custom Astro project required.

Takeaway

For a team without a dedicated designer, that's the actual pitch: on-brand in a few config lines instead of a CSS project.

Going deeper

Diagrams that just work

Mermaid renders straight from a plain fenced code block — no plugin, no extra config, because Blume bundles Mermaid itself. I used it for an architecture flowchart, an entity-relationship diagram, and sequence diagrams, grounded in Nebula Logger's real objects: Log__c, LogEntry__c, LoggerTag__c, LogEntryTag__c, and LogEntryEvent__e.

Generated illustration of Nebula Logger's 4 architecture layers stacked bottom to top: Logger Engine, Log Management, Configuration, and Plugin.
The one page that got a generated illustration instead of a screenshot or a diagram alone — the 4-layer stack called for something more visual than nodes and edges.
The object model behind the diagrams
Log__c is the parent record for a transaction. LogEntry__c holds each individual log line under it. LoggerTag__c and the junction object LogEntryTag__c handle tagging. LogEntryEvent__e is the platform event that carries log data across the async, event-driven path before it lands as a record. The sequence diagrams trace that path end to end.
The padding bug
One guide page rendered its explanation paragraph flush against the code block, no gap between them. The cause: a Tailwind selector, [&:has(>pre)]:p-0, that strips all padding from a tab panel the moment a code block appears anywhere inside it — even next to prose. The fix was to keep each tab either code-only or prose-only.

Takeaway

The one rough edge — a Tailwind rule stripping padding around a code block — took one read of Blume's own component source to trace and fix. Details below.

The rest of the library

Twenty-plus components, four I put to use

The component library goes well past Tabs and CardGroup — cards, columns, steps, accordions, badges, code groups, frames, file trees, type tables, live component previews, diffs, and more, all usable in MDX with no imports. I used four for real: Steps to walk through how the site got built, a Diff block for the wrong-number fix two sections up, a Type Table for Log__c's status fields, and a GitHub info card pulling Nebula Logger's live star and fork count at build time.

Takeaway

That last one replaced a hardcoded "935+ stars" sitting in two pages, already stale by the time I wrote it. The live card showed 952 stars and 240 forks the day I checked.

Built for agents

On both ends — building it and reading it

An official skill for Claude Code, Codex, and Cursor — installed with npx skills add haydenbleasel/blume — teaches an agent to scaffold the site, write pages, and configure the theme. On the read side, every page is machine-readable by default: append .md to a URL for the raw source, an auto-generated llms.txt indexes the whole site, and an optional MCP server lets a reader's own agent search and read the docs directly instead of scraping HTML.

The result

Live, with the source public

Live demo and source are both public, including the commit history showing the wrong page and class counts and the two commits that fixed them.

Unofficial, fan-made demo — not affiliated with or endorsed by Nebula Logger's maintainers. Nebula Logger is copyright Jonathan Gillespie and contributors, MIT licensed. I also have no affiliation with Blume or its author — no sponsorship, no referral link, nothing to gain from recommending it. I tried it on a real project and this is what happened.

Takeaway

If you maintain a Salesforce package or internal tool with docs stuck in a stale wiki, the Blume config and build setup are free to reuse. Only the adapted Nebula Logger content itself carries attribution.

Cheat sheet

What Blume actually gets you

Zero-config scaffolding

A folder of docs is a complete project — no starter to clone, no framework to learn. Navigation, search, theming, and OG images all work before you write a config file.

Native Mermaid and KaTeX, no plugins

Diagrams and math render straight from fenced code blocks and $$ syntax — both are bundled in, so there's nothing extra to install.

Theming without ejecting

Accent color, radius, color mode, and fonts are config tokens; a theme.css file covers anything they don't. No custom Astro project required.

Agent skill, llms.txt, and .md export

An agent skill (npx skills add haydenbleasel/blume) helps you build the site; .md URLs, llms.txt, and an optional MCP server let readers' agents consume it.