docmd: one Markdown source, a website plus AI context files

The problem docmd solves, and the name you will fight

Most documentation pipelines produce one artifact: HTML. Everything else that consumes the same prose, from a search box to a coding agent's context window, gets built by a second tool with its own config. docmd's claim is that a single Markdown tree can compile to a static website, an offline full-text search index, llms.txt context files, OKF bundles for RAG pipelines, a sitemap, and an MCP server that exposes the docs to agents over stdio. The README states the goal plainly: "One source, one build, every output."

That is a coherent target. It is aimed at teams who maintain docs as Markdown and have been asked, separately, to make them searchable, crawlable and machine-readable. If you already run a static site generator and then hand-write a llms.txt, docmd is proposing to delete that second step.

Before any of that, a practical warning. Searching for "docmd" returns Microsoft Access VBA results: DoCmd.OpenForm, DoCmd.Close, DoCmd.RunSQL. Those are unrelated to this project. Every search phrase that people actually type about this repository's name is about Access macros, not about a TypeScript compiler. If you adopt docmd, expect to explain which docmd you mean in every internal thread, and expect your own search history to be useless.

How the build pipeline is put together

The mechanism is a compile step with several emitters hanging off it. Point docmd at a Markdown folder; it walks the tree, derives navigation from the file structure, and writes into an output directory. The README's startup banner shows the shape of a run: source `docs/`, output `site/`, then four phases. BUILD reports the engine, source, output, detected versions and locales. DATA INDEXING syncs git metadata, builds the search index and RAG embeddings across versions, and generates AI Assistant RAG context. PUBLISHING writes robots.txt, `.nojekyll`, the sitemap, LLMs context files and OKF bundles. WATCHING then tracks the source folder, `docmd.config.json` and the assets directory.

Two details in that banner are worth pausing on. First, "Versions 2 (06, 05)" and "Locales 7" mean versioning and internationalisation are detected from the layout rather than declared by hand. Second, the build is not a pure static transform: the indexing phase produces embeddings, which is why the AI Assistant can answer from your docs. That is also why the tool is heavier than a plain Markdown-to-HTML converter, even though the deployed output is static HTML with minimal vanilla JavaScript and no framework runtime.

The repository is a pnpm monorepo. `packages/` holds the core, UI, plugins and engines; `_playground/` is the development fixture the root scripts run against. The root `package.json` exposes the whole surface as scripts: `doctor`, `validate`, `migrate`, `deploy`, `mcp`, `add` and `remove` for plugins. That script list is the clearest evidence of intended scope, and it is broader than most static site generators attempt.

Install docmd and get a first page running

The README's quick start needs no installation at all. Run this in any folder containing Markdown files, and docmd starts a development server on port 3000:

npx @docmd/core dev

In the README's example the server reports `http://127.0.0.1:3000` and a network address, serving from `./site`. If the folder has no Markdown, there is nothing for the build to emit, so start from a directory that already has at least one `.md` file.

To ship the same source as a static site, run the build subcommand. The README says the output is an SPA ready for Vercel, Cloudflare Pages, Netlify, GitHub Pages or any static host:

npx @docmd/core build

If you would rather not invoke npx each time, install the package globally and use the `docmd` binary directly. The README gives both npm and pnpm forms:

npm install -g @docmd/core
# or
pnpm add -g @docmd/core

docmd dev
docmd build

Node.js 18 or higher is required. There is also a published container image, and the README advises pinning a version for reproducible builds:

docker run -p 3000:3000 ghcr.io/docmd-io/docmd:0.9.0

A config file is optional. The README states that navigation is generated from your file structure, with no config file, no frontmatter and no framework to learn. The dev server does watch `./docmd.config.json`, so that is the filename to create when you outgrow the defaults. What that file accepts is not shown in the README; the documentation site at docs.docmd.io is the place to look.

Where docmd stops being the right tool

The AI outputs depend on a service or a key. The README describes the AI Assistant plugin as RAG-powered chat grounded in your documentation, and says you can use your own API key or connect a local provider, with support for 100+ providers through AIPlug. The hosted Cloud Relay exists specifically to enable the assistant on static documentation without running your own AI backend. So the offline claim applies to search, not to chat: full-text search needs no cloud service, but a conversational assistant needs a provider somewhere. Teams in air-gapped environments should plan for the local provider path and verify it works before promising a chat feature.

The README does not document rollback or downgrading. Upgrades are the risky operation in a compiler that also writes a search index and embeddings: if 0.9.6 changes the index format, going back to 0.9.5 is an undocumented procedure. The README's own advice to pin a version for reproducible builds is the mitigation, and it is worth taking literally.

Plugin availability is the third boundary. The root scripts include `plugin:add` and `plugin:remove`, so an extension system exists, but the README does not enumerate what is available. If your requirements include a specific integration, confirm it exists before you migrate. And if your docs are not Markdown, or your site needs a component framework with client-side state, docmd's no-framework-runtime output is a constraint rather than a feature.

docmd against Docusaurus and Mintlify

The README points to a comparison page at docs.docmd.io/comparison/ covering Docusaurus, Mintlify and others. The honest difference is in what each tool treats as the primary artifact.

Docusaurus is a React-based static site generator with a deep plugin ecosystem and a large body of community answers. Its output is a website, and anything machine-readable is bolted on afterwards. docmd emits the machine-readable artifacts from the same build, at the cost of a smaller ecosystem and a much shorter track record.

Mintlify is a hosted documentation platform. You get the site, the search and the AI features as a service, and you pay for that convenience with a platform dependency. docmd is a compiler you run yourself, MIT licensed, with a self-hosted Cloud Relay as the optional hosted piece. The trade is operational work against vendor lock-in.

A plain static site generator plus a hand-written llms.txt is the third option, and it is the one to beat. If your docs change slowly and your AI context file is short, that combination is cheaper than adopting a compiler. docmd wins when the outputs multiply: multiple versions, seven locales, a search index and an MCP endpoint that all have to stay in sync with the same source.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-09. Releases are frequent: 0.9.3 on 2026-08-19, 0.9.4 on 2026-08-23, 0.9.5 on 2026-09-08. That cadence cuts both ways. Fixes arrive quickly, and so does churn. The 0.9 series is described in the README as an active line with a roadmap discussion, and the release titles mention build performance, OpenAPI and assistant tooling, which suggests the surface is still moving.

For upgrade cost, the practical exposure is the generated data rather than the HTML. A page template change is easy to review in a diff. A search index or embedding change is not, and the README does not describe an index migration path. Pin the version, build into a clean output directory, and treat the index as disposable.

The licence is MIT, which permits commercial use and modification. That is permissive in the ordinary sense; it is not legal advice, and if you redistribute the tool inside a product you should read the LICENSE file at the repository root rather than this summary. The README also links a separate `docmd-skills` repository for agent skills, which carries its own terms.

What the repository layout tells you about maturity

Beyond `packages/`, the tree contains `tests/`, `tools/`, `scripts/`, `eslint-rules/` and a custom `eslint.config.mjs`. The root scripts include `verify`, `prep`, `sim` and `lint`, and `sim` runs a simulation against `_playground` with `--regen-tars --build`. A project that maintains its own ESLint rules and a simulation harness is being developed with more discipline than a single-author side project, even if the README is the only documentation you read.

The `docker/` directory holds the Dockerfile referenced by `docker:build`, and `docker:test` mounts a `docs` folder and runs `--version`, which is a smoke test rather than a build test. The multi-language READMEs (German, Chinese, Spanish, Japanese, French, Russian) match the seven locales the build banner reports, so the project eats its own i18n output.

What the layout does not tell you is how many people are using it or how it behaves on a large corpus. The README's example build reports 1.2s for a small playground, and that number should not be extrapolated. Build time against a few thousand pages is the measurement that matters, and the README does not provide it.

Editorial conclusion

Adopt docmd if your documentation already lives as Markdown and you want the AI-facing outputs (llms.txt, OKF bundles, an MCP endpoint) produced by the same build that produces the website, without adding a separate pipeline. Skip it if you need a mature plugin ecosystem, a documented rollback path, or if your team will search for the name and land on Microsoft Access VBA pages instead. Verify three things before committing: that the plugin you need exists and is documented, that your Node version is 18 or higher, and that the Docker image tag you pin actually resolves. The README does not document rollback or version downgrade, so decide how you would recover from a bad upgrade before you ship one.

Frequently asked questions

Official sources

1. docmd-io/docmd on GitHub
2. License: MIT
3. Project website
4. README
5. Releases