Skip to main content

Machine-readable specs

Everything a tool needs to use Prism correctly is available as structured data, not just prose.

Component specs​

/ai/components.json describes all 102 components. It is generated from the component type definitions, so it never drifts from the code. Each entry carries:

{
  "name": "Button",
  "category": "core",
  "categoryLabel": "Core",
  "description": "The primary action control. Use exactly one accent button per view…",
  "props": [
    { "name": "variant", "type": "\"accent\" | \"neutral\" | \"quiet\" | \"outline\" | \"negative\" | \"positive\" | \"notice\"", "optional": true, "desc": "Visual emphasis…" },
    { "name": "size", "type": "\"sm\" | \"md\" | \"lg\" | \"xl\"", "optional": true, "desc": "Control height…" }
  ],
  "source": "components/core/Button.jsx"
}

The top of the file records the namespace and that it was generated from the system manifest, so a tool can read the correct window.<namespace> rather than guess.

llms.txt​

/llms.txt is the human- and model-readable index: the import, the theming attributes, the rules, and every component with a one-line description and link. Start here, then pull specific specs from the JSON when a task needs exact props.

Regenerating​

Both files are build artifacts. The generator reads the design system's manifest and type definitions and emits components.json; llms.txt is built from the same data. Run the docs meta script after a system change so the specs track the source. Because they derive from the manifest, the specs are only ever as stale as the last build — there is no separate copy to maintain by hand.

Using the specs​

  • Validate generated code — check that prop names and enum values used actually exist in the spec.
  • Drive a picker or palette — the category grouping and descriptions are enough to build a "choose a component" UI.
  • Feed an agent — give it llms.txt for breadth and the relevant components.json entries for depth.