GitBook vs ReadMe

Agent access

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

   weight 2 · round to ReadMe
   GitBook✓fullprobed8/10

   GitBook publishes an official llms.txt (confirmed live via probe) plus llms-full.txt, a dedicated 'LLM-ready docs' guide, and even an 'agent-score' tool to check how well AI agents can parse docs, alongside MCP servers for published docs enabling agent access. This directly satisfies pointing an agent at llms.txt/agent-oriented docs for any GitBook-hosted site. Missing for 10: independent third-party validation that agents actually consume llms.txt effectively in practice, and docs.md endpoint returned 404 suggesting inconsistent markdown-mirroring coverage.

   • [probe] “PROBE llms.txt: HTTP 200 at https://gitbook.com/llms.txt # GitBook > GitBook is a collaborative platform for creating, publishing and manag…”
   • [claimed-docs] “LLM-ready docs”
   • [claimed-docs] “Write in the editor, drive it from your agent, or sync from Git.”
   • [claimed-docs] “See how easily AI agents can reach, parse, and use your documentation.”
   • [claimed-docs] “MCP servers for published docs”
   • [probe] “PROBE docs-md: HTTP 404 at https://gitbook.com/docs.md”

   proof ↗⚑ flag

   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

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

   weight 2 · round to ReadMe
   GitBook~partialcommunity5/10

   GitBook offers a REST API (gitbook-docs-36), a CLI that can list orgs/inspect content/build integrations from the shell (gitbook-docs-28, gitbook-docs-34), and Git Sync for docs-as-code workflows (gitbook-docs-4, gitbook-docs-27) — all of which support scripted/automated use outside the UI. However, there is no explicit documentation of headless/CI-specific usage (e.g., CI pipeline examples, non-interactive auth flows, exit codes) and the CLI's OSS/self-hosted precursor was explicitly deprecated by the vendor per community evidence (gitbook-comm-17), raising doubt about current automation tooling maturity. Missing for 10: explicit CI/headless run documentation, examples of scripted pipelines, and confirmation the current CLI is actively maintained for automation use cases.

   • [claimed-docs] “GitBook CLI”
   • [claimed-docs] “list organizations, inspect spaces and pages, ask questions against your docs, and build and publish integrations — all without leaving the …”
   • [claimed-docs] “GitHub & GitLab Sync”
   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”
   • [community] “GitBook README cited as reason for community fork: 'As the efforts of the GitBook team are focused on the GitBook.com platform, the CLI is n…”

   proof ↗⚑ flag

   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

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round drawn
   GitBook—none0/10

   Evidence documents GitBook publishing its own MCP server so external AI agents (Claude Code, Cursor, etc.) can call GitBook's tools (gitbook-docs-14, gitbook-docs-15, gitbook-docs-33, gitbook-probe-4) — this is GitBook acting as an MCP server, not as an MCP client consuming external servers' tools. There is no evidence that GitBook's own AI Assistant or Agent can be configured to plug in and call third-party MCP servers.

   • [claimed-docs] “New: The GitBook MCP server is here. Connect your AI agent”
   • [claimed-docs] “MCP servers for published docs”
   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”
   • [probe] “official MCP server documented at https://gitbook.com/docs/docs-as-code/gitbook-mcp”

   proof ↗⚑ flag

   ReadMe—none0/10

   All MCP-related evidence describes ReadMe publishing its own MCP server so external AI coding assistants (Cursor, Claude Code, VS Code Copilot) can call ReadMe's API/docs tools (readme-docs-3, readme-docs-34, readme-probe-2) — this is the server role, the opposite of what the story asks. There is no evidence that ReadMe's own AI features (Ask AI, AI Agent, GitHub AI Writer) can connect to and consume external MCP servers as a client.

   • [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”
   • [probe] “official MCP server documented at https://docs.readme.com/main/docs/your-projects-mcp-server”
   • [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

4. ai-native userConnect an agent via an official MCP server

   weight 3 · round drawn
   GitBook✓fullprobed8/10

   GitBook documents an official MCP server ('GitBook MCP server is here. Connect your AI agent') that lets MCP clients like Claude Code, Codex, and Cursor create/configure sites, open change requests, draft content, edit pages, and restructure docs — a clear agent-connectivity capability, not just consuming other MCP servers. Missing for 10: independent/hands-on verification of the MCP server's reliability and no third-party corroboration beyond vendor docs.

   • [claimed-docs] “New: The GitBook MCP server is here. Connect your AI agent”
   • [claimed-docs] “MCP servers for published docs”
   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”
   • [probe] “official MCP server documented at https://gitbook.com/docs/docs-as-code/gitbook-mcp”

   proof ↗⚑ flag

   ReadMe✓fullprobed8/10

   ReadMe documents an official, project-specific MCP server that gives AI coding assistants (Cursor, Claude Code, VS Code Copilot) a live connection to API specs/docs, backed by dedicated MCP metrics/analytics and confirmed live via probe. missing for 10: independent/hands-on third-party verification that the MCP connection works as described beyond first-party docs.

   • [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] “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] “MCP Metrics”
   • [probe] “official MCP server documented at https://docs.readme.com/main/docs/your-projects-mcp-server”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round to GitBook
   GitBook✓fullclaimed7/10

   GitBook publishes an official CLI (gitbook-docs-28) documented to let users list organizations, inspect spaces/pages, ask questions against docs, and build/publish integrations 'without leaving the shell' (gitbook-docs-34), directly matching an AI-native CLI story alongside its MCP server for agent tooling. missing for 10: independent/hands-on verification of the CLI's current functionality and any AI-native workflow examples beyond first-party docs (the only community CLI comment found refers to the legacy, unrelated open-source book-building CLI, not this one).

   • [claimed-docs] “GitBook CLI”
   • [claimed-docs] “list organizations, inspect spaces and pages, ask questions against your docs, and build and publish integrations — all without leaving the …”
   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   GitBook✓fullprobed8/10

   GitBook documents a RESTful public API supporting standard HTTP methods (GET/POST/PATCH/DELETE) with a full API reference, plus a CLI and an MCP server that let agents create/configure sites, open change requests, draft and edit content programmatically — directly enabling AI-native users to drive the product outside the UI. Missing for 10: a discoverable machine-readable OpenAPI spec (probe-3 shows all common OpenAPI paths 404) and independent/hands-on corroboration of the API's robustness beyond vendor docs.

   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”
   • [claimed-docs] “GitBook CLI”
   • [claimed-docs] “list organizations, inspect spaces and pages, ask questions against your docs, and build and publish integrations — all without leaving the …”
   • [claimed-docs] “New: The GitBook MCP server is here. Connect your AI agent”
   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”
   • [probe] “official MCP server documented at https://gitbook.com/docs/docs-as-code/gitbook-mcp”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gitbook.com/openapi.json, https://gitbook.com/swagger.json, https://gitbook.com/api/openapi.…”

   proof ↗⚑ flag

   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

7. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round drawn
   GitBook—none0/10

   GitBook exposes a general REST API and an MCP server for AI agents, but no evidence describes scoped or least-privilege API credentials/tokens, granular permission scopes, or agent-specific access controls for its API keys — only generic 'authenticated access' for site audiences is mentioned, which is unrelated to credential scoping.

   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”
   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”
   • [claimed-docs] “Authenticated access”

   proof ↗⚑ flag

   ReadMe—none0/10

   While ReadMe exposes an MCP server and a general ReadMe API, the evidence pack contains no mention of issuing scoped or least-privilege API credentials specifically for AI agents (e.g., agent-specific API keys, permission scopes, or token restrictions) — only general API key injection for docs personalization and generic API access control.

   ⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round to ReadMe
   GitBook—none0/10

   Evidence shows GitBook has a REST API (gitbook-docs-36), a CLI (gitbook-docs-28/34), and an MCP server (gitbook-docs-14/15/33), but there is no mention anywhere of official client SDKs (e.g., JS/Python/Go libraries) for developers to build against. Missing for 10: any official SDK documentation, package registry listings, or language-specific client libraries.

   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”
   • [claimed-docs] “GitBook CLI”
   • [claimed-docs] “list organizations, inspect spaces and pages, ask questions against your docs, and build and publish integrations — all without leaving the …”

   proof ↗⚑ flag

   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

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to GitBook
   GitBook✓fullclaimed7/10

   GitBook documents an 'AI insights' analytics feature that shows what visitors ask and how AI Assistant answers using site content, plus an AI documentation agent that identifies outdated content and drafts improvements — both are AI-generated insights/suggestions surfaced inside the product. Evidence is vendor-documented only, without independent hands-on corroboration of accuracy or usefulness. missing for 10: independent/community validation of AI insights quality, more detail on suggestion actionability beyond docs pages.

   • [claimed-docs] “AI insights”
   • [claimed-docs] “AI insights shows what your visitors are asking and how effectively GitBook Assistant responds using your content.”
   • [claimed-docs] “GitBook’s AI documentation agent identifies missing or outdated content, drafts improvements, and helps your team keep product knowledge ali…”
   • [claimed-docs] “The docs platform that flags outdated content. Then fixes it.”

   proof ↗⚑ flag

   ReadMe~partialclaimed6/10

   ReadMe offers AI-generated insights within the product itself: the AI Linter/Docs Audit checks content against natural-language rules, the AI Agent and Inline AI can draft/rewrite/enhance content, and Ask AI surfaces answers from docs; API/MCP Metrics also surface usage insights though these are analytics dashboards rather than AI-generated suggestions. However, evidence is entirely vendor documentation with no independent/hands-on validation of the AI suggestions' quality or accuracy. missing for 10: independent/hands-on evidence of AI insight quality, examples of AI-generated suggestions in practice, and confirmation that analytics (metrics) include AI-driven interpretation rather than raw charts.

   • [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] “The Agent is a powerful documentation assistant that helps you create, edit, and enhance content across Guides, API References, Custom Pages…”
   • [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] “Draft, edit, and research documentation from the AI chat panel.”
   • [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] “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] “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…”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to GitBook
   GitBook~partialclaimed5/10

   GitBook advertises a background 'GitBook Agent' that autonomously flags outdated content, drafts fixes, and auto-translates docs without user intervention (gitbook-docs-1, gitbook-docs-38, gitbook-docs-41), which is a real form of autonomous background automation. However, there's no evidence of a general-purpose automation/workflow builder (triggers, schedules, custom rules) that AI-native users could configure themselves. Missing for 10: a documented automation/rules engine or scheduler users can configure, independent confirmation these agent behaviors run unattended reliably, and broader automation scope beyond content-freshness/translation.

   • [claimed-docs] “The docs platform that flags outdated content. Then fixes it.”
   • [claimed-docs] “GitBook’s AI documentation agent identifies missing or outdated content, drafts improvements, and helps your team keep product knowledge ali…”
   • [claimed-docs] “Auto translations make it easy to keep your documentation up-to-date in multiple languages, with minimal manual effort.”
   • [claimed-docs] “Review change requests with GitBook Agent”

   proof ↗⚑ flag

   ReadMe~partialclaimed4/10

   The GitHub AI Writer feature watches pull requests in the background and autonomously proposes documentation updates when code changes affect docs (readme-docs-8), which is the only evidence of a background automation. However, this is a single fixed integration (not a general automation framework), still requires human review/approval before changes go live (readme-docs-12/27), and there's no evidence of user-configurable autonomous background jobs, schedules, or triggers beyond this one PR-watching feature. missing for 10: general-purpose automation/workflow builder, evidence of fully unattended (no-approval) execution, multiple autonomous background triggers beyond PR-watching, independent confirmation of autonomy in practice.

   • [claimed-docs] “The GitHub AI Writer keeps your documentation in sync with your codebase by watching your pull requests and proposing updates when code chan…”
   • [claimed-docs] “Reviews allow you to check your changes for issues with the AI Linter or get approval from a teammate.”
   • [claimed-docs] “Reviews are an optional, but highly recommended, feature to help maintain quality in your docs.”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to GitBook
   GitBook✓fullclaimed7/10

   GitBook ships a built-in 'GitBook AI Assistant' that answers reader questions from docs content, and a separate 'GitBook Agent' that can identify outdated content, draft improvements, and review change requests — both are native, first-party AI delegation features distinct from external MCP integrations. Missing for 10: independent/hands-on user reports validating real task delegation and reliability of the assistant/agent beyond vendor docs.

   • [claimed-docs] “AI Assistant”
   • [claimed-docs] “I'm here to help you with the docs.”
   • [claimed-docs] “Add it to your product, website, or docs to give every user accurate, contextual answers.”
   • [claimed-docs] “GitBook’s AI documentation agent identifies missing or outdated content, drafts improvements, and helps your team keep product knowledge ali…”
   • [claimed-docs] “Review change requests with GitBook Agent”
   • [claimed-docs] “AI insights shows what your visitors are asking and how effectively GitBook Assistant responds using your content.”

   proof ↗⚑ flag

   ReadMe~partialclaimed6/10

   ReadMe ships an in-product 'Agent' documentation assistant that creates, edits, and enhances content across Guides, API References, and Custom Pages, plus inline AI editing via natural-language prompts — a genuine built-in AI assistant users can delegate documentation tasks to. However, this is scoped to docs authoring/editing tasks, not general task delegation, and there's no independent/hands-on corroboration of the Agent's reliability or scope beyond vendor docs. missing for 10: independent or hands-on verification of the Agent's capabilities and limits, evidence of broader task delegation beyond content editing, and any community feedback on the Agent feature specifically.

   • [claimed-docs] “The Agent is a powerful documentation assistant that helps you create, edit, and enhance content across Guides, API References, Custom Pages…”
   • [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…”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to GitBook
   GitBook✓fullprobed8/10

   GitBook ships an official MCP server that lets AI agents (Claude Code, Codex, Cursor, etc.) create/configure sites, open change requests, draft and edit content, and restructure docs via natural-language instructions, plus a CLI and AI Assistant that can answer questions and act against docs conversationally. This directly matches 'operate via natural-language commands' for an AI-native user. Missing for 10: independent/hands-on verification of MCP command reliability and breadth (all evidence is vendor docs, no community testing of the agent workflow).

   • [claimed-docs] “New: The GitBook MCP server is here. Connect your AI agent”
   • [claimed-docs] “MCP servers for published docs”
   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”
   • [claimed-docs] “list organizations, inspect spaces and pages, ask questions against your docs, and build and publish integrations — all without leaving the …”
   • [claimed-docs] “Agent skills”
   • [probe] “official MCP server documented at https://gitbook.com/docs/docs-as-code/gitbook-mcp”

   proof ↗⚑ flag

   ReadMe~partialclaimed6/10

   ReadMe's Agent and Inline AI let users edit and enhance docs content via plain-language prompts, and the Linter lets you define documentation rules in natural language, showing genuine NL-driven operation of core content-editing workflows. However, this is scoped to content editing rather than full product operation (e.g., configuring project settings, analytics, or publishing via NL commands), and there's no independent/hands-on corroboration beyond first-party docs. Missing for 10: evidence of NL control over broader product functions (settings, analytics, admin tasks) and independent verification of the Agent/Inline AI working as described.

   • [claimed-docs] “The Agent is a powerful documentation assistant that helps you create, edit, and enhance content across Guides, API References, Custom Pages…”
   • [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] “You write rules in natural language — like "Use active voice" or "Flag placeholder text" — and it checks every page against them”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to ReadMe
   GitBook✓fullclaimed7/10

   GitBook explicitly supports OpenAPI specs with interactive playgrounds that 'let your users test endpoints right on the page with interactive blocks,' plus a documented API reference, directly enabling runnable API docs. Missing for 10: independent/hands-on verification of the interactive playground working in practice, and more detail on the range of runnable example types beyond OpenAPI.

   • [claimed-docs] “Interactive API playgrounds”
   • [claimed-docs] “Add an OpenAPI specification”
   • [claimed-docs] “let your users test endpoints right on the page with interactive blocks”
   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   GitBook—none0/10

   Probes explicitly show all candidate OpenAPI/spec endpoints (openapi.json, swagger.json, etc.) return 404, and there is no documentation link to download a machine-readable spec of GitBook's own API — the 'Add an OpenAPI specification' docs describe a feature for customers embedding specs in their own docs, not GitBook's own API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://gitbook.com/openapi.json, https://gitbook.com/swagger.json, https://gitbook.com/api/openapi.…”
   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”
   • [claimed-docs] “Add an OpenAPI specification”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   GitBook—none0/10

   The evidence shows GitBook has a REST API (gitbook-docs-36) and features for versioning documentation content (gitbook-docs-24), but there is no mention of a versioning scheme or deprecation policy for GitBook's own platform API, and probes for a discoverable OpenAPI spec all returned 404s (gitbook-probe-3), giving no indication of documented API stability guarantees.

   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”
   • [claimed-docs] “Version control”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gitbook.com/openapi.json, https://gitbook.com/swagger.json, https://gitbook.com/api/openapi.…”

   proof ↗⚑ flag

   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

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
   GitBook✓fullprobed7/10

   GitBook explicitly documents 'MCP servers for published docs' and a general MCP server that AI agents can connect to for querying docs, directly matching the story of published sites exposing an MCP endpoint for search/page content. Missing for 10: no independent/hands-on verification of the published-docs MCP server's search/content-query behavior, and no detail on the exact query capabilities exposed.

   • [claimed-docs] “New: The GitBook MCP server is here. Connect your AI agent”
   • [claimed-docs] “MCP servers for published docs”
   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”
   • [probe] “official MCP server documented at https://gitbook.com/docs/docs-as-code/gitbook-mcp”

   proof ↗⚑ flag

   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

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 drawn
   GitBook✓fullprobed8/10

   GitBook has a dedicated 'LLM-ready docs' feature page and references an llms-full.txt variant in docs, and a live probe confirms https://gitbook.com/llms.txt actually returns 200 with real content, corroborating the vendor claim. Missing for 10: direct probe confirmation of the llms-full.txt variant and evidence it's automatically enabled across arbitrary customer-published sites, not just gitbook.com itself.

   • [claimed-docs] “LLM-ready docs”
   • [claimed-docs] “Write in the editor, drive it from your agent, or sync from Git.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://gitbook.com/llms.txt # GitBook > GitBook is a collaborative platform for creating, publishing and manag…”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   GitBook✓fullprobed7/10

   GitBook explicitly documents an 'LLM-ready docs' feature and the evidence pack itself cites numerous live GitBook docs pages at .md-suffixed URLs (e.g. gitbook-mcp.md, ai-insights.md, customization.md), strongly implying published pages do serve raw markdown when .md is appended; llms.txt is also confirmed live via probe. The one 404 probe (gitbook.com/docs.md) tested a non-page root path rather than an actual content page, so it doesn't concretely contradict the pattern seen elsewhere. Missing for 10: a controlled hands-on test appending .md to an actual customer-published site page (not gitbook.com's own docs) and independent third-party confirmation beyond the vendor's own citations.

   • [claimed-docs] “LLM-ready docs”
   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”
   • [claimed-docs] “Write in the editor, drive it from your agent, or sync from Git.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://gitbook.com/llms.txt # GitBook > GitBook is a collaborative platform for creating, publishing and manag…”
   • [probe] “PROBE docs-md: HTTP 404 at https://gitbook.com/docs.md”

   proof ↗⚑ flag

   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

Assistant

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

   weight 2 · round to GitBook
   GitBook✓fullclaimed8/10

   GitBook documents a first-party AI Assistant embeddable on published docs sites that answers reader questions grounded in the site's own content, plus AI insights analytics showing what visitors ask and how the assistant responds using that content. missing for 10: explicit confirmation/example that assistant answers include inline citations/links to source pages, and independent (non-vendor) hands-on validation of citation accuracy.

   • [claimed-docs] “AI Assistant”
   • [claimed-docs] “I'm here to help you with the docs.”
   • [claimed-docs] “Add it to your product, website, or docs to give every user accurate, contextual answers.”
   • [claimed-docs] “AI insights shows what your visitors are asking and how effectively GitBook Assistant responds using your content.”
   • [claimed-docs] “AI search”

   proof ↗⚑ flag

   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

Writer agent

1. ai-native userA platform AI agent drafts, updates, and reviews my docs — from a prompt, a PR, or a schedule — and ships its work as change requests

   weight 2 · round to GitBook
   GitBook✓fullclaimed7/10

   GitBook Agent is documented as identifying missing/outdated content, drafting improvements, and shipping changes via change requests, with a dedicated review workflow (gitbook-agent/review-change-requests-with-gitbook-agent) and MCP/CLI integration letting agents open change requests, draft content, and restructure docs from prompts or Git workflows. However, evidence for explicit PR-triggered or schedule-triggered automation is thin/implied rather than concretely documented, and there's no independent/hands-on corroboration of the agent's output quality. Missing for 10: explicit scheduled-trigger documentation, concrete PR-triggered workflow details, and independent verification of the agent's drafting/review quality.

   • [claimed-docs] “GitBook’s AI documentation agent identifies missing or outdated content, drafts improvements, and helps your team keep product knowledge ali…”
   • [claimed-docs] “Review change requests with GitBook Agent”
   • [claimed-docs] “Change requests”
   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”
   • [claimed-docs] “Write in the editor, drive it from your agent, or sync from Git.”
   • [claimed-docs] “Agent skills”

   proof ↗⚑ flag

   ReadMe~partialclaimed7/10

   ReadMe documents an AI Agent that drafts/edits content from natural-language prompts (readme-docs-18, readme-docs-19), a GitHub AI Writer that watches PRs and proposes doc updates when code changes (readme-docs-8, readme-docs-53), and a Reviews/branches workflow where changes are held until approved (readme-docs-12, readme-docs-27, readme-docs-45, readme-docs-70) — functioning like change requests. However there is no evidence of a schedule-triggered agent run, and it's unclear whether GitHub AI Writer output surfaces as an actual GitHub pull request versus an internal ReadMe branch/review. Missing for 10: schedule-based trigger evidence, and explicit confirmation that agent output is submitted as a GitHub PR/change request rather than only an internal review branch.

   • [claimed-docs] “The Agent is a powerful documentation assistant that helps you create, edit, and enhance content across Guides, API References, Custom Pages…”
   • [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 GitHub AI Writer keeps your documentation in sync with your codebase by watching your pull requests and proposing updates when code chan…”
   • [claimed-docs] “Proposes documentation updates when pull requests change your codebase.”
   • [claimed-docs] “Reviews allow you to check your changes for issues with the AI Linter or get approval from a teammate.”
   • [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.”
   • [claimed-docs] “Branches allow admins to save changes across pages without them going live immediately.”
   • [claimed-docs] “Run documentation entirely through Git, with Markdown and OpenAPI in your repository and pull requests as the review step.”

   proof ↗⚑ flag

Analytics

1. ai-native userMy docs analytics distinguish AI-agent traffic from human traffic so I can see who — or what — is actually reading

   weight 2 · round to ReadMe
   GitBook—none0/10

   GitBook's analytics docs mention general 'Analytics & user feedback' and 'AI insights' (which tracks questions asked to the AI Assistant) and an 'Agent Score' for AI accessibility, but none of these describe segmenting or labeling raw site traffic as AI-agent vs. human visitors. No evidence shows a dashboard breakdown of bot/agent traffic vs. human pageviews.

   • [claimed-docs] “Analytics & user feedback”
   • [claimed-docs] “AI insights”
   • [claimed-docs] “AI insights shows what your visitors are asking and how effectively GitBook Assistant responds using your content.”
   • [claimed-docs] “See how easily AI agents can reach, parse, and use your documentation.”

   proof ↗⚑ flag

   ReadMe~partialclaimed6/10

   ReadMe's MCP Metrics page explicitly tracks calls made by AI agents/clients to a project's MCP server (calls, latency, failures, per-tool breakdown), which functions as dedicated AI-agent-traffic analytics distinct from human page-view metrics. However, this only covers MCP tool-call traffic, not a unified dashboard that tags/distinguishes AI crawlers or AI agent readers from human visitors across regular docs page views and API Metrics. Missing for 10: evidence of AI-vs-human classification within general docs pageview/API Metrics (not just MCP), and any UI showing side-by-side human vs agent traffic breakdown.

   • [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”
   • [claimed-docs] “MCP Metrics”
   • [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”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   GitBook~partialcommunity5/10

   GitBook's pricing/docs pages claim 'Analytics & user feedback' and 'AI insights' that show 'what your visitors are asking and how effectively GitBook Assistant responds,' plus a search feature; one HN reviewer separately praised GitBook's search as 'fast & accurate.' However, page-view analytics accuracy is called into question by a hands-on community report that 'traffic stats are not realistic (counts page loads, off by 2-3x vs Google Analytics), country demographics clearly wrong,' and no evidence documents an explicit reader-feedback widget/mechanism beyond the pricing bullet. Missing for 10: dedicated documentation of a feedback-collection UI, independent corroboration of analytics accuracy, and confirmation the cited stats complaint doesn't still apply to the current platform.

   • [claimed-docs] “Analytics & user feedback”
   • [claimed-docs] “AI insights”
   • [claimed-docs] “AI insights shows what your visitors are asking and how effectively GitBook Assistant responds using your content.”
   • [claimed-docs] “Searching internal content”
   • [community] “'I'm using gitbook to write a book currently... its an excellent platform for writers. Most of the product is open-source... Version control…”
   • [community] “'GoCD moved its user & developer docs to GitBook... and its been great so far! The best feature by far is fast & accurate search.'”

   proof ↗⚑ flag

   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

Playground

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

   weight 2 · round to ReadMe
   GitBook✓fullclaimed7/10

   GitBook's docs explicitly advertise 'Interactive API playgrounds' as a pricing feature and describe OpenAPI integration that lets users 'test endpoints right on the page with interactive blocks,' directly matching the story. Missing for 10: independent/hands-on third-party confirmation of the playground actually executing live API calls, and more detail on auth/response handling within the playground.

   • [claimed-docs] “Interactive API playgrounds”
   • [claimed-docs] “Add an OpenAPI specification”
   • [claimed-docs] “let your users test endpoints right on the page with interactive blocks”

   proof ↗⚑ flag

   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

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
   GitBook~partialclaimed6/10

   GitBook explicitly supports adding an OpenAPI specification to generate API reference pages with interactive playgrounds (gitbook-docs-23, gitbook-docs-5, gitbook-docs-35), and it has Git-sync/version-control features that could keep specs updated (gitbook-docs-27, gitbook-docs-24). However, no evidence explicitly confirms automatic re-sync/regeneration of reference pages when the underlying OpenAPI spec file changes (e.g. webhook-triggered refresh), only general 'flags outdated content' branding (gitbook-docs-1) without specifics tied to OpenAPI. Missing for 10: explicit documentation of automatic spec-change detection/refresh workflow, and independent/hands-on confirmation that the sync actually works reliably.

   • [claimed-docs] “Add an OpenAPI specification”
   • [claimed-docs] “Interactive API playgrounds”
   • [claimed-docs] “let your users test endpoints right on the page with interactive blocks”
   • [claimed-docs] “GitHub & GitLab Sync”
   • [claimed-docs] “Version control”
   • [claimed-docs] “The docs platform that flags outdated content. Then fixes it.”

   proof ↗⚑ flag

   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

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 GitBook
   GitBook~partialcommunity7/10

   GitBook's docs confirm a block-based visual editor with custom blocks and Markdown/MDX authoring (gitbook-docs-3, gitbook-docs-46), plus a concrete example of a rich block (the 'updates' changelog block with auto RSS) showing the block system is real (gitbook-docs-44). Community reviews independently praise the web editor and Markdown support (gitbook-comm-3, gitbook-comm-5). However, the pack never explicitly names tabs, callouts, code-groups, or step components, so the exact component set the story cites isn't directly confirmed. Missing for 10: explicit documentation/screenshots naming tabs/callouts/code-group/step blocks, and independent hands-on confirmation of those specific components.

   • [claimed-docs] “Block-based visual editor & custom blocks”
   • [claimed-docs] “GitBook’s AI-native visual editor makes it easy to write, review, and publish technical content — with Markdown, real-time collaboration, ve…”
   • [claimed-docs] “An updates block lets you add a changelog to any page... Any page with an updates block automatically gets an RSS feed”
   • [community] “'I'm using gitbook to write a book currently... its an excellent platform for writers. Most of the product is open-source... Version control…”
   • [community] “'I've been using GitBook since the early days, and it has improved significantly... The web-based book editor is phenomenal, and it is perfe…”

   proof ↗⚑ flag

   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

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 drawn
   GitBook✓fullcommunity8/10

   GitBook's visual block-based editor is explicitly designed for non-git users, with real-time collaboration and version control built in, and the same content syncs bidirectionally with Git ('Write in the editor, drive it from your agent, or sync from Git'), keeping one source of truth. Community reviews independently corroborate the web editor experience as 'phenomenal' and suited for non-developers writing docs with version control. Missing for 10: no independent evidence specifically confirming non-technical teammates' edits merge cleanly with git-synced changes without conflicts, and no hands-on account from a non-technical user's perspective.

   • [claimed-docs] “Block-based visual editor & custom blocks”
   • [claimed-docs] “Invite your team to collaborate”
   • [claimed-docs] “Change requests”
   • [claimed-docs] “GitBook’s AI-native visual editor makes it easy to write, review, and publish technical content — with Markdown, real-time collaboration, ve…”
   • [claimed-docs] “Write in the editor, drive it from your agent, or sync from Git.”
   • [claimed-docs] “GitHub & GitLab Sync”
   • [community] “'I've been using GitBook since the early days, and it has improved significantly... The web-based book editor is phenomenal, and it is perfe…”
   • [community] “'I'm using gitbook to write a book currently... its an excellent platform for writers. Most of the product is open-source... Version control…”

   proof ↗⚑ flag

   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

Content reuse

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

   weight 1 · round drawn
   GitBook✓fullclaimed8/10

   GitBook's docs explicitly document a 'Reusable content' feature for defining reusable snippets/blocks that sync across pages, plus 'Content variants' for variable-driven content reuse, directly matching the story. missing for 10: independent/hands-on community corroboration specifically about snippet/variable syncing (community evidence in the pack covers other features, not this one).

   • [claimed-docs] “Reusable content”
   • [claimed-docs] “Content variants”

   proof ↗⚑ flag

   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

Quality

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

   weight 2 · round to ReadMe
   GitBook—none0/10

   GitBook's AI features (agent, assistant, AI insights) focus on flagging outdated/missing content and answering reader questions, not on linting prose against a style guide before publishing. No evidence of style-guide rules, vale-like linting, or pre-publish content-quality checks tied to a style guide.

   ⚑ flag

   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

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

   weight 2 · round to GitBook
   GitBook~partialprobed5/10

   GitBook exposes a REST API (GET/POST/PATCH/DELETE) and an MCP server/CLI that agents can use to create/configure sites, open change requests, draft content, edit pages, and restructure docs, which enables scripted bulk-style operations across many pages/spaces programmatically. However, there's no first-party bulk-operations UI or documented batch endpoints (e.g., bulk update/delete/move across many items in one call), and no independent evidence of bulk workflows being used at scale. missing for 10: dedicated bulk-edit/batch API endpoints, documented bulk UI actions, and independent confirmation of large-scale automation use.

   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”
   • [claimed-docs] “list organizations, inspect spaces and pages, ask questions against your docs, and build and publish integrations — all without leaving the …”
   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”
   • [claimed-docs] “GitBook CLI”
   • [probe] “official MCP server documented at https://gitbook.com/docs/docs-as-code/gitbook-mcp”

   proof ↗⚑ flag

   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

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round drawn
   GitBook—none0/10

   GitBook's docs describe autonomous AI behaviors (auto-flagging outdated content, auto-translations, AI insights) and git-based sync triggers, but there is no evidence of a user-configurable rules/automation engine where users define custom event→action triggers (e.g., webhooks, if-this-then-that logic). Missing for 10: any documented rules/trigger builder, webhook or event-condition-action framework, or examples of users defining custom automation logic.

   ⚑ flag

   ReadMe—none0/10

   ReadMe offers linting rules, GitHub sync, and AI writer proposals, but these are triggered by manual runs or PR events for documentation maintenance, not a general-purpose 'define rules that trigger arbitrary actions on events' automation engine for AI-native users. No evidence of a rules/automation/webhook engine letting users define custom event-triggered actions. missing for 10: an event-trigger/automation rules engine, webhook or conditional action framework, evidence of user-defined triggers beyond docs linting/sync.

   • [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] “The GitHub AI Writer keeps your documentation in sync with your codebase by watching your pull requests and proposing updates when code chan…”
   • [claimed-docs] “Bi-directional sync creates a two-way connection between your ReadMe project and a GitHub or GitLab repository.”

   proof ↗⚑ flag

3. ai-native userVersion, review, and roll back my automations

   weight 1 · round drawn
   GitBook~partialclaimed5/10

   GitBook supports versioning of docs via Git sync/version control and review via Change Requests (including AI-agent-authored changes reviewed by 'GitBook Agent'), which maps loosely to versioning/reviewing AI-driven changes, but there is no explicit documentation of an 'automations' concept (e.g., agent workflows) being versioned or rolled back as a distinct object — only content/page-level version control and change-request review are evidenced. Missing for 10: explicit rollback mechanism for automations, evidence of automation objects (not just docs content) under version control, independent confirmation of the review/rollback workflow.

   • [claimed-docs] “Version control”
   • [claimed-docs] “GitHub & GitLab Sync”
   • [claimed-docs] “Change requests”
   • [claimed-docs] “Review change requests with GitBook Agent”
   • [claimed-docs] “GitBook’s AI-native visual editor makes it easy to write, review, and publish technical content — with Markdown, real-time collaboration, ve…”

   proof ↗⚑ flag

   ReadMe~partialclaimed5/10

   ReadMe supports versioning of docs content (readme-docs-17), review workflows with AI Linter/teammate approval (readme-docs-12, readme-docs-27), and bi-directional git sync (readme-docs-26) which implicitly enables rollback via git history for AI-driven changes like the GitHub AI Writer's proposed updates (readme-docs-8). However, none of this is framed specifically around 'automations' as a distinct object with version/review/rollback controls — it's inferred from general docs versioning and git integration rather than a dedicated automation-management feature. Missing for 10: an explicit rollback mechanism/UI for AI Agent or automation actions, direct evidence connecting review/versions to 'automations' specifically, and independent corroboration of this workflow in practice.

   • [claimed-docs] “Maintaining multiple versions of your documentation is critical for many different technical products.”
   • [claimed-docs] “Reviews allow you to check your changes for issues with the AI Linter or get approval from a teammate.”
   • [claimed-docs] “Reviews are an optional, but highly recommended, feature to help maintain quality in your docs.”
   • [claimed-docs] “Bi-directional sync creates a two-way connection between your ReadMe project and a GitHub or GitLab repository.”
   • [claimed-docs] “The GitHub AI Writer keeps your documentation in sync with your codebase by watching your pull requests and proposing updates when code chan…”

   proof ↗⚑ flag

Review

1. technical writerTeammates propose changes that go through review — comments, approvals, and a merge step — before they publish

   weight 2 · round to GitBook
   GitBook✓fullclaimed8/10

   GitBook's 'Change requests' feature (gitbook-docs-29) provides a git-like PR workflow for docs with review, comments, approvals, and merge before publishing, and GitBook Agent can review change requests (gitbook-docs-18). missing for 10: independent/hands-on community corroboration specifically of the review-approve-merge workflow (community evidence pack only covers older GitBook versions and unrelated issues).

   • [claimed-docs] “Change requests”
   • [claimed-docs] “Review change requests with GitBook Agent”
   • [claimed-docs] “Invite your team to collaborate”
   • [claimed-docs] “GitBook’s AI-native visual editor makes it easy to write, review, and publish technical content — with Markdown, real-time collaboration, ve…”

   proof ↗⚑ flag

   ReadMe~partialclaimed6/10

   ReadMe's Reviews feature explicitly supports pre-publish approval workflows — teammates can check changes for issues or get approval before they go live, and the branch-based model (Branch menu) implies a merge-into-main step. However, the evidence never explicitly mentions inline comments/discussion threads, only 'approval' and 'AI Linter' checks, and there's no dedicated documentation of the merge action itself. Missing for 10: explicit comment/discussion functionality within reviews, and clear documentation of the merge step that finalizes publishing.

   • [claimed-docs] “Reviews allow you to check your changes for issues with the AI Linter or get approval from a teammate.”
   • [claimed-docs] “Reviews are an optional, but highly recommended, feature to help maintain quality in your docs.”
   • [claimed-docs] “Bi-directional sync creates a two-way connection between your ReadMe project and a GitHub or GitLab repository.”
   • [claimed-docs] “You can export the files in your docs or as a PDF from the Branch menu.”

   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 ReadMe
   GitBook~partialcommunity4/10

   GitBook advertises 'Site customization', 'Advanced branding options', and a 'block-based visual editor & custom blocks' plus custom domain support, showing some theme/branding controls (gitbook-docs-3, -11, -30, -47). However, none of the evidence explicitly confirms custom CSS/JS injection or embedding of fully custom React/UI components, and a community reviewer explicitly called landing-page customization 'limited' (gitbook-comm-3), directly cutting against a full brand-matching claim. missing for 10: explicit docs on custom CSS/JS support, custom component/embed capability, and independent confirmation that deep branding (beyond logo/colors/domain) is achievable.

   • [claimed-docs] “Block-based visual editor & custom blocks”
   • [claimed-docs] “Advanced branding options”
   • [claimed-docs] “Site customization”
   • [claimed-docs] “You can customize the appearance of your published documentation, match the user interface to the language of your content, and more.”
   • [community] “'I'm using gitbook to write a book currently... its an excellent platform for writers. Most of the product is open-source... Version control…”

   proof ↗⚑ flag

   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

Git workflow

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

   weight 3 · round drawn
   GitBook✓fullcommunity8/10

   GitBook documents GitHub/GitLab Sync as a core docs-as-code workflow, with version control, change requests, and branch/PR-driven publishing explicitly covered in official docs (gitbook-docs-4, gitbook-docs-24, gitbook-docs-27, gitbook-docs-29, gitbook-docs-46). Community evidence corroborates the platform's version-control and Git-based editing heritage, though some users note GitBook has shifted away from pure open-source/CLI git workflows toward its SaaS platform (gitbook-comm-13, gitbook-comm-17). missing for 10: independent hands-on confirmation that PR merges directly trigger publishing (vs. GitBook's own change-request review flow), and more detail on conflict handling between Git-sync and in-app edits.

   • [claimed-docs] “Sync with GitHub or GitLab”
   • [claimed-docs] “Version control”
   • [claimed-docs] “GitHub & GitLab Sync”
   • [claimed-docs] “Change requests”
   • [claimed-docs] “GitBook’s AI-native visual editor makes it easy to write, review, and publish technical content — with Markdown, real-time collaboration, ve…”
   • [community] “'Gitbook was a great project, but they really moved everything to their SaaS with artificial barriers to just using the software... such a n…”
   • [community] “GitBook README cited as reason for community fork: 'As the efforts of the GitBook team are focused on the GitBook.com platform, the CLI is n…”

   proof ↗⚑ flag

   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

2. developerEvery docs pull request gets a shareable preview deployment before it merges

   weight 2 · round to GitBook
   GitBook✓fullclaimed7/10

   GitBook explicitly lists 'Preview deployments' as a shipped feature alongside GitHub/GitLab sync and a change-request workflow for reviewing docs changes before they go live, matching the PR-preview-before-merge story for docs-as-code teams. Missing for 10: independent/hands-on confirmation that previews are auto-generated per PR with a shareable link, and more detail on how previews tie into the GitHub PR UI itself.

   • [claimed-docs] “Preview deployments”
   • [claimed-docs] “Sync with GitHub or GitLab”
   • [claimed-docs] “GitHub & GitLab Sync”
   • [claimed-docs] “Change requests”

   proof ↗⚑ flag

   ReadMe—none0/10

   No evidence describes per-PR shareable preview deployments of docs; ReadMe's docs-as-code features cover bi-directional sync, Reviews (AI Linter/teammate approval), and branch-based exports, but nothing indicates an automatic preview URL generated for each pull request before merge.

   ⚑ flag

Quality gates

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

   weight 2 · round drawn
   GitBook—none0/10

   No evidence of CI-integrated link/config validation (e.g., a check that runs in pull requests or build pipelines to catch broken links or invalid config before publish). GitBook's docs-as-code features cover Git sync, change requests, and preview deployments, but nothing describes automated CI validation for links/config prior to publishing.

   ⚑ flag

   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

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round drawn
   GitBook~partialprobed6/10

   GitBook exposes a documented REST API, a CLI, and an MCP server that let agents create/configure sites, open change requests, draft/edit content, and restructure docs (gitbook-docs-28,33,34,36), suggesting broad programmatic coverage of core UI actions. However, there's no explicit claim or evidence of full feature parity between API and UI, and the OpenAPI spec/full API surface isn't independently discoverable (gitbook-probe-3 shows 404s on all candidate spec paths). Missing for 10: an explicit parity statement, a complete public OpenAPI reference, and independent/hands-on confirmation that all UI actions (e.g. branding, analytics config, redirects) are API-accessible.

   • [claimed-docs] “GitBook CLI”
   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”
   • [claimed-docs] “list organizations, inspect spaces and pages, ask questions against your docs, and build and publish integrations — all without leaving the …”
   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gitbook.com/openapi.json, https://gitbook.com/swagger.json, https://gitbook.com/api/openapi.…”

   proof ↗⚑ flag

   ReadMe~partialprobed6/10

   ReadMe documents a full ReadMe API for programmatic control (readme-docs-87) plus an official CLI (rdme, readme-probe-3) and bi-directional GitHub/GitLab sync (readme-docs-26/46), suggesting most content, versioning, and docs management actions can be done via API/CLI/Git instead of the UI. However, the evidence doesn't confirm parity for every UI feature (e.g., Reviews approval workflows, Linter/Docs Audit runs, custom CSS/domain setup, Analytics/metrics views) being fully scriptable via the API, and no independent confirmation of full UI/API parity exists. missing for 10: explicit API/CLI equivalents for Reviews, Linter/Docs Audit, Analytics dashboards, and custom domain/CSS configuration, plus independent verification of full parity.

   • [claimed-docs] “Control your docs programmatically with the ReadMe API”
   • [probe] “official CLI documented at https://github.com/readmeio/rdme”
   • [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] “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”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   GitBook~partialcommunity5/10

   GitBook supports two-way Git Sync with GitHub/GitLab, storing content as Markdown with version control, which gives a real open-format export/exit path (gitbook-docs-27, gitbook-docs-24, gitbook-docs-46). However, there's no documented full-data export (analytics, users, integrations) and community feedback explicitly criticizes GitBook for moving away from open-source/self-hosted use and locking features behind its SaaS ('non open source behavior to only support their monthly service', 'abandoned open source spirit') (gitbook-comm-13, gitbook-comm-15). Missing for 10: a documented one-click full-account export, confirmation that all site/analytics/config data (not just page content) is portable, and resolution of community concerns about SaaS lock-in.

   • [claimed-docs] “GitHub & GitLab Sync”
   • [claimed-docs] “Version control”
   • [claimed-docs] “GitBook’s AI-native visual editor makes it easy to write, review, and publish technical content — with Markdown, real-time collaboration, ve…”
   • [community] “'Gitbook was a great project, but they really moved everything to their SaaS with artificial barriers to just using the software... such a n…”
   • [community] “'This is much needed as GitBook moved away from Book publishing and abandoned open source spirit.'”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   GitBook—none0/10

   No first-party evidence that GitBook publishes its source under an open license; recent community reports explicitly state GitBook moved away from open source and no longer actively develops its once-open CLI, confirming the product is closed-source SaaS today.

   • [community] “'Gitbook was a great project, but they really moved everything to their SaaS with artificial barriers to just using the software... such a n…”
   • [community] “'This is much needed as GitBook moved away from Book publishing and abandoned open source spirit.'”
   • [community] “GitBook README cited as reason for community fork: 'As the efforts of the GitBook team are focused on the GitBook.com platform, the CLI is n…”

   proof ↗⚑ flag

   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

4. ai-native userSelf-host the core product

   weight 3 · round drawn
   GitBook—none0/10

   GitBook is documented and confirmed by community evidence as a SaaS-only platform; multiple users explicitly note GitBook 'moved everything to their SaaS with artificial barriers to just using the software' and abandoned its open-source spirit, with the CLI 'no longer under active development.' No vendor documentation anywhere offers a self-hosted deployment option for the core product.

   • [community] “'Gitbook was a great project, but they really moved everything to their SaaS with artificial barriers to just using the software... such a n…”
   • [community] “'This is much needed as GitBook moved away from Book publishing and abandoned open source spirit.'”
   • [community] “GitBook README cited as reason for community fork: 'As the efforts of the GitBook team are focused on the GitBook.com platform, the CLI is n…”

   proof ↗⚑ flag

   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

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   GitBook—none0/10

   No evidence anywhere in the pack mentions data residency, region selection, or geographic storage controls for GitBook content; the pricing/feature list covers editing, sync, and AI features but nothing about regional data storage choices.

   ⚑ flag

   ReadMe—none0/10

   No evidence in the pack addresses data residency, regional storage selection, or data location controls for ReadMe; the docs cover editing, MCP, analytics, and customization but never data-residency options.

   ⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round drawn
   GitBook—none0/10

   No evidence in the pack addresses opting out of AI training data usage, data privacy controls for model training, or any privacy policy statements about training exclusion; GitBook's AI features focus on LLM-readiness and search rather than data usage controls. missing for 10: any privacy policy or settings documentation on opting out of AI training, contractual/DPA language about training data use, or third-party confirmation of such a control.

   ⚑ flag

   ReadMe—none0/10

   No evidence in the pack addresses AI training data opt-out or any data-privacy controls related to AI model training; ReadMe's docs cover documentation/AI-assistant features but not this privacy posture.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round drawn
   GitBook—none0/10

   No evidence in the pack discusses data retention policies, data deletion controls, export/purge tooling, or privacy/compliance settings for AI-native users; the docs focus on content authoring, MCP/AI assistant features, and publishing, not data governance.

   ⚑ flag

   ReadMe—none0/10

   The evidence pack covers documentation authoring, MCP server setup, AI writing tools, and content export/versioning, but nothing addresses data retention policies or user-controlled deletion of stored data (e.g., MCP call logs, Ask AI query history, or account data). Analytics features like MCP Metrics explicitly record every AI tool call, but no docs describe retention windows or deletion controls for that data.

   • [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”
   • [claimed-docs] “Export your docs using our built-in features, tooling, and our API.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   GitBook—none0/10

   No evidence in the pack addresses telemetry, analytics opt-out, or usage tracking controls for AI-native users; the closest items (Analytics & user feedback, AI insights) describe collecting data, not opting out of it.

   ⚑ flag

   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

Access control

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

   weight 1 · round to GitBook
   GitBook~partialclaimed6/10

   GitBook's official docs include a dedicated 'Authenticated access' page under Publish > Site Audience, directly matching the gating-content-behind-auth use case, but the evidence pack gives only the page title with no detail on which auth mechanisms (password vs JWT vs SSO) are actually supported or how they're configured, and there's no independent/community corroboration of this specific feature working in practice. Missing for 10: documented specifics on password/JWT/SSO configuration options, plan-tier restrictions, and independent verification that authenticated access works as described.

   • [claimed-docs] “Authenticated access”

   proof ↗⚑ flag

   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

Domains

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

   weight 2 · round drawn
   GitBook✓fullclaimed8/10

   GitBook explicitly documents custom domain support ('You can customize this by setting a custom domain, meaning your audience can access your documentation on a chosen domain') and lists 'Use a custom domain' as a pricing feature. This directly satisfies the core ask of serving docs on a custom domain. missing for 10: no explicit documentation or example of a /docs subpath deployment on the main site's domain, and no independent/hands-on confirmation of custom domain setup beyond vendor docs.

   • [claimed-docs] “Use a custom domain”
   • [claimed-docs] “You can customize this by setting a custom domain, meaning your audience can access your documentation on a chosen domain.”

   proof ↗⚑ flag

   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

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 ReadMe
   GitBook—none0/10

   GitBook offers Git sync of markdown source content but no documented feature for exporting the full rendered site (theme, navigation, assets) as a static bundle for self-hosting elsewhere; probes for such export endpoints return 404. Community commentary explicitly describes lock-in concerns ('artificial barriers to just using the software... non open source behavior to only support their monthly service', 'abandoned open source spirit') and the CLI being deprecated, reinforcing that no portable static-export path exists.

   • [claimed-docs] “GitHub & GitLab Sync”
   • [claimed-docs] “GitBook CLI”
   • [community] “'Gitbook was a great project, but they really moved everything to their SaaS with artificial barriers to just using the software... such a n…”
   • [community] “'This is much needed as GitBook moved away from Book publishing and abandoned open source spirit.'”
   • [community] “GitBook README cited as reason for community fork: 'As the efforts of the GitBook team are focused on the GitBook.com platform, the CLI is n…”
   • [probe] “PROBE docs-md: HTTP 404 at https://gitbook.com/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gitbook.com/openapi.json, https://gitbook.com/swagger.json, https://gitbook.com/api/openapi.…”

   proof ↗⚑ flag

   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

Search

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

   weight 3 · round to GitBook
   GitBook~partialcommunity6/10

   GitBook documents a built-in 'AI search' feature and a dedicated 'Searching internal content' doc, and independent community feedback praises GitBook's search as 'fast & accurate' out of the box. However, no evidence explicitly confirms typo-tolerance or details on relevance-ranking algorithms, so the specific claims in the story are only partially substantiated. Missing for 10: explicit documentation of typo-tolerant/fuzzy matching, technical detail on relevance ranking, and independent hands-on testing of search quality across a full site.

   • [claimed-docs] “AI search”
   • [claimed-docs] “Searching internal content”
   • [community] “'GoCD moved its user & developer docs to GitBook... and its been great so far! The best feature by far is fast & accurate search.'”

   proof ↗⚑ flag

   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

Localization

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

   weight 1 · round to GitBook
   GitBook~partialcommunity6/10

   GitBook docs describe auto-translation features to keep content updated across languages with minimal effort, and site customization docs note the UI can match the language of the content (implying localized navigation elements). However, there's no explicit first-party documentation detailing translated navigation menus/labels specifically, and the only independent corroboration of multi-language support is from a much older version of the product (pre-SaaS book publishing era). Missing for 10: explicit documentation of translated navigation trees/menus, current independent/hands-on verification of multi-language site publishing.

   • [claimed-docs] “Auto translations make it easy to keep your documentation up-to-date in multiple languages, with minimal manual effort.”
   • [claimed-docs] “You can customize the appearance of your published documentation, match the user interface to the language of your content, and more.”
   • [community] “GitBook co-founder: 'We have a lot of non-english books actually... over a thousand in chinese alone. In the upcoming 2.0.0 release, we've f…”

   proof ↗⚑ flag

   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

Versioning

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

   weight 3 · round to GitBook
   GitBook~partialclaimed6/10

   GitBook documents a 'Content variants' feature explicitly for maintaining multiple versions of a site (e.g., per product/API version) and separate 'Version control' docs-as-code capability, which together support the story of versioned docs with reader-facing switching. However, all evidence is vendor documentation with no independent hands-on confirmation of the version-switcher UI/UX or how seamless the reader experience is. Missing for 10: independent/community verification of the version switcher working well in practice, and more detail on how readers navigate between variants.

   • [claimed-docs] “Content variants”
   • [claimed-docs] “Version control”
   • [claimed-docs] “each site is made up of sections — the pages you write and edit live inside a section. Related sections can be organized into groups to shap…”

   proof ↗⚑ flag

   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