docmd Documentation

@docmd/parser is an isomorphic Markdown engine used to parse Markdown into HTML. It is designed to run identically in both Node.js and browser environments. It provides specialized support for documentation-specific Markdown features including:

• Callouts
• Tabs
• Steps
• Changelogs

@docmd/ui serves as the visual foundation for the docmd documentation engine. It provides the core building blocks used by all official themes, including:

• EJS layout templates: Structural templates for documentation pages.
• Core CSS and JavaScript: The base styling and logic for the documentation interface.
• SVG icon sets: A standardized set of icons used across the ecosystem.

If you are building a custom theme for docmd, you should build upon these core assets to ensure compatibility with the rest of the engine.

The @docmd/plugin-search plugin provides offline full-text search capabilities for docmd sites. It works by building a search-index.json file at compile time, which allows for fast, fuzzy matching using minisearch.

Key characteristics:

• No API keys required: Does not rely on external cloud services.
• Privacy & Air-gapped friendly: Works entirely locally without external network calls.
• Zero configuration: It is bundled with @docmd/core and is enabled by default.

docmd is designed for AI-driven documentation consumption through several built-in features:

• MCP Server: Running docmd mcp exposes your documentation to AI agents via stdio, allowing them to search, read, and validate content.
• LLM Context: At build time, docmd automatically generates llms.txt and llms-full.txt files, providing complete documentation context for LLMs.
• Agent Skills: Modular instruction sets for LLMs and IDE agents are available via docmd-skills.
• Browser Tools: One-click buttons in the browser allow users to "Copy as Markdown" or "Copy Context" for easy pasting into AI chats.

The Summer template uses the docmd template plugin system. Assets are loaded in a specific order based on priority levels. The Summer template's CSS and JS files are loaded at priority 10.

The full load order is:

1. docmd-main.css (Priority 0) — Base styles
2. Theme CSS (e.g., docmd-theme-sky.css) (Priority 5)
3. summer.css (Priority 10) — The template's styles
4. Your customCss (Priority 15) — User-provided overrides
5. Plugin CSS (Priority 20) — Plugin-specific styles

The Rust engine provides high-performance documentation processing through several specialized capabilities:

• file-discovery: Uses native filesystem APIs for parallel directory traversal.
• file-read-batch: Utilizes memory-mapped file reading for efficient large-batch operations.
• git-log: Provides direct libgit2 integration, meaning the git CLI is not required on the host system.
• search-index: Employs SIMD-accelerated text processing for faster indexing.

docmd is designed for modern documentation workflows involving AI agents and LLMs:

• MCP Server: Use docmd mcp to expose your documentation via stdio to AI Agents, allowing them to search, read, and verify content directly.
• AI Context Files: During build, docmd automatically generates llms.txt and llms-full.txt files, providing complete documentation context ready for any LLM.
• Agent Skills: Access modular instruction sets for LLMs and IDE Agents via docmd-skills.
• Context Copying: The browser interface includes one-click buttons to copy content as Markdown or as optimized AI chat context.

The deployer uses an orchestrator pattern to manage file generation.

1. Orchestrator (index.ts): Resolves user options and handles all I/O (writing files to disk).
2. Providers: Each target (e.g., Docker, Vercel) is implemented as a provider. A provider is a pure function with the signature (ctx: DeployContext) => string. Providers have no side effects and perform no I/O; they simply return the content of the file to be written.

This architecture allows for easy extension: adding a new deployment target only requires adding a new provider file without modifying existing ones.

The @docmd/tui design system includes several components for structuring terminal output:

• Banner: Displays the centralized ASCII logo and versioning.
• Section: Creates box-drawing based sections to group related output.
• Step: Provides standardized step-by-step progress logging (e.g., showing a task name and its status like DONE).
• Footer: Renders a consistent footer at the end of the output sequence.

The plugin determines the type for each page using the following order of precedence:

1. frontmatter.okf.type (nested)
2. frontmatter.type (top-level)
3. frontmatter.okfType (legacy)
4. Path-prefix inference (e.g. /guides/foo → guide)
5. defaultType (with a warning if warnOnMissingType is enabled)

Supported path-prefix inferences include: guides/, api/, reference/, concepts/, runbooks/, datasets/, metrics/, and tables/.