# Opsml UI

> Broad skill for building, editing, debugging, styling, and extending the OpsML UI in `crates/opsml_server/opsml_ui`. Use for Svelte 5 components, SvelteKit routes/layouts/load functions, internal `/routes/api` proxy endpoints, UI stores, Tailwind or Skeleton styling, card pages, Scouter dashboards, observability or trace views, agent or prompt interfaces, and general frontend bugfix or feature work inside the embedded OpsML frontend.

- Skill: `demml/opsml-ui` (Agent Skill)
- Install (CLI): `npx skillmds@latest add demml/opsml-ui`
- Raw SKILL.md: https://api.skillmd.com/api/skills/demml/opsml-ui/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: demml (https://skillmd.com/u/demml)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/demml/opsml-ui

---


Canonical skill for OpsML frontend work. The older `sveltekit-neobrutalism` skill is a legacy alias; use this skill as the source of truth for `crates/opsml_server/opsml_ui`.

Work inside the existing `opsml_ui` architecture and visual language rather than treating this as a generic Svelte app. OpsML is a dense developer tool, not a marketing site: build fast, scannable, task-oriented interfaces that expose operational details clearly.

Start by locating the feature boundary before editing:
- Read `references/working-map.md` to find the right feature area.

Then load only the topic references needed for the task:
- BFF/data-loading, server routes, load functions, invalidation, auth/session boundaries: read `references/sveltekit-architecture.md` and, for legacy route notes, `references/architecture.md`.
- Svelte component state, runes, snippets, effects, `.svelte.ts` modules, and legacy Svelte anti-patterns: read `references/svelte5-patterns.md` and, for shorter local patterns, `references/sveltekit-patterns.md`.
- Large tables, traces, files, charts, pagination, virtualization, search/filtering, and payload budgets: read `references/data-performance.md`.
- Developer workflow UX, registries, observability, trace inspection, filters, drilldowns, empty/loading/error states: read `references/developer-ux.md`.
- Tailwind v4, Skeleton, OpsML theme tokens, dark mode, icons, semantic color rules: read `references/theming.md` and, for short local rules, `references/design-system.md`.
- Vitest, Svelte Testing Library, pure utility tests, build/manual checks, accessibility and performance checks: read `references/testing-verification.md`.

Follow these repo-specific rules:
- Keep data fetching server-side by default. Prefer `+page.server.ts`, `+layout.server.ts`, and server helpers under `src/lib/server/`.
- Reuse the BFF shape already in the app. If a component needs backend access, prefer an internal SvelteKit `/routes/api/...` endpoint plus a server helper instead of calling the Rust backend directly from the browser.
- Reuse route constants from `src/lib/components/api/routes.ts` before introducing new path strings.
- Preserve OpsML theme tokens and brutalist interaction patterns. Do not introduce arbitrary hex colors, soft shadows, glassmorphism, or generic grayscale borders.
- Use `primary-*`, `secondary-*`, and `tertiary-*` for neutral UI categories. Reserve `success-*`, `warning-*`, and `error-*` for actual state, feedback, risk, or failure semantics.
- Keep types close to the feature unless they are clearly shared by multiple areas.
- Preserve the current auth flow in `src/hooks.server.ts` and `src/lib/server/auth/validateToken.ts`.
- Use `$derived(expression)` or `$derived.by(() => expression)` for derived state and keep derived values side-effect free.
- Use `$effect` mainly for external side effects such as browser APIs, observers, Chart.js, CodeMirror, imperative subscriptions, and request side effects.
- Prefer server-backed pagination, filtering, sorting, and aggregation for large remote datasets.
- Use `VirtualScroller.svelte` or `@tanstack/svelte-virtual` for large scrollable views.
- Do not add new UI libraries unless the user explicitly asks.

When making changes, inspect in this order:
1. The route entrypoint (`+page.svelte`, `+page.ts`, `+page.server.ts`, `+layout.*`)
2. The feature component under `src/lib/components/...`
3. The server helper under `src/lib/server/...`
4. Shared route constants, schema, or local feature types

Use these verification commands from `crates/opsml_server/opsml_ui` when relevant:
- `pnpm build`
- `pnpm exec svelte-check`
- `pnpm exec eslint .`

Prefer small, local edits that match existing patterns over broad refactors unless the task explicitly requires architectural cleanup.