For AI
Feeding this to a model
Half of what you need to use a component is written as a comment next to a prop. All of it is generated into files a model can read, so it never has to guess.
What's available
/llms.txt- The index — one line per component page, under 80 lines. Start here: read it whole, then fetch only the pages you need.
/docs/components/button.md- Any component page as Markdown — add .md to its URL. When to use it and when not, runnable examples, then every prop, its type, its default and its classes parts. These same files ship in the package, at node_modules/omaris/docs/, for an agent that cannot fetch a URL.
/docs/choosing-a-component.md- The guides as Markdown too. This one is the decision tables — which of the look-alikes to use — and /docs/building-a-screen.md, /docs/look.md, /docs/forms.md, /docs/feedback.md and /docs/footguns.md are the rest of the "how to build" set.
/llms-full.txt- The complete API in one flat file, plus every guide on this site. About 3,000 lines — worth it when the model has to make design decisions rather than just call things correctly.
/docs/api.json- The same data structured, for tooling that would rather parse than read.
A ready-made brief
Drop this into a system prompt, a CLAUDE.md, a Cursor rule
file, or wherever your tool keeps standing instructions. It is short on purpose — the API itself
belongs in the generated pages, not in a prompt that gets stale.
You are writing SvelteKit code that uses the omaris component library.Rules:- Import from 'omaris'. Charts are 'omaris/chart', maps are 'omaris/map'.- Never guess a prop name or a classes part name. Read llms.txt, then the page it links to for each component you use. Installed, those pages are node_modules/omaris/docs/ — index.md first.- Every page opens with "Use it for" and "Not for". Read them before choosing a component; a "Not for" line names the one to use instead. When two look alike (Select/Combobox, Switch/Checkbox, Dialog/Sheet), the guide at /docs/choosing-a-component settles it, and /docs/footguns lists the mistakes that compile.- Style with Tailwind utilities and omaris design tokens (bg-primary, text-muted-foreground, rounded-shape-lg, shadow-2, ease-emphasized). Never hex colours, never arbitrary px values.- `class` styles a component's root and is merged last, so it always wins.- Multi-part components take `classes`, one Tailwind string per named part: <Input class="w-96" classes={{ control: 'font-mono' }} />- tailwind-merge only resolves conflicts inside one group, so aspect-video does not cancel a height. Where a component ships one it gives you a prop instead — see Carousel.height.- Wrap the app once in <OmarisProvider>. It provides toast, dialog.confirm/alert/prompt and the theme store.- omaris bundles no icons. Hand a component an <svg> and it sets the size and the colour. Lucide matches its built-in glyphs.- Svelte 5 runes only: $state, $derived, $props, $effect. Or let the CLI do it
init wires omaris into a SvelteKit app and writes an AGENTS.md alongside it, so an agent working in the project reads
the conventions before it writes a line.
bunx omaris init It points at node_modules/omaris/docs/ rather than copying the
API in, so the reference updates itself when the package does — and it reads off disk, which most
coding agents can do and fetching a URL is not.
Why not just read the types?
Because the types do not say enough. height?: number | string is true and useless; what a model needs to know is that the height is a prop rather than a class precisely
so a consumer's aspect-video can replace it. That sentence exists in the source
as a comment, and these files are how it gets out.