Building with an AI coding assistant — GitHub Copilot, Cursor, Claude, ChatGPT, or any agentic workflow? This documentation is designed to be consumed by machines as well as humans. Every page is published in a clean, machine-readable form so an agent can ground its answers in the actual current API instead of guessing from stale training data.
Coding agents are only as good as the context they’re given. Left to their training data alone, an LLM will happily invent plausible-but-wrong API: a method that never existed, a prop from a different grid library, an import path from an old major version. The fix is retrieval — handing the agent the authoritative, current docs at generation time.
Pointing your assistant at the files below gives you:
Correct imports and API surface — side-effect imports, feature vs. plugin config, event names, and type names come straight from the source, not a hallucination.
Fewer iterations — the agent gets the critical rules (height is required, editing is opt-in, plugin load order) up front, so generated code runs the first time.
Framework-portable answers — the same gridConfig pattern is documented for vanilla JS, React, Angular, and Vue, so the agent recommends the portable shape by default.
Up-to-date guidance — because these files are regenerated on every docs build, your assistant reads today’s API, not last year’s.
All three formats follow the llms.txt standard and are served from the site root.
llms.txtA concise, curated index: a one-paragraph overview, the agent steering rules, and links to every documentation page (each pointing at its Markdown companion). Small enough to fit a modest context window.
Per-page MarkdownAppend .md to any docs URL — e.g. /grid/getting-started.md — to fetch a lean, self-contained Markdown rendering of just that page, with its demo code inlined. There's also a 'View as Markdown' link at the bottom of every page.
The full corpus and its sizes
llms-full.txt is the full corpus: every prose guide, plugin, and adapter page concatenated with demo code inlined, for one-shot ingestion. The per-symbol API reference is linked, not inlined. A per-framework variant drops the other stacks’ examples to trim size.
The sizes below are computed at build time by the same generators that emit the files, so they never drift from reality. Don’t be put off by the megabyte figures — most assistants retrieve only the sections a task needs rather than loading a file whole; size mainly bites if you paste verbatim, so when in doubt prefer llms.txt plus on-demand .md fetches.
Reach for the smallest file that answers the question — precision beats volume. More context is not always better: an oversized prompt buries the relevant lines and can push the model past its usable window.
Your assistant can…
Use this
Why
Fetch URLs on demand (Copilot, Cursor, Claude + MCP/tools)
llms.txt first → fetch .md pages
Loads a small index, then pulls only the pages the task needs. Highest signal-to-noise.
Only accept one pasted/loaded blob (no fetching)
llms-full.txt
One-shot ingestion of the whole corpus when on-demand retrieval isn’t available.
One blob, but you work in one framework
llms-full-{react,vue,angular,vanilla}.txt
Same corpus, scoped to your stack — other frameworks’ examples and adapter pages are dropped, cutting size substantially.
Work on one specific page/feature
The page’s .md companion
Self-contained — the single most relevant document, nothing else.
Recommended default: llms.txt. It is the curated map (overview, the agent steering rules, and a link to every page’s .md companion). A capable agent reads it, then fetches just the handful of pages a task requires — e.g. the Editing and Selection plugin pages for an editable grid — instead of ingesting all ~25 plugins. Point at llms-full.txt only when your tool can’t fetch on demand and you want everything in a single load. If your tool can’t fetch but you only target one framework, prefer the scoped llms-full-{react,vue,angular,vanilla}.txt variant — it is the same corpus with the irrelevant framework variants removed.
These files are generated at build time, never hand-written, so they cannot drift from the documentation you’re reading:
Source of truth — they are built from the same MDX documentation pages, the live demo component sources, and the JSDoc-derived TypeDoc API that produce this website. When the docs change, the AI files change in the same build.
Demo code is the real code — runnable examples are inlined directly from the demo sources the live site executes, so an agent learns from code that actually works, with zero copy-paste drift.
Honest curation — a few non-implementation pages (this one and the changelogs) are intentionally kept out of llms-full.txt so the corpus stays focused on building with the grid. They remain linked in llms.txt for discoverability.
Steering rules first — llms.txt and the introduction lead with the critical rules and anti-patterns an agent must respect before writing a single line, so the most consequential constraints are read first.
Pick the right entry point. Prefer llms.txt when your assistant can fetch pages on demand (it then pulls only the .md pages a task needs); fall back to llms-full.txt for one-shot loads when on-demand fetching isn’t available. See Which one should you use? above.
Share .md links, not HTML. When you reference a specific page in a prompt, append .md to the URL. It hands the agent the page’s actual content directly, so it spends no compute stripping HTML to reach the words that matter.
Configure project rules. For repeated use, drop a pointer to /llms.txt (or /llms-full.txt for fetch-less tools) into your tool’s project rules file (e.g. a Cursor rule or a Copilot instructions file) so every session starts grounded.
If your assistant cannot fetch the full corpus reliably, give it a prompt like this instead of pasting the whole file:
Download https://toolboxjs.com/llms-full-angular.txt to a local file, search it for the exact topic or symbols I care about, and return only the smallest relevant slices. Prefer a local search first, then extract just the matching regions. Do not paste the entire corpus back to me.
You can then follow up with a concrete topic, such as a renderer type, a directive name, or a plugin.
