ReadMe vs Docusaurus

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to ReadMe
   ReadMe✓fullprobed9/10

   ReadMe hosts a verified llms.txt at docs.readme.com/llms.txt (probe confirms HTTP 200) plus per-page .md access, dedicated llms.txt-style docs for customizing/writing/workflows/ai sections, an Agent-Friendly Docs scoring feature (ai-discoverability), and an official MCP server giving agents live access to API specs and docs. missing for 10: independent/hands-on third-party confirmation that an external agent successfully consumes the llms.txt content end-to-end (only first-party docs and one probe corroborate this).

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.readme.com/llms.txt # ReadMe Documentation Documentation > Beautiful documentation made easy. App…”
   • [claimed-docs] “Make your documentation discoverable and accessible to AI agents and the assistant”
   • [claimed-docs] “ReadMe crawls a sample of your published pages and scores your project against the Agent-Friendly Docs spec, so you can see at a glance wher…”
   • [claimed-docs] “Get your API documentation live in three steps: create a project, upload your API definition, and write your first guide.”
   • [claimed-docs] “Set your hub's look from four theme presets, then tune brand colors and typography in Appearance settings.”
   • [claimed-docs] “Run documentation entirely through Git, with Markdown and OpenAPI in your repository and pull requests as the review step.”
   • [claimed-docs] “Draft, edit, and research documentation from the AI chat panel.”
   • [probe] “official MCP server documented at https://docs.readme.com/main/docs/your-projects-mcp-server”

   proof ↗⚑ flag

   Docusaurus—none0/10

   Probes show Docusaurus's own site has no llms.txt (404) and no agent-oriented docs.md endpoint (404), and no docs evidence describes shipping llms.txt support for generated sites either.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round drawn
   ReadMe~partialprobed6/10

   ReadMe ships an official CLI (rdme) and a documented REST API for controlling docs programmatically, both of which support headless/CI automation (e.g., syncing OpenAPI specs in pipelines). However, the evidence pack lacks explicit CI/CD workflow examples, headless-mode documentation, or community confirmation of CI usage. Missing for 10: explicit CI pipeline examples/docs, headless-mode guarantees, and independent confirmation of automated CLI/API use in production pipelines.

   • [probe] “official CLI documented at https://github.com/readmeio/rdme”
   • [claimed-docs] “Control your docs programmatically with the ReadMe API”
   • [claimed-docs] “Run documentation entirely through Git, with Markdown and OpenAPI in your repository and pull requests as the review step.”

   proof ↗⚑ flag

   Docusaurus~partialprobed6/10

   Docusaurus ships a documented CLI (`npm run build`, `docusaurus serve`) that produces static files non-interactively, which is the basis for running it in CI/CD pipelines (e.g., building docs on every push and deploying to Vercel/Netlify/GitHub Pages), and this is a standard, well-documented workflow for static-site generators. However, there's no first-party CI-specific guide (e.g., GitHub Actions workflow) in the evidence, and community reports describe build performance problems severe enough to time out GitHub Actions runners on larger sites, which undercuts reliability for automation at scale. Missing for 10: explicit CI/automation documentation or example workflow, and independent confirmation of successful large-scale CI builds (contradicted in part by comm-10's report of CI timeouts).

   • [claimed-docs] “To build the static files of your website for production, run: npm run build”
   • [claimed-docs] “Once it finishes, the static files will be generated within the `build` directory.”
   • [claimed-docs] “Docusaurus provides a [`docusaurus serve`](/docs/cli#docusaurus-serve-sitedir) command for that”
   • [claimed-docs] “You can deploy your site to static site hosting services such as [Vercel](https://vercel.com/), [GitHub Pages](https://pages.github.com/), […”
   • [probe] “official CLI documented at https://docusaurus.io/docs/cli”
   • [community] “I haven't used Starlight, but Docusaurus is very slow. The last time I used it, its performance on a large documentation site was terrible, …”
   • [community] “I tried migrating our markdown docs-as-code to use Docusaurus, we have somewhere around several hundred pages, and the build times seemed ve…”

   proof ↗⚑ flag

3. ai-native userUse an official CLI

   weight 2 · round to Docusaurus
   ReadMe~partialprobed5/10

   ReadMe does maintain an official CLI (rdme) per the GitHub probe, confirming the capability exists, but the evidence pack contains no first-party documentation detailing the CLI's commands, AI-native workflow support, or independent corroboration of its use. missing for 10: detailed CLI docs/feature list, AI-native workflow examples, independent/hands-on usage confirmation.

   • [probe] “official CLI documented at https://github.com/readmeio/rdme”

   proof ↗⚑ flag

   Docusaurus✓fullprobed7/10

   Docusaurus ships a well-documented official CLI (create-docusaurus scaffolding, docusaurus start/build/serve, versioning and swizzle commands) confirmed by docs and a probe hit on /docs/cli, all scriptable via npm and usable non-interactively by automation/agents. Missing for 10: no explicit documentation or examples of AI-agent-specific usage/integration, and no independent hands-on confirmation of CLI reliability in automated/agentic pipelines.

   • [claimed-docs] “npx create-docusaurus@latest my-website classic”
   • [claimed-docs] “Builds and serves a preview of your site locally with Webpack Dev Server.”
   • [claimed-docs] “You can use the versioning CLI to create a new documentation version based on the latest content in the docs directory.”
   • [claimed-docs] “Docusaurus provides a [`docusaurus serve`](/docs/cli#docusaurus-serve-sitedir) command for that”
   • [probe] “official CLI documented at https://docusaurus.io/docs/cli”

   proof ↗⚑ flag

4. ai-native userDrive the product through a documented public API

   weight 3 · round to ReadMe
   ReadMe✓fullprobed8/10

   ReadMe documents a full public API ('Control your docs programmatically with the ReadMe API') plus a companion developer-metrics API and an open-source CLI (rdme) that wraps it, giving AI-native users a documented, scriptable interface to drive the product. missing for 10: independent/hands-on confirmation that the API works as documented and more detail on API reference completeness beyond the one-line docs mention.

   • [claimed-docs] “Control your docs programmatically with the ReadMe API”
   • [claimed-docs] “See how people use your docs and how developers use your API”
   • [probe] “official CLI documented at https://github.com/readmeio/rdme”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.readme.com/llms.txt # ReadMe Documentation Documentation > Beautiful documentation made easy. App…”

   proof ↗⚑ flag

   Docusaurus~partialprobed4/10

   Docusaurus exposes a documented CLI (build, serve, versioning commands) and a plugin/Node API that let a user or script drive site generation and customization programmatically, which is the closest analog to a public API for this static-site-generator category. However, probes confirm there is no REST/OpenAPI, no llms.txt, and no HTTP-callable interface for AI agents to interact with — only local CLI/build-time automation. Missing for 10: HTTP/REST or OpenAPI-documented API, AI-agent discovery file (llms.txt), and any remote/service-style programmatic interface beyond local CLI/plugin hooks.

   • [claimed-docs] “Builds and serves a preview of your site locally with Webpack Dev Server.”
   • [claimed-docs] “Builds and serves a preview of your site locally with [Webpack Dev Server]”
   • [claimed-docs] “Docusaurus provides a [`docusaurus serve`](/docs/cli#docusaurus-serve-sitedir) command for that”
   • [claimed-docs] “All features are delegated to individual plugins: the docs feature provided by the docs plugin; the blog feature provided by the blog plugin…”
   • [claimed-docs] “A plugin is usually an npm package, so you install them like other npm packages using npm.”
   • [probe] “official CLI documented at https://docusaurus.io/docs/cli”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”

   proof ↗⚑ flag

5. ai-native userBuild against official SDKs

   weight 2 · round to Docusaurus
   ReadMe~partialprobed3/10

   ReadMe documents a public REST API and an official CLI (rdme) that developers can build against programmatically, but there is no evidence of dedicated official client SDKs in multiple languages (e.g., Python, Node, Go) for integrating with the ReadMe platform itself — 'Pick a language' refers to code-sample generation for the API reference of the docs being hosted, not an SDK for ReadMe. Missing for 10: explicit official multi-language SDKs, independent/hands-on validation of SDK quality, and clear API-vs-SDK distinction.

   • [claimed-docs] “Control your docs programmatically with the ReadMe API”
   • [probe] “official CLI documented at https://github.com/readmeio/rdme”
   • [claimed-docs] “Pick a language”

   proof ↗⚑ flag

   Docusaurus~partialprobed5/10

   Docusaurus documents official developer-facing APIs to build against — a plugin architecture (docs-4, docs-8, docs-25), theme swizzling API (docs-10, docs-27), and a documented CLI (docusaurus-probe-4, docusaurus-docs-11) — which count as 'official SDKs' for extending/building sites. However, there is no AI-native machine-readable SDK surface: llms.txt and docs.md both 404, and no OpenAPI spec exists (docusaurus-probe-1, docusaurus-probe-2, docusaurus-probe-3), so an AI agent cannot discover or consume an official SDK spec automatically. Missing for 10: machine-readable API/SDK manifests (llms.txt, OpenAPI), any AI-specific SDK or agent-facing integration docs, and independent confirmation that the plugin/theme APIs are stable enough to be treated as a true SDK.

   • [claimed-docs] “Extend and customize your project's layout by writing React components. Leverage the pluggable architecture, and design your own site while …”
   • [claimed-docs] “All features are delegated to individual plugins: the docs feature provided by the docs plugin; the blog feature provided by the blog plugin…”
   • [claimed-docs] “swizzling permits to swap a theme component with your own implementation”
   • [claimed-docs] “A plugin is usually an npm package, so you install them like other npm packages using npm.”
   • [probe] “official CLI documented at https://docusaurus.io/docs/cli”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round to ReadMe
   ReadMe✓fullcommunity8/10

   ReadMe's docs explicitly describe an interactive API reference where developers can make test calls and see real responses without writing code, backed by OpenAPI upload/management for generating that reference, and community feedback corroborates strong API reference/Swagger support versus alternatives. missing for 10: independent hands-on validation specifically of the 'runnable examples' UX (only vendor docs cited) and no direct AI-native user testimonial trying the runnable examples.

   • [claimed-docs] “developers can explore your API, make test calls right from the documentation, and see real responses without writing a single line of code”
   • [claimed-docs] “ReadMe makes it simple to transform your existing OAS file into beautiful, interactive documentation that your developers will actually enjo…”
   • [community] “My experience is that Readme has better support for Swagger compared to Docusaurus.”

   proof ↗⚑ flag

   Docusaurus—none0/10

   Docusaurus's evidence shows only generic MDX/React embedding, versioning, i18n, and search features—no built-in interactive API reference or runnable-example tooling (e.g., OpenAPI/Swagger integration) is documented, and probes for openapi.json/swagger.json all return 404. While MDX could theoretically host custom interactive widgets, there's no evidence of a first-party or documented capability for this specific story.

   • [claimed-docs] “Docusaurus has built-in support for MDX, which allows you to write JSX within your Markdown files and render them as React components.”
   • [claimed-docs] “You can also import your own components defined in other files or third-party components installed via npm.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   ReadMe—none0/10

   Evidence documents ReadMe's ability to upload/manage an OpenAPI spec to generate docs (readme-docs-23) and export docs/PDF files (readme-docs-13/29), but there is no evidence of a feature letting a user download the underlying OpenAPI spec (JSON/YAML) as a machine-readable artifact. Missing for 10: any documented spec-download endpoint, export-as-OpenAPI option, or explicit machine-readable API spec retrieval capability.

   • [claimed-docs] “ReadMe makes it simple to transform your existing OAS file into beautiful, interactive documentation that your developers will actually enjo…”
   • [claimed-docs] “You can export the files in your docs or as a PDF from the Branch menu.”
   • [claimed-docs] “You can export the files in your docs or as a PDF from the **Branch** menu.”

   proof ↗⚑ flag

   Docusaurus—none0/10

   Docusaurus is a documentation site generator, not an API service, but it could plausibly expose a machine-readable spec of its own CLI/config or plugin API; probes explicitly show no OpenAPI/swagger spec exists at any expected path, and no docs mention publishing one.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”

   proof ↗⚑ flag

3. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   ReadMe—none0/10

   Evidence shows ReadMe offers a 'Versions' feature for customers' own API docs (readme-docs-17, 48, 69) and exposes its own ReadMe API for programmatic control (readme-docs-87), but there is no documentation of a versioning scheme or deprecation policy for ReadMe's own API/product that an AI-native consumer could rely on.

   • [claimed-docs] “Maintaining multiple versions of your documentation is critical for many different technical products.”
   • [claimed-docs] “Maintain more than one version of your docs, covering version settings, the reader-facing dropdown, and common use”
   • [claimed-docs] “Maintain more than one version of your docs, covering version settings, the reader-facing dropdown, and common use cases.”
   • [claimed-docs] “Control your docs programmatically with the ReadMe API”

   proof ↗⚑ flag

   Docusaurus—none0/10

   The pack shows Docusaurus has a 'document versioning' feature for content (docs-6, docs-19, docs-23), but that is unrelated to the story's ask about the framework's own APIs (plugin API, config schema, npm package) being semantically versioned with a documented deprecation policy. No evidence of a changelog, semver policy, or deprecation notices for Docusaurus's own APIs is present; the only related note is that v2 was a 'total rewrite' from v1 (docusaurus-docs-16), which suggests breaking changes rather than a managed deprecation path.

   • [claimed-docs] “Docusaurus v2+ has been a total rewrite from Docusaurus v1, taking advantage of a completely modernized toolchain.”
   • [claimed-docs] “You can use the versioning CLI to create a new documentation version based on the latest content in the docs directory.”
   • [claimed-docs] “Support users on all versions of your project. Document versioning helps you keep documentation in sync with project releases.”

   proof ↗⚑ flag

Agent access

1. ai-native userMy published docs site exposes its own MCP server that my users' agents can query for search and page content

   weight 3 · round to ReadMe
   ReadMe✓fullprobed8/10

   ReadMe documents a per-project MCP server that gives AI agents/coding assistants a live connection to the API spec and docs, with dedicated analytics tracking every tool call made by AI clients, matching the story of an exposed queryable MCP server. missing for 10: no independent/hands-on confirmation of query quality or third-party agent testing, and no detail on search-specific tool schemas beyond general spec/doc access.

   • [claimed-docs] “Your MCP server gives AI coding assistants — Cursor, Claude Code, VS Code Copilot — a live connection to your API spec and documentation.”
   • [claimed-docs] “Your MCP server gives AI coding assistants — Cursor, Claude Code, VS Code Co”
   • [claimed-docs] “MCP”
   • [claimed-docs] “The MCP page in Analytics shows how many calls arrived, how quickly they returned, how many failed, and the query or endpoint behind each ca…”
   • [claimed-docs] “Every time an AI client calls a tool on your project's MCP server, ReadMe records the call. The MCP page in Analytics shows how many calls a…”
   • [claimed-docs] “See which tools AI agents call on your MCP server, how fast those calls return, and what”
   • [probe] “official MCP server documented at https://docs.readme.com/main/docs/your-projects-mcp-server”

   proof ↗⚑ flag

   Docusaurus—none0/10

   No evidence Docusaurus generates or exposes an MCP server for published docs sites; search is via Algolia DocSearch, not an agent-queryable MCP endpoint, and probes for llms.txt/docs.md/openapi all 404.

   • [claimed-docs] “Docusaurus provides first-class support for Algolia DocSearch.”
   • [claimed-docs] “Make it easy for your community to find what they need in your documentation. We proudly support Algolia documentation search.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”

   proof ↗⚑ flag

Agent output

1. ai-native userMy published docs site automatically serves llms.txt (and a full-content variant) so agents can index it

   weight 3 · round to ReadMe
   ReadMe✓fullprobed8/10

   A direct probe confirms docs.readme.com serves a live llms.txt (HTTP 200) that also documents a full-content variant via appending .md to any page URL — matching the story's ask exactly. This is reinforced by ReadMe's own docs being organized under numerous /llms.txt paths (e.g. customizing-docs/llms.txt, workflows/llms.txt, ai/llms.txt) and a dedicated 'AI Discoverability' feature (readme-docs-10/31/65) that scores published docs against an 'Agent-Friendly Docs spec,' indicating llms.txt generation is a first-class, cross-project capability rather than a one-off. Missing for 10: explicit first-party confirmation that llms.txt is auto-generated for arbitrary customer-published hubs (not just docs.readme.com itself), and independent/community corroboration of this specific feature.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.readme.com/llms.txt # ReadMe Documentation Documentation > Beautiful documentation made easy. App…”
   • [claimed-docs] “ReadMe crawls a sample of your published pages and scores your project against the Agent-Friendly Docs spec”
   • [claimed-docs] “ReadMe crawls a sample of your published pages and scores your project against the Agent-Friendly Docs spec, so you can see at a glance wher…”
   • [claimed-docs] “Make your documentation discoverable and accessible to AI agents and the assistant”
   • [claimed-docs] “Inject your users' API keys, server variables, and more!”
   • [claimed-docs] “Set your hub's look from four theme presets, then tune brand colors and typography in Appearance settings.”

   proof ↗⚑ flag

   Docusaurus—none0/10

   No evidence Docusaurus core ships automatic llms.txt or full-content markdown variant generation; direct probes of the Docusaurus own site show 404 for both llms.txt and docs.md, and no docs mention this feature.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”

   proof ↗⚑ flag

2. ai-native userEvery published page serves clean markdown at its URL (e.g. appending .md) so agents skip the HTML

   weight 3 · round to ReadMe
   ReadMe✓fullprobed7/10

   A direct probe of ReadMe's own docs site confirms the .md URL pattern works ('Append .md to any documentation page URL to...'), and ReadMe's AI-discoverability feature explicitly scores published customer pages against an 'Agent-Friendly Docs spec,' indicating this is a platform-wide capability, not just ReadMe's own site. Missing for 10: independent confirmation on a customer-hosted docs hub (not just docs.readme.com), third-party corroboration of the .md behavior across arbitrary published projects.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.readme.com/llms.txt # ReadMe Documentation Documentation > Beautiful documentation made easy. App…”
   • [claimed-docs] “ReadMe crawls a sample of your published pages and scores your project against the Agent-Friendly Docs spec”
   • [claimed-docs] “ReadMe crawls a sample of your published pages and scores your project against the Agent-Friendly Docs spec, so you can see at a glance wher…”
   • [claimed-docs] “Make your documentation discoverable and accessible to AI agents and the assistant”
   • [claimed-docs] “Your docs, now agent-ready”

   proof ↗⚑ flag

   Docusaurus—none0/10

   Docusaurus builds static HTML from Markdown/MDX but there is no evidence of a per-page clean-markdown endpoint (e.g. .md suffix) or llms.txt-style output; direct probes confirm llms.txt and docs.md both 404, indicating this capability is not shipped.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”
   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served.”

   proof ↗⚑ flag

Assistant

1. ai-native userAn embedded AI assistant on my docs site answers reader questions with citations into my content

   weight 2 · round to ReadMe
   ReadMe~partialclaimed6/10

   ReadMe's 'Ask AI' feature is documented as giving readers instant answers from published documentation directly inside the hub, matching the core story of an embedded assistant answering questions from docs content, but the evidence never confirms it surfaces explicit citations/links into specific content, and there's no independent or hands-on verification of this behavior. missing for 10: explicit documentation or proof that Ask AI cites/links specific source pages, independent/community confirmation of citation quality.

   • [claimed-docs] “Ask AI gives your users instant answers from your published documentation, directly inside your hub.”

   proof ↗⚑ flag

   Docusaurus—none0/10

   No evidence of an embedded AI assistant or Q&A-with-citations feature; Docusaurus documentation covers search (Algolia DocSearch), MDX, plugins, versioning, i18n, etc., but nothing about an AI chat/assistant answering reader questions with citations into content.

   ⚑ flag

Analytics

1. devrel leadI see page views, search terms, and reader feedback so I know which docs work and which fail

   weight 2 · round to ReadMe
   ReadMe~partialclaimed5/10

   ReadMe documents Docs/API Metrics Charts and a Developer Metrics API that show 'how people use your docs and how developers use your API' (page views/usage), and Suggest in GitHub lets readers flag typos or share feedback, giving DevRel leads usage and feedback signals. However, there is no explicit documentation of search-term tracking/analytics, and no independent or hands-on evidence validating the depth or accuracy of these analytics dashboards. Missing for 10: explicit search-query/search-term analytics, quantified reader feedback/ratings dashboard, independent corroboration of the metrics feature's usefulness.

   • [claimed-docs] “With ReadMe's API Metrics, you have reports on API call volume, endpoint usage, and errors that give you insights into your best use cases”
   • [claimed-docs] “API & Docs Metrics Charts”
   • [claimed-docs] “See how people use your docs and how developers use your API”
   • [claimed-docs] “They can use Suggest in GitHub to flag typos or share user feedback.”
   • [claimed-docs] “Anyone consuming your public documentation (developers, partners, etc.). They can use Suggest in GitHub to flag typos or share user feedback…”
   • [claimed-docs] “Suggesting changes from GitHub allows anyone reading your document”

   proof ↗⚑ flag

   Docusaurus—none0/10

   Docusaurus is a static site generator; evidence shows search (Algolia DocSearch) support but nothing about built-in analytics dashboards, page-view tracking, search-term analytics, or reader feedback collection. No evidence of any such capability exists in the pack.

   ⚑ flag

Playground

1. developerReaders can try real API calls from an interactive playground embedded in the reference docs

   weight 2 · round to ReadMe
   ReadMe✓fullcommunity8/10

   ReadMe's docs explicitly describe an interactive API reference where developers can make real test calls and see actual responses without writing code, and independent community feedback corroborates ReadMe's strong Swagger/OpenAPI-based reference experience. Missing for 10: independent hands-on confirmation specifically of the try-it-out call execution (vs. general praise) and details on auth/key injection during live calls.

   • [claimed-docs] “developers can explore your API, make test calls right from the documentation, and see real responses without writing a single line of code”
   • [claimed-docs] “ReadMe makes it simple to transform your existing OAS file into beautiful, interactive documentation that your developers will actually enjo…”
   • [community] “My experience is that Readme has better support for Swagger compared to Docusaurus.”

   proof ↗⚑ flag

   Docusaurus—none0/10

   Docusaurus is a static-site/documentation generator supporting MDX, React embeds, versioning, i18n, and search, but nothing in the evidence pack shows a built-in interactive API playground/try-it-out console for making real API calls; probes for OpenAPI support also failed (404s). Developers could theoretically embed a custom React component for this via MDX, but no evidence shows an out-of-the-box or officially supported playground feature.

   • [claimed-docs] “Docusaurus has built-in support for MDX, which allows you to write JSX within your Markdown files and render them as React components.”
   • [claimed-docs] “You can also import your own components defined in other files or third-party components installed via npm.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”

   proof ↗⚑ flag

Spec driven

1. developerMy API reference pages are generated from an OpenAPI spec and stay in sync when the spec changes

   weight 3 · round to ReadMe
   ReadMe✓fullcommunity8/10

   ReadMe explicitly supports transforming an OpenAPI spec into interactive API reference docs (readme-docs-23), documents accepted OpenAPI versions/file types (readme-docs-32), and offers Git-based workflows to manage API definitions in source control with docs updating from spec changes (readme-docs-44, readme-docs-68). Independent community feedback also notes ReadMe's strong Swagger/OpenAPI support relative to alternatives (readme-comm-7). Missing for 10: no first-party or independent evidence detailing automatic re-sync behavior when the spec file is updated post-publish (e.g., webhook/CI-triggered re-ingestion) or hands-on confirmation of staying in sync over time.

   • [claimed-docs] “ReadMe makes it simple to transform your existing OAS file into beautiful, interactive documentation that your developers will actually enjo…”
   • [claimed-docs] “Check which OpenAPI versions and file types ReadMe accepts, and what your definition gives your API Refe”
   • [claimed-docs] “Run documentation entirely through Git, with Markdown and OpenAPI in your repository and pull requests as the review step.”
   • [claimed-docs] “Manage API definitions in Git while your team writes docs in ReadMe, for o”
   • [community] “My experience is that Readme has better support for Swagger compared to Docusaurus.”

   proof ↗⚑ flag

   Docusaurus—none0/10

   No evidence pack item mentions OpenAPI spec import, API reference page generation, or spec-sync capability; Docusaurus core is described as a Markdown/MDX static-site generator with docs/blog/pages plugins, not an OpenAPI-driven doc generator. The OpenAPI probe explicitly found no such endpoints/support.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”
   • [claimed-docs] “All features are delegated to individual plugins: the docs feature provided by the docs plugin; the blog feature provided by the blog plugin…”
   • [claimed-docs] “All features are delegated to individual plugins: the [docs](/docs/docs-introduction) feature provided by the [docs plugin]”

   proof ↗⚑ flag

Authoring

1. technical writerI author pages in Markdown/MDX with rich components — tabs, callouts, code groups, steps — without writing custom HTML

   weight 3 · round to Docusaurus
   ReadMe~partialclaimed5/10

   ReadMe documents Markdown/MDX authoring with JSX syntax support (readme-docs-42, 81) and slash-command Mermaid diagrams (readme-docs-60), plus reusable Markdown blocks (readme-docs-24, 43), which supports building rich pages without raw HTML. However, the evidence never explicitly names built-in components like tabs, callouts, code groups, or step lists — only MDX/JSX generically and diagrams. Missing for 10: explicit documentation of tabs/callout/code-group/step components, and independent/hands-on confirmation of their availability.

   • [claimed-docs] “Write MDX in ReadMe, including the JSX syntax and the places where it behaves differently from plain Markdown.”
   • [claimed-docs] “MDX”
   • [claimed-docs] “Add flowcharts, sequence diagrams, and other Mermaid diagrams to your docs with a slash command, written as text rather than images.”
   • [claimed-docs] “Reusable Content lets ReadMe Admins create Markdown blocks that appear across multiple pages. When you edit a block, the system updates all …”
   • [claimed-docs] “Create reusable blocks of Markdown content to use repeatedly across your pr”
   • [claimed-docs] “Write long-form tutorials, walkthroughs, and explanations that sit beside your API Reference, in Markdown with MDX support.”

   proof ↗⚑ flag

   Docusaurus~partialcommunity6/10

   Docusaurus docs confirm built-in MDX/JSX support letting writers embed and import React components directly in Markdown without hand-writing HTML (docusaurus-docs-3, docusaurus-docs-17, docusaurus-docs-31, docusaurus-docs-32), and community users confirm using Markdown+React together happily (docusaurus-comm-13, docusaurus-comm-20). However, the evidence never explicitly names or documents the specific built-in rich components the story calls out (Tabs, admonitions/callouts, code-block groups, Steps) — it only shows general MDX/component-embedding capability. missing for 10: explicit docs citing built-in Tabs/Admonition/CodeBlock-group/Steps components, and hands-on confirmation that writers use them without custom code.

   • [claimed-docs] “Docusaurus has built-in support for MDX, which allows you to write JSX within your Markdown files and render them as React components.”
   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served. You can even embed React co…”
   • [claimed-docs] “You can also import your own components defined in other files or third-party components installed via npm.”
   • [claimed-docs] “You can even embed React components in your Markdown thanks to MDX.”
   • [community] “Long time user of (and contributor to) Docusaurus. I use it to build my markdown powered tech blog. It is very much a Goldilocks product for…”
   • [community] “I moved from 11ty / eleventy to docusaurus... Very active project. Nice theme out of the box / configuration. Better than any static site ge…”

   proof ↗⚑ flag

2. technical writerNon-technical teammates can edit docs in a visual web editor without touching git, and their changes flow into the same source of truth

   weight 2 · round to ReadMe
   ReadMe✓fullclaimed8/10

   ReadMe provides a visual web editor (Guides/API Reference pages, inline AI editing) alongside bi-directional Git sync, so non-technical teammates can edit in the hub without touching git while changes sync to the same underlying source via branches/reviews. Suggest in GitHub and Reviews further support non-engineer contribution flows feeding into one source of truth. Missing for 10: independent/hands-on evidence (beyond vendor docs) confirming non-technical teammates specifically use the visual editor smoothly, and no explicit description of a WYSIWYG editor UI distinct from Markdown/MDX editing.

   • [claimed-docs] “Write in your preferred environment whether that's ReadMe or your local development setup.”
   • [claimed-docs] “Bi-directional sync creates a two-way connection between your ReadMe project and a GitHub or GitLab repository.”
   • [claimed-docs] “Connect your project to a GitHub, GitLab, or Bitbucket repos”
   • [claimed-docs] “Create and review documentation changes in isolation, so nothing reaches your live hub until your team has approved it.”
   • [claimed-docs] “Reviews are an optional, but highly recommended, feature to help maintain quality in your docs.”
   • [claimed-docs] “Reviews allow you to check your changes for issues with the AI Linter or get approval from a teammate.”
   • [claimed-docs] “They can use Suggest in GitHub to flag typos or share user feedback.”
   • [claimed-docs] “When you select text, a prompt field appears in the formatting toolbar where you can type plain-language instructions and let the Agent appl…”
   • [claimed-docs] “The Agent is a powerful documentation assistant that helps you create, edit, and enhance content across Guides, API References, Custom Pages…”

   proof ↗⚑ flag

   Docusaurus—none0/10

   Docusaurus is a git-based, MDX/React static site generator with no visual web editor for non-technical users — all editing happens via markdown files and git workflows; no evidence of a WYSIWYG editor or non-git content sync.

   ⚑ flag

Content reuse

1. technical writerReusable snippets and variables keep repeated content in sync across pages

   weight 1 · round to ReadMe
   ReadMe✓fullclaimed8/10

   ReadMe's Reusable Content feature lets admins create Markdown blocks reused across multiple pages, with edits automatically propagating to every instance ('Edit once, update everywhere'), directly matching the snippet-sync story; variables are less explicitly documented separately. missing for 10: dedicated documentation/example of a distinct 'variables' feature (vs. reusable Markdown blocks) and independent/hands-on corroboration beyond vendor docs.

   • [claimed-docs] “Edit once, update everywhere”
   • [claimed-docs] “Reusable Content lets ReadMe Admins create Markdown blocks that appear across multiple pages. When you edit a block, the system updates all …”

   proof ↗⚑ flag

   Docusaurus~partialclaimed6/10

   Docusaurus's MDX support lets writers define partial files and import them as reusable components across pages (docs-3, docs-31), which is the documented mechanism for reusable snippets, but the evidence pack never explicitly mentions a dedicated 'variables' or site-wide constants feature (e.g. customFields) or admonition-style snippet reuse guidance. missing for 10: explicit docs on site-wide variables/customFields, dedicated partials/snippets guide, independent hands-on confirmation that content stays in sync across pages.

   • [claimed-docs] “Docusaurus has built-in support for MDX, which allows you to write JSX within your Markdown files and render them as React components.”
   • [claimed-docs] “You can also import your own components defined in other files or third-party components installed via npm.”
   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served. You can even embed React co…”

   proof ↗⚑ flag

Quality

1. technical writerAutomated checks lint my content against a style guide and flag issues before they publish

   weight 2 · round to ReadMe
   ReadMe✓fullclaimed7/10

   ReadMe's Linter lets writers define natural-language style rules (e.g., 'Use active voice') that check every page, and Docs Audit runs those rules across the whole site to flag outdated content, broken links, and style inconsistencies before publishing; Reviews also let content be checked with the AI Linter before going live. missing for 10: independent/hands-on evidence of linting accuracy, no detail on pre-publish blocking/gating enforcement, and no third-party corroboration of the feature working in practice.

   • [claimed-docs] “You write rules in natural language — like "Use active voice" or "Flag placeholder text" — and it checks every page against them”
   • [claimed-docs] “Docs Audit runs your Linter rules against every page in your project in a single pass, so you can find outdated content, broken links, and s…”
   • [claimed-docs] “Docs Audit runs your Linter rules against every page in your project in a single pass, so you can find outdated content, broken links, and s…”
   • [claimed-docs] “An AI-powered tool for checking page content against your own style guide.”
   • [claimed-docs] “Score your entire documentation against your style guide in one run.”
   • [claimed-docs] “Reviews allow you to check your changes for issues with the AI Linter or get approval from a teammate.”

   proof ↗⚑ flag

   Docusaurus—none0/10

   No evidence of any built-in or first-party linting/style-guide checking feature for content; Docusaurus docs cover MDX authoring, versioning, i18n, search, deployment, but nothing about automated prose/style linting before publish.

   ⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to ReadMe
   ReadMe~partialprobed4/10

   ReadMe offers a Docs Audit that runs Linter rules across every page in one pass (readme-docs-7, readme-docs-25, readme-docs-52) and an rdme CLI plus ReadMe API for programmatic control (readme-docs-87, readme-probe-3), which enable some bulk-style operations across many docs/pages. However there's no direct evidence of bulk operations across arbitrary 'items' (e.g., batch endpoint edits, bulk publish/delete, bulk API reference updates) beyond the audit/linter and CLI/API scripting potential. missing for 10: explicit bulk edit/publish/delete UI or API examples, documented batch size/limits, independent hands-on confirmation of bulk workflows succeeding at scale.

   • [claimed-docs] “Docs Audit runs your Linter rules against every page in your project in a single pass, so you can find outdated content, broken links, and s…”
   • [claimed-docs] “Docs Audit runs your Linter rules against every page in your project in a single pass, so you can find outdated content, broken links, and s…”
   • [claimed-docs] “Score your entire documentation against your style guide in one run.”
   • [claimed-docs] “Control your docs programmatically with the ReadMe API”
   • [probe] “official CLI documented at https://github.com/readmeio/rdme”

   proof ↗⚑ flag

   Docusaurus—none0/10

   Docusaurus is a static site generator with a CLI for building/serving sites, but there is no evidence of any bulk operation capability across many content items (e.g., bulk editing, batch content transformation, mass metadata updates) beyond a single site build/version command; probes for machine-readable APIs (llms.txt, docs.md, openapi) all returned 404, showing no programmatic bulk-automation surface. Missing for 10: any documented bulk-edit/batch-processing feature, API or CLI subcommand for operating across many items at once, and evidence of AI-native automation tooling.

   • [claimed-docs] “Builds and serves a preview of your site locally with Webpack Dev Server.”
   • [claimed-docs] “You can use the versioning CLI to create a new documentation version based on the latest content in the docs directory.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”

   proof ↗⚑ flag

Theming

1. devrel leadI customize themes, fonts, and layout — down to custom CSS/JS or my own components — so the docs match my brand

   weight 2 · round to Docusaurus
   ReadMe✓fullcommunity8/10

   ReadMe's docs explicitly cover theme presets with brand color/typography tuning, custom CSS (variables or raw rules), custom JavaScript and include tags, custom domain/SSL, and MDX support for custom components, directly matching the DevRel branding customization story. A community testimonial (Heap Analytics) also corroborates the visual customization experience in practice. Missing for 10: independent/hands-on verification of deep custom-JS/component work beyond vendor docs, and no evidence of a fully custom component framework beyond MDX.

   • [claimed-docs] “Customize your docs with CSS using either CSS variables or custom CSS rules.”
   • [claimed-docs] “Customize your docs with CSS using either CSS variables or custom CSS rules. The most flexible is to use CSS variables.”
   • [claimed-docs] “Set your hub's look from four theme presets, then tune brand colors and typography in Appearance settings.”
   • [claimed-docs] “Apply your own CSS, JavaScript, and include tags to your hub, with the plan requirements and toggles for each.”
   • [claimed-docs] “Host your docs on your own domain, covering CNAME setup, apex domains versus subdomains, and SSL certificates.”
   • [claimed-docs] “Write MDX in ReadMe, including the JSX syntax and the places where it behaves differently from plain Markdown.”
   • [claimed-docs] “Use Font Awesome 7 Regular and Duotone icons in your docs, including how to hide a decorative icon from screen readers.”
   • [community] “Heap Analytics moved docs to ReadMe.io: 'The ReadMe team is really responsive and helpful, the documentation is beautiful and the interface …”

   proof ↗⚑ flag

   Docusaurus✓fullcommunity9/10

   Docusaurus provides multiple documented layers of theming/branding: custom CSS import via classic theme (docusaurus-docs-9/26/41), full React component customization and MDX embedding (docusaurus-docs-4/31/33), and swizzling to override/replace built-in theme components entirely (docusaurus-docs-10/27), plus a plugin architecture for deeper extension (docusaurus-docs-8/40). Community testimonials corroborate real-world use of React/TypeScript/CSS customization (docusaurus-comm-13/20). Missing for 10: independent hands-on verification specifically of brand-level theming (fonts/logo/full rebrand) rather than general customization mentions.

   • [claimed-docs] “you can create your own CSS files (e.g. /src/css/custom.css) and import them globally by passing them as an option of the classic theme.”
   • [claimed-docs] “If you're using `@docusaurus/preset-classic`, you can create your own CSS files (e.g. `/src/css/custom.css`) and import them globally”
   • [claimed-docs] “swizzling permits to swap a theme component with your own implementation”
   • [claimed-docs] “swizzling permits to **swap a theme component with your own implementation**”
   • [claimed-docs] “Extend and customize your project's layout by writing React components. Leverage the pluggable architecture, and design your own site while …”
   • [claimed-docs] “You can also import your own components defined in other files or third-party components installed via npm.”
   • [claimed-docs] “Extend and customize your project's layout by writing React components.”
   • [claimed-docs] “All features are delegated to individual plugins: the docs feature provided by the docs plugin; the blog feature provided by the blog plugin…”
   • [community] “Long time user of (and contributor to) Docusaurus. I use it to build my markdown powered tech blog. It is very much a Goldilocks product for…”
   • [community] “I moved from 11ty / eleventy to docusaurus... Very active project. Nice theme out of the box / configuration. Better than any static site ge…”

   proof ↗⚑ flag

Git workflow

1. developerMy docs live in my own git repository — branches, pull requests, and merges drive what gets published

   weight 3 · round drawn
   ReadMe✓fullclaimed8/10

   ReadMe supports bi-directional GitHub/GitLab/Bitbucket sync, git-based workflows with Markdown/OpenAPI in-repo, pull requests as the review step, and branch-based review before publishing (readme-docs-26, readme-docs-44, readme-docs-45, readme-docs-46, readme-docs-67, readme-docs-70, readme-docs-68). This directly matches docs-as-code with branches/PRs/merges driving publishing. missing for 10: independent/hands-on confirmation of the git-sync workflow in practice (community evidence is thin/tangential) and more detail on merge conflict handling.

   • [claimed-docs] “Bi-directional sync creates a two-way connection between your ReadMe project and a GitHub or GitLab repository.”
   • [claimed-docs] “Run documentation entirely through Git, with Markdown and OpenAPI in your repository and pull requests as the review step.”
   • [claimed-docs] “Create and review documentation changes in isolation, so nothing reaches your live hub until your team has approved it.”
   • [claimed-docs] “Connect your project to a GitHub, GitLab, or Bitbucket repos”
   • [claimed-docs] “Sync with GitHub”
   • [claimed-docs] “Manage API definitions in Git while your team writes docs in ReadMe, for o”
   • [claimed-docs] “Branches allow admins to save changes across pages without them going live immediately.”

   proof ↗⚑ flag

   Docusaurus✓fullcommunity8/10

   Docusaurus is fundamentally a static-site generator that builds from Markdown/MDX files stored in your own repo, and its docs plugin explicitly reads content from a `docs` directory that you version-control (versioning CLI operates on `docs` directory content), with localization also handled 'via git' or other translation managers. It deploys to static hosts like GitHub Pages, Netlify, Vercel that are commonly wired to git push/PR/merge triggers, and community users confirm using it for markdown-based docs-as-code workflows (migrating docs, contributing via git). Missing for 10: no explicit documentation of PR-preview builds, branch-based deploy previews, or CI/CD pipeline configuration specifics.

   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served.”
   • [claimed-docs] “All features are delegated to individual plugins: the docs feature provided by the docs plugin; the blog feature provided by the blog plugin…”
   • [claimed-docs] “Localization comes out-of-the-box. Use git, Crowdin, or any other translation manager to translate your docs and deploy them individually.”
   • [claimed-docs] “You can use the versioning CLI to create a new documentation version based on the latest content in the `docs` directory.”
   • [claimed-docs] “You can deploy your site to static site hosting services such as [Vercel](https://vercel.com/), [GitHub Pages](https://pages.github.com/), […”
   • [community] “Long time user of (and contributor to) Docusaurus. I use it to build my markdown powered tech blog. It is very much a Goldilocks product for…”
   • [community] “I moved from 11ty / eleventy to docusaurus... Very active project. Nice theme out of the box / configuration. Better than any static site ge…”

   proof ↗⚑ flag

Quality gates

1. developerCI validation catches broken links and invalid configuration before the site publishes

   weight 2 · round drawn
   ReadMe—none0/10

   ReadMe's docs mention Docs Audit/Linter for style/broken-link checks and Reviews as a manual approval gate, and bi-directional sync with Git, but there is no evidence of a CI pipeline check (e.g., rdme CLI command or GitHub Action) that validates links/config and blocks a publish/merge automatically before the site goes live. missing for 10: evidence of an automated CI/CD integration (CLI command or GitHub Action) that runs link/config validation and fails the build pre-publish, and any confirmation that Docs Audit/Linter can be invoked as a CI gate rather than a manual dashboard action.

   • [claimed-docs] “Docs Audit runs your Linter rules against every page in your project in a single pass, so you can find outdated content, broken links, and s…”
   • [claimed-docs] “Docs Audit runs your Linter rules against every page in your project in a single pass, so you can find outdated content, broken links, and s…”
   • [claimed-docs] “Reviews are an optional, but highly recommended, feature to help maintain quality in your docs.”
   • [claimed-docs] “Create and review documentation changes in isolation, so nothing reaches your live hub until your team has approved it.”
   • [probe] “official CLI documented at https://github.com/readmeio/rdme”

   proof ↗⚑ flag

   Docusaurus—none0/10

   No evidence pack items mention broken-link checking, config validation, or CI integration/build-failure behavior for invalid content; only build/serve/deploy CLI commands are documented. This is a fair axis for a docs-as-code SSG (Docusaurus does have onBrokenLinks options in reality, but nothing in the evidence pack supports it).

   ⚑ flag

1. ai-native userExport all of my data in open formats and leave

   weight 3 · round to Docusaurus
   ReadMe~partialclaimed5/10

   ReadMe supports exporting docs files or PDF from the Branch menu, giving some data portability, but this is limited to documentation content and PDF/file export, not a full open-format export of all underlying data (API metrics, analytics, custom pages, versions, reusable content blocks) in machine-readable open formats like JSON/Markdown source. missing for 10: evidence of exporting all account/project data (metrics, settings, versions) in open formats, confirmation of underlying file format (e.g., raw Markdown vs proprietary), and independent/hands-on confirmation of a full data export and migration path away from ReadMe.

   • [claimed-docs] “You can export the files in your docs or as a PDF from the Branch menu.”
   • [claimed-docs] “You can export the files in your docs or as a PDF from the **Branch** menu.”

   proof ↗⚑ flag

   Docusaurus✓fullcommunity8/10

   Docusaurus content is authored as plain Markdown/MDX files stored in the user's own git repo and compiled to static HTML, meaning there is no proprietary data store to 'export from' — the source of truth is already an open, portable format the user fully owns, reinforced by MIT licensing and git/Crowdin-based translation workflows. missing for 10: no explicit vendor documentation framing this as a 'data export/exit' guarantee, and no independent report confirming users successfully migrated away with zero data loss (only anecdotal mentions of switching to other SSGs).

   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served.”
   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served. You can even embed React co…”
   • [claimed-docs] “To build the static files of your website for production, run: npm run build”
   • [claimed-docs] “Once it finishes, the static files will be generated within the `build` directory.”
   • [claimed-docs] “Localization comes out-of-the-box. Use git, Crowdin, or any other translation manager to translate your docs and deploy them individually.”
   • [claimed-docs] “Use git, Crowdin, or any other translation manager to translate your docs and deploy them individually.”
   • [community] “It's probably also a good thing that Facebook dogfoods Docusaurus in some places, while keeping it MIT licensed so the community can fork it…”
   • [community] “For writing technical styled documentation, I've found fumadocs to be amazing... We just moved to it from Docusaurus and couldn't be happier…”

   proof ↗⚑ flag

2. ai-native userRead the product's source under an open license

   weight 2 · round to Docusaurus
   ReadMe—none0/10

   ReadMe is a closed, proprietary SaaS documentation platform; there is no evidence of its core product source being released under an open license (only a CLI tool 'rdme' is open-source, not the product itself). No evidence supports an open-license source availability for the platform.

   ⚑ flag

   Docusaurus✓fullcommunity7/10

   Community evidence confirms Docusaurus is open source and MIT licensed, with users noting they can read, fork, and contribute to the source code (docusaurus-comm-16, docusaurus-comm-1). No evidence contradicts open licensing. missing for 10: first-party documentation or GitHub repo citation explicitly stating the MIT license, and no direct link to the source repository in the evidence pack.

   • [community] “It's probably also a good thing that Facebook dogfoods Docusaurus in some places, while keeping it MIT licensed so the community can fork it…”
   • [community] “So happy to see Docusaurus hit the big 2.0! I use it to power my blog and it's a tremendous tool. The DX is fantastic and it's open source! …”

   proof ↗⚑ flag

3. ai-native userSelf-host the core product

   weight 3 · round to Docusaurus
   ReadMe—none0/10

   ReadMe is a SaaS-only hosted documentation platform; there is no evidence of a self-hostable core product, Docker image, or on-prem deployment option. Community evidence even shows a user switching to open-source Docusaurus specifically to avoid ReadMe's hosted costs, and a request for an open-source-friendly plan went unmet, further indicating no self-hosting path exists.

   • [community] “Wish there was a plan for opensource projects, which allowed me to use customized landing page etc.”
   • [community] “Blog post titled 'From Readme to Docusaurus: How an Intern Saved Us $1.2k', describing a switch away from ReadMe.com to the open-source Docu…”

   proof ↗⚑ flag

   Docusaurus✓fullcommunity9/10

   Docusaurus is a static-site generator that builds fully self-hostable static HTML output via `npm run build`, deployable to any static host (Vercel, Netlify, GitHub Pages, or self-managed servers) with no vendor lock-in, and is MIT licensed so it can be forked/self-maintained indefinitely. Community evidence corroborates real-world self-hosting and even forking concerns being addressed by its open license. Missing for 10: no first-party Docker/container self-hosting guide or independent benchmark of a fully self-hosted deployment pipeline.

   • [claimed-docs] “To build the static files of your website for production, run: npm run build”
   • [claimed-docs] “Once it finishes, the static files will be generated within the `build` directory.”
   • [claimed-docs] “You can deploy your site to static site hosting services such as [Vercel](https://vercel.com/), [GitHub Pages](https://pages.github.com/), […”
   • [claimed-docs] “Docusaurus provides a [`docusaurus serve`](/docs/cli#docusaurus-serve-sitedir) command for that”
   • [community] “It's probably also a good thing that Facebook dogfoods Docusaurus in some places, while keeping it MIT licensed so the community can fork it…”
   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served.”

   proof ↗⚑ flag

1. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   ReadMe—none0/10

   No evidence in the pack addresses telemetry or usage-tracking opt-out settings for ReadMe; nothing describes data collection controls or privacy toggles. Missing for 10: any documentation of telemetry practices, an opt-out mechanism, or privacy settings related to usage tracking.

   ⚑ flag

   Docusaurus—none0/10

   The evidence pack contains no mention of telemetry, analytics collection, or an opt-out mechanism for Docusaurus's CLI or build process; while such a capability is plausible for a CLI-driven static site generator, there is no documentation or community evidence confirming it exists.

   ⚑ flag

Access control

1. devrel leadI gate some or all docs behind authentication — password, JWT, or SSO — for customers-only content

   weight 1 · round drawn
   ReadMe—none0/10

   Evidence covers SSO only for internal Teammates sign-in (readme-docs-84) and admin permission control (readme-docs-63), but nothing describes gating published customer-facing docs behind password, JWT, or SSO authentication for readers/customers. missing for 10: reader-facing password protection, JWT-based authenticated docs, SSO gating for external customers viewing docs.

   • [claimed-docs] “Connect your identity provider and let Teammates sign in with SSO”
   • [claimed-docs] “Control who can access admin controls and edit content.”

   proof ↗⚑ flag

   Docusaurus—none0/10

   Docusaurus is a static site generator; the evidence pack contains no mention of built-in authentication, password protection, JWT, or SSO gating features. Since Docusaurus builds static HTML files meant to be publicly served (docs-2, docs-13), auth-gating is a plausible but unaddressed capability for a docs publishing tool, making this 'none' rather than 'na'.

   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served.”
   • [claimed-docs] “To build the static files of your website for production, run: npm run build”
   • [claimed-docs] “Once it finishes, the static files will be generated within the `build` directory.”

   proof ↗⚑ flag

Domains

1. devrel leadI serve docs on my own custom domain or as a /docs subpath of my main site

   weight 2 · round to ReadMe
   ReadMe✓fullclaimed8/10

   ReadMe's docs explicitly cover custom domain setup with CNAME, apex vs subdomain, and SSL certificates, framed as making docs 'polished and professional' on a company domain, which directly matches the custom-domain part of the story; the /docs subpath scenario is implicitly covered via apex/subdomain configuration options. Missing for 10: explicit first-party or independent confirmation of serving docs specifically as a path-based /docs subpath (vs subdomain) on the main domain.

   • [claimed-docs] “Hosting docs on your company domain is an important part of making your docs polished and professional. You can setup a custom domain from *…”
   • [claimed-docs] “Host your docs on your own domain, covering CNAME setup, apex domains versus subdomains, and SSL certificates.”
   • [claimed-docs] “Custom Domain & SSL”

   proof ↗⚑ flag

   Docusaurus~partialclaimed5/10

   Docusaurus docs confirm it builds static files deployable to common static hosts (Vercel, GitHub Pages, Netlify, etc.) and provides a `docusaurus serve` command, which implicitly supports custom domains via those hosts. However, the evidence pack never explicitly documents the `baseUrl` config for subpath deployment or custom-domain setup instructions (e.g., CNAME files), leaving the core of the story only inferred rather than directly evidenced. Missing for 10: explicit docs on baseUrl/subpath configuration, explicit custom-domain setup guidance, and independent confirmation of successful custom-domain/subpath deployments.

   • [claimed-docs] “You can deploy your site to static site hosting services such as [Vercel](https://vercel.com/), [GitHub Pages](https://pages.github.com/), […”
   • [claimed-docs] “Docusaurus provides a [`docusaurus serve`](/docs/cli#docusaurus-serve-sitedir) command for that”
   • [claimed-docs] “To build the static files of your website for production, run: npm run build”
   • [claimed-docs] “Once it finishes, the static files will be generated within the `build` directory.”

   proof ↗⚑ flag

Portability

1. developerExport my entire docs site as a static bundle and host it anywhere, so my content is never locked in

   weight 2 · round to Docusaurus
   ReadMe~partialclaimed3/10

   ReadMe docs mention exporting files or a PDF from the Branch menu, which shows some content-export capability, but there is no evidence of exporting the entire docs site as a deployable static bundle (with API reference, navigation, styling, etc.) that can be self-hosted elsewhere — the product is fundamentally a hosted SaaS platform. missing for 10: full static-site export/bundle, documentation of self-hosting elsewhere, independent confirmation that exported files constitute a complete replica of the hosted site.

   • [claimed-docs] “You can export the files in your docs or as a PDF from the Branch menu.”
   • [claimed-docs] “You can export the files in your docs or as a PDF from the **Branch** menu.”

   proof ↗⚑ flag

   Docusaurus✓fullclaimed9/10

   Docusaurus builds static HTML files via `npm run build` into a `build` directory, which can be hosted on any static host (Vercel, GitHub Pages, Netlify, Render, Surge) or served locally via `docusaurus serve`, confirming no vendor lock-in. Community comments corroborate real-world deployment and migration flexibility. Missing for 10: no independent hands-on verification of exporting/re-hosting a site across multiple providers beyond docs claims.

   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served.”
   • [claimed-docs] “To build the static files of your website for production, run: npm run build”
   • [claimed-docs] “Once it finishes, the static files will be generated within the `build` directory.”
   • [claimed-docs] “You can deploy your site to static site hosting services such as [Vercel](https://vercel.com/), [GitHub Pages](https://pages.github.com/), […”
   • [claimed-docs] “Docusaurus provides a [`docusaurus serve`](/docs/cli#docusaurus-serve-sitedir) command for that”

   proof ↗⚑ flag

Search

1. developerReaders get fast, typo-tolerant, relevance-ranked search over the whole docs site out of the box

   weight 3 · round to Docusaurus
   ReadMe—none0/10

   The evidence pack describes Ask AI (AI-generated answers from docs) and MCP/agent discoverability features, but contains no mention of a traditional full-text search index, typo-tolerance, or relevance ranking for the docs site itself. Search-discovery via a classic search bar is a plausible axis for a docs platform, but no evidence confirms it delivers fast, typo-tolerant, relevance-ranked search out of the box.

   • [claimed-docs] “Ask AI gives your users instant answers from your published documentation, directly inside your hub.”
   • [claimed-docs] “Ask AI gives your users instant answers from your published documentat”
   • [claimed-docs] “ReadMe crawls a sample of your published pages and scores your project against the Agent-Friendly Docs spec”

   proof ↗⚑ flag

   Docusaurus~partialclaimed5/10

   Docusaurus does not ship its own out-of-the-box search index; it relies on integrating third-party Algolia DocSearch, which requires a separate application/setup and free-tier approval, and there's a migration note suggesting the infra has changed over time. Typo-tolerant, relevance-ranked search is achieved via Algolia (once configured), not built-in by default. missing for 10: evidence of a zero-config/built-in local search out of the box, independent confirmation of Algolia's typo-tolerance/ranking quality in practice, and details on setup friction or fallback for sites not approved for free DocSearch.

   • [claimed-docs] “Docusaurus provides first-class support for Algolia DocSearch.”
   • [claimed-docs] “You can read more about migration from the legacy DocSearch infra in our blog post”
   • [claimed-docs] “Make it easy for your community to find what they need in your documentation. We proudly support Algolia documentation search.”
   • [claimed-docs] “The service is **free** for any developer documentation or technical blog: just make sure to read the [checklist]”
   • [claimed-docs] “We proudly support Algolia documentation search.”

   proof ↗⚑ flag

Localization

1. technical writerI publish my docs in multiple languages with translated navigation and content

   weight 1 · round to Docusaurus
   ReadMe—none0/10

   No evidence of multi-language documentation publishing, translated navigation, or i18n/localization features; 'Pick a language' (readme-docs-2) refers to code-sample language selection, not content localization. Versioning docs (readme-docs-17, readme-docs-48) address content versions, not language translation.

   ⚑ flag

   Docusaurus✓fullclaimed9/10

   Docusaurus has built-in i18n support explicitly designed for translating docs and navigation, with support for git/Crowdin translation workflows and RTL locales, plus versioning to keep translated docs in sync with releases. Missing for 10: independent hands-on verification of translated navigation specifically (community evidence focuses on other features, not i18n workflows).

   • [claimed-docs] “It is easy to translate a Docusaurus website with its internationalization (i18n) support.”
   • [claimed-docs] “Localization comes out-of-the-box. Use git, Crowdin, or any other translation manager to translate your docs and deploy them individually.”
   • [claimed-docs] “It is **easy to translate a Docusaurus website** with its internationalization ([i18n](https://en.wikipedia.org/wiki/Internationalization_an…”
   • [claimed-docs] “Use git, Crowdin, or any other translation manager to translate your docs and deploy them individually.”
   • [claimed-docs] “**RTL support**: locales reading right-to-left (Arabic, Hebrew, etc.) are supported and easy to implement”

   proof ↗⚑ flag

Versioning

1. developerI publish versioned documentation per product or API version, and readers switch versions from the site

   weight 3 · round to Docusaurus
   ReadMe~partialclaimed5/10

   ReadMe's docs explicitly state that maintaining multiple versions of documentation is a supported, important feature (readme-docs-17), confirming per-product/API version publishing capability. However, the evidence pack contains no detail on the actual version-switcher UI or reader-facing mechanism for switching versions from the site, nor any independent/community confirmation of this workflow. Missing for 10: documentation or screenshots of the reader-facing version switcher, confirmation of how versions map to distinct URLs/hubs, and independent corroboration that readers can toggle versions seamlessly.

   • [claimed-docs] “Maintaining multiple versions of your documentation is critical for many different technical products.”

   proof ↗⚑ flag

   Docusaurus✓fullclaimed9/10

   Docusaurus has built-in, well-documented versioning support (versioning CLI to snapshot docs directory into a version, version dropdown for readers to switch) and dedicated docs on this exact workflow, plus i18n for localization. No independent hands-on corroboration specifically for the versioning UX is present, and no evidence of a version-switcher dropdown being explicitly named, so missing for 10: independent/community confirmation of the version-switch UI in practice, edge-case coverage for large numbers of versions.

   • [claimed-docs] “You can use the versioning CLI to create a new documentation version based on the latest content in the docs directory.”
   • [claimed-docs] “Support users on all versions of your project. Document versioning helps you keep documentation in sync with project releases.”
   • [claimed-docs] “You can use the versioning CLI to create a new documentation version based on the latest content in the `docs` directory.”
   • [claimed-docs] “It is **easy to translate a Docusaurus website** with its internationalization ([i18n](https://en.wikipedia.org/wiki/Internationalization_an…”

   proof ↗⚑ flag