opsml-ui

Name: opsml-ui
Author: demml

39stars3forks

How to install opsml-ui?

demml/opsml/opsml-ui

$npx -y skills add demml/opsml --skill opsml-ui

Installs into the current project.

Summary

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,

Files · 1

View on GitHub

SKILL.md

1	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`.
2
3	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.
4
5	Start by locating the feature boundary before editing:
6	- Read `references/working-map.md` to find the right feature area.
7
8	Then load only the topic references needed for the task:
9	- BFF/data-loading, server routes, load functions, invalidation, auth/session boundaries: read `references/sveltekit-architecture.md` and, for legacy route notes, `references/architecture.md`.
10	- 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`.
11	- Large tables, traces, files, charts, pagination, virtualization, search/filtering, and payload budgets: read `references/data-performance.md`.
12	- Developer workflow UX, registries, observability, trace inspection, filters, drilldowns, empty/loading/error states: read `references/developer-ux.md`.
13	- 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`.
14	- Vitest, Svelte Testing Library, pure utility tests, build/manual checks, accessibility and performance checks: read `references/testing-verification.md`.
15
16	Follow these repo-specific rules:
17	- Keep data fetching server-side by default. Prefer `+page.server.ts`, `+layout.server.ts`, and server helpers under `src/lib/server/`.
18	- 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.
19	- Reuse route constants from `src/lib/components/api/routes.ts` before introducing new path strings.
20	- Preserve OpsML theme tokens and brutalist interaction patterns. Do not introduce arbitrary hex colors, soft shadows, glassmorphism, or generic grayscale borders.
21	- Use `primary-`, `secondary-`, and `tertiary-` for neutral UI categories. Reserve `success-`, `warning-`, and `error-` for actual state, feedback, risk, or failure semantics.
22	- Keep types close to the feature unless they are clearly shared by multiple areas.
23	- Preserve the current auth flow in `src/hooks.server.ts` and `src/lib/server/auth/validateToken.ts`.
24	- Use `$derived(expression)` or `$derived.by(() => expression)` for derived state and keep derived values side-effect free.
25	- Use `$effect` mainly for external side effects such as browser APIs, observers, Chart.js, CodeMirror, imperative subscriptions, and request side effects.
26	- Prefer server-backed pagination, filtering, sorting, and aggregation for large remote datasets.
27	- Use `VirtualScroller.svelte` or `@tanstack/svelte-virtual` for large scrollable views.
28	- Do not add new UI libraries unless the user explicitly asks.
29
30	When making changes, inspect in this order:
31	1. The route entrypoint (`+page.svelte`, `+page.ts`, `+page.server.ts`, `+layout.*`)
32	2. The feature component under `src/lib/components/...`
33	3. The server helper under `src/lib/server/...`
34	4. Shared route constants, schema, or local feature types
35
36	Use these verification commands from `crates/opsml_server/opsml_ui` when relevant:
37	- `pnpm build`
38	- `pnpm exec svelte-check`
39	- `pnpm exec eslint .`
40
41	Prefer small, local edits that match existing patterns over broad refactors unless the task explicitly requires architectural cleanup.

People who liked this also viewed

6 picks

Type

opsml-ui

39stars3forks

View on GitHub

How to install opsml-ui?

demml/opsml/opsml-ui

$npx -y skills add demml/opsml --skill opsml-ui

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	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`.
2
3	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.
4
5	Start by locating the feature boundary before editing:
6	- Read `references/working-map.md` to find the right feature area.
7
8	Then load only the topic references needed for the task:
9	- BFF/data-loading, server routes, load functions, invalidation, auth/session boundaries: read `references/sveltekit-architecture.md` and, for legacy route notes, `references/architecture.md`.
10	- 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`.
11	- Large tables, traces, files, charts, pagination, virtualization, search/filtering, and payload budgets: read `references/data-performance.md`.
12	- Developer workflow UX, registries, observability, trace inspection, filters, drilldowns, empty/loading/error states: read `references/developer-ux.md`.
13	- 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`.
14	- Vitest, Svelte Testing Library, pure utility tests, build/manual checks, accessibility and performance checks: read `references/testing-verification.md`.
15
16	Follow these repo-specific rules:
17	- Keep data fetching server-side by default. Prefer `+page.server.ts`, `+layout.server.ts`, and server helpers under `src/lib/server/`.
18	- 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.
19	- Reuse route constants from `src/lib/components/api/routes.ts` before introducing new path strings.
20	- Preserve OpsML theme tokens and brutalist interaction patterns. Do not introduce arbitrary hex colors, soft shadows, glassmorphism, or generic grayscale borders.
21	- Use `primary-`, `secondary-`, and `tertiary-` for neutral UI categories. Reserve `success-`, `warning-`, and `error-` for actual state, feedback, risk, or failure semantics.
22	- Keep types close to the feature unless they are clearly shared by multiple areas.
23	- Preserve the current auth flow in `src/hooks.server.ts` and `src/lib/server/auth/validateToken.ts`.
24	- Use `$derived(expression)` or `$derived.by(() => expression)` for derived state and keep derived values side-effect free.
25	- Use `$effect` mainly for external side effects such as browser APIs, observers, Chart.js, CodeMirror, imperative subscriptions, and request side effects.
26	- Prefer server-backed pagination, filtering, sorting, and aggregation for large remote datasets.
27	- Use `VirtualScroller.svelte` or `@tanstack/svelte-virtual` for large scrollable views.
28	- Do not add new UI libraries unless the user explicitly asks.
29
30	When making changes, inspect in this order:
31	1. The route entrypoint (`+page.svelte`, `+page.ts`, `+page.server.ts`, `+layout.*`)
32	2. The feature component under `src/lib/components/...`
33	3. The server helper under `src/lib/server/...`
34	4. Shared route constants, schema, or local feature types
35
36	Use these verification commands from `crates/opsml_server/opsml_ui` when relevant:
37	- `pnpm build`
38	- `pnpm exec svelte-check`
39	- `pnpm exec eslint .`
40
41	Prefer small, local edits that match existing patterns over broad refactors unless the task explicitly requires architectural cleanup.

People who liked this also viewed

6 picks

Type