Publish an llms.txt index for openfeature.dev

Proposal

Publish an llms.txt index at https://openfeature.dev/llms.txt — a short Markdown file listing the site's key pages (docs sections, SDK references, provider and hook catalogue, spec and OFREP links) with a one-line description each, so an LLM or coding agent can find the right page in one fetch instead of crawling navigation HTML.

Optional second step: serve a raw Markdown version of each page (e.g. /docs/reference/concepts.md), which is the part agents actually benefit from once they've picked a page.

Why this fits OpenFeature

Our content is spread across surfaces — docs here, SDK references pulled in from the org's SDK repos at build time, ~50 providers generated from src/datasets/providers, plus the spec, OFREP and the CLI elsewhere. An agent asked "how do I write a provider in Python" has to guess URLs or crawl the sidebar today. We also already ship an OpenFeature MCP Server, so agent-facing surfaces aren't new territory for the project — this is the cheap, static counterpart to it.

What other CNCF projects actually do

Adoption is real but early and uneven.

Have it:

• OpenTelemetry — opentelemetry.io/llms.txt, plus text/markdown output for every page (/docs/concepts/index.md). Tracked in open-telemetry/opentelemetry.io#9449 and generated upstream in Docsy (PR #9614).
• Cilium — cilium.io/llms.txt plus a ~2 MB llms-full.txt.
• Dapr — dapr.io/llms.txt, a small hand-curated file (~1 KB).
• Open Policy Agent — openpolicyagent.org/llms.txt.

Checked and returning 404: Kubernetes, Istio, Linkerd, Argo, Flux, Knative, KEDA, Helm, containerd, etcd, Falco, Tekton, cert-manager, Harbor, Kubeflow, Crossplane, Kyverno, NATS, Backstage, Jaeger, Envoy.

So it isn't a de facto CNCF standard, but the foundation's largest docs site has invested in it fairly seriously.

Worth being honest about

Search engines don't consume this — Google has stated no Search system reads llms.txt, and no major model provider has committed to fetching it in production. The value is narrower: agents and IDE assistants that fetch URLs at request time, and people pasting openfeature.dev/llms.txt into a prompt as a starting point. It's a low-cost bet, not a traffic lever, and I think it's worth deciding on that basis.

Implementation notes

Docusaurus has no built-in support as of 3.10. Two options:

1. A community plugin (@signalwire/docusaurus-plugin-llms-txt, docusaurus-plugin-llms, @writechoice/docusaurus-plugin-llms-txt); some also emit per-page .md and an llms-full.txt.
2. A small build script that walks the sidebar and writes static/llms.txt, avoiding another dependency.

Open questions: whether the index should include remote SDK content and blog posts, and whether llms-full.txt is worth it given how much of our content originates in other repos.

Happy to open a PR if there's interest.

AI-assisted — Tool: Claude Code; model: anthropic/claude-opus-5; version: 2.1.236.

Start by reading the Docusaurus 3.10 build setup and sidebar structure, then inspect how content from src/datasets/providers is generated. Compare a build script that writes static/llms.txt with the listed plugin options. Done means the site serves an index at /llms.txt with the agreed page categories and one-line descriptions; inclusion of remote SDKs, blog posts, and optional Markdown pages still needs a decision.