Skip to content
omaris

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.