Machine-readable docs

Everything on this site has a machine-readable counterpart at a stable URL. An agent working on a Jx project can fetch the documentation corpus, the search index, or the schemas themselves without scraping HTML. None of it is a separate artifact that drifts, because all of it is regenerated from the same sources on every build.

The documentation corpus

llms.txt

https://jxsuite.com/llms.txt

A plain-text index in the llms.txt convention : a one-paragraph summary of the project, then one ## heading per documentation section, then one line per page in sidebar order:

# Jx Suite

> Jx Suite is a visual site builder (Jx Studio), a JSON-native component format, and a compiler that prerenders every page — working on plain files you own and publish with git. …

## Start here

- [Start here](https://jxsuite.com/docs/start/): What Jx Suite is, how to install Jx Studio, and where to go first …
- [Install Jx Studio](https://jxsuite.com/docs/start/install/): Download the Jx Studio desktop app …
- [Your first project](https://jxsuite.com/docs/start/first-project/): …

Each section's landing page comes first, then the rest of that section's own pages, then each of its groups in turn, exactly as the sidebar orders them.

It carries no page bodies, roughly 27 KB against full-docs.json 's ~680 KB, which makes it the cheap first fetch: point an agent at it, let it read the titles and descriptions, and let it pull only the pages it needs.

A Markdown copy of every page

Beside each page's HTML the build writes a Markdown copy of it. https://jxsuite.com/templates/ has https://jxsuite.com/templates/index.md ; with trailingSlash: "never" the copy of /about is /about.md . The path follows the HTML file, and for a URL without a file name it is the index.md the llms.txt proposal names.

You do not have to guess it. Every page that has a copy says so in its <head> :

<link href="/templates/index.md" rel="alternate" type="text/markdown" />

That rel="alternate" link is the discovery mechanism the llms.txt proposal recommends. An agent that fetched the HTML follows it, and a crawler that understands alternates finds the copy on its own. The link names only a copy the build wrote, and the 404 page has none. To point a page at a different Markdown file, write the same <link> in the page's $head : yours wins.

full-docs.json

https://jxsuite.com/docs/full-docs.json

The same corpus in the same order, with the prose included. A JSON array of objects, one per page:

This is the fetch for an agent that wants the whole thing at once: one request, no crawling, and the markdown field is the same text a contributor edits in the repository.

search-index.json

https://jxsuite.com/search-index.json

The index that powers the site's own search box, emitted by the search extension during the build. A documents array wrapped in an envelope of version , engine ( "minisearch" ), the indexed fields , and per-field boost weights. Each document is one page or one heading-level section within a page, carrying id , collection , slug , url , title , description , heading , and text . The two granularities partition the entry rather than overlapping: a page document ( heading: "" ) carries only the text before its first heading, and the section documents carry the rest. Reassemble a page by concatenating its page document with every document whose id starts with <page-id># . A collection that keeps one directory per language adds locale , and then the id carries the tag too ( docs:fr-CA:start/install ), because two translations share an entry id.

The index is not the whole corpus. A page whose frontmatter says search: false contributes no documents, and the three reference pages derived from the specs (the spec changelog, implementation status and the standards table) say it; the generated catalogues stay indexed. For those, and for anything you want verbatim, read full-docs.json , which carries every page in nav order regardless.

Reach for it when you want lookup rather than reading: it is section-granular, so a query lands on a heading instead of a whole page.

The schemas

The other machine-readable surface is the format itself. The Jx schemas are plain JSON Schema 2020-12 documents, served at the URLs that are also their canonical $id s:

Any compliant 2020-12 validator can consume them directly. There is no Jx-specific validation runtime. They are published from packages/schema through the copy map in the site's project.json , so the served documents are byte-for-byte the schemas the toolchain uses.

For work inside a project, prefer the local composed copies. jx schema writes project.schema.json and document.schema.json into the project root, merging these core schemas with the fragments each enabled extension ships and inlining every referenced resource. Those files resolve offline (no node_modules , no network, no editor configuration), and they are what jx validate checks against. The hosted URLs above are the right reference when you are outside a project or want the core format without any extension's additions. The hosted $paths union accepts any extension source shape it cannot see, where your project's generated copy checks the exact set your extensions provide. See Schema composition .

Related

• Working with agents : the workflow these endpoints support

• Authoring rules for agents : the briefing to hand an agent alongside them

• CLI commands : jx schema and jx validate

• Site search : how the search index is configured and emitted

• Contributing to these docs : where the corpus comes from