Skip to content
cccskills
FreePublished on GitHub

svelte-frontend

Apply Windmill-specific patterns when building or changing Svelte UI in its frontend. Find and reuse existing components, follow brand and layout guidance, use the design system and Tailwind CSS, and verify changes in a browser with Playwright MCP.

OriginalShow the original description

Svelte coding guidelines for the Windmill frontend. MUST use when writing or modifying code in the frontend directory.

windmill-labs/windmill18,276 stars(GitHub 18,276 + cccskills 0)
Works withPlaywright

Run score Not tested

See how to install

Good for

  • Build a new screen with existing UI components
  • Update a Svelte form or interaction
  • Apply Windmill brand and layout guidance
  • Verify frontend changes in a browser

Files included (1)

  • SKILL.md6.0 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Windmill Svelte Patterns

Apply these Windmill-specific patterns when writing Svelte code in frontend/. For general Svelte 5 syntax (runes, snippets, event handling), use the Svelte MCP server.

Before writing any UI (MUST)

Do both of these before the first line of markup — not after, and not only when something looks unfamiliar.

1. Find the component that already exists. frontend/src/lib/components/common/index.ts is the design-system barrel — 28 lines, read it in full. It exports far more than the three documented below: Alert, Badge, Breadcrumb, Drawer/DrawerContent, Menu/MenuItem, Tabs/Tab/TabContent, Skeleton, FileInput, RadioCard, Section, Kbd, ActionRow, ClearableInput, CopyButton, SecondsInput, UndoRedo, Url.

The barrel is not the full picture either: common/ has 34 subdirectories and only 23 exports, so modal/, popup/, stepper/, tooltip/, checkbox/, table/, contextmenu/, confirmationModal/, calendarPicker/, fileUpload/, toggleButton-v2/ and more exist but must be imported by path. Selects, text inputs and melt-based primitives sit next to common/ in components/select/, components/text_input/, components/meltComponents/.

The tree holds 1,600+ components — grep frontend/src/lib/components for the thing you're about to build; it almost certainly exists. Building a new one is the last resort, not the first move.

2. Read the guideline for what you're building. frontend/brand-guidelines.md is the authority on how it should look and read. Don't load all 34k chars — jump to the section:

BuildingSection to read
Any new screen or component# Components (Core Rules, Quick Reference)
Buttons, CTAs## Buttons — hierarchy matters, only one Accent per view
Colors, surfaces, borders# Color system (Quick Reference, Do's and Don'ts)
Text, labels, headings# Typography — note ## Text Casing, sentence case throughout
Spacing, grids, page structure# Spacing & Layout; # Layout → ## Form for forms
Shadows, overlays, depth# Elevation
Icons# Iconography
Wording of any UI copy# Voice & Communication, # Tone of Voice

Get the line range with grep -n '^#' frontend/brand-guidelines.md, then read just that span.

Windmill UI Components (MUST use)

Always use Windmill's design-system components. Never use raw HTML elements. The three below are the ones you'll reach for most often — they are examples, not the catalog. For anything else, go back to the barrel and grep.

Buttons — <Button>

<script>
  import { Button } from '$lib/components/common'
  import { ChevronLeft } from 'lucide-svelte'
</script>

<Button variant="default" onclick={handleClick}>Label</Button>
<Button startIcon={{ icon: ChevronLeft }} iconOnly onclick={prev} />

Props: variant?: 'accent' | 'accent-secondary' | 'default' | 'subtle', unifiedSize?: '2xs' | 'xs' | 'sm' | 'md' | 'lg', startIcon?: { icon: SvelteComponent }, iconOnly?: boolean, disabled?: boolean

size on <Button> is banned — it, spacingSize and extendedSize are the legacy sizing system (xs3/xs2/xs/…, marked @deprecated in Button.svelte). Size every button with unifiedSize, the small ones included: 2xs and xs are h-5, sm is h-7, md is h-8, lg is h-10. Existing size="xs2" call sites are legacy, not a precedent to copy. Same for variant: contained/border/divider are deprecated — use the four listed above.

Text inputs — <TextInput>

<script>
  import { TextInput } from '$lib/components/common'
</script>

<TextInput bind:value={val} placeholder="Enter value" />

Props: value?: string | number (bindable), placeholder?: string, disabled?: boolean, error?: string | boolean, size?: 'sm' | 'md' | 'lg'

Selects — <Select>

<script>
  import Select from '$lib/components/select/Select.svelte'
</script>

<Select items={[{ label: 'Jan', value: 1 }]} bind:value={selected} />

Props: items?: Array<{ label?: string; value: any }>, value (bindable), placeholder?: string, clearable?: boolean, size?: 'sm' | 'md' | 'lg'

Icons — lucide-svelte

Never write inline SVGs. Import from lucide-svelte:

<script>
  import { ChevronLeft, X } from 'lucide-svelte'
</script>
<ChevronLeft size={16} />

Form Components

Form components (TextInput, Toggle, Select, etc.) should use the unified size system when placed together.

Styling

  • Use Tailwind CSS for all styling — no custom CSS
  • Use Windmill's theming classes for colors/surfaces (see frontend/brand-guidelines.md)
  • Read component props JSDoc before using them

Feature Telemetry

New user-facing UX is the main source of feature_usage counters — propose them in the plan, not as a separate question, and read docs/feature-telemetry.md first. logFeatureUsage() from $lib/utils/featureUsage is only half the change: the (feature, kind) pair must also be registered in the backend allowlist or every event is silently discarded. The disclosure copy in InstanceSettings.svelte stays at the category level; see the recipe's step 3.

Svelte MCP Server

Use the Svelte MCP tools when working on Svelte code:

  1. list-sections: Call first to discover available docs
  2. get-documentation: Fetch relevant sections based on use_cases
  3. svelte-autofixer: MUST use on all Svelte code before finalizing — keep calling until no issues
  4. playground-link: Only after user confirms and code was NOT written to project files

Verifying in the Browser

After changing Svelte code, use the Playwright MCP (mcp__playwright__*) to drive the running frontend and confirm the change works. See frontend/AGENTS.md → "Verifying Frontend Changes" for the full flow. Use playwright (headless) on devboxes; playwright-headed when a display is available.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

adding-a-trigger

FreeSummary

Plan the code changes needed to add a TriggerCrud-based trigger to Windmill. The checklist covers backend, database, API, CLI, frontend, capture, and validation work so the new trigger can be managed across the product.

  • Add a Kafka, GCP, or Azure style trigger to Windmill
  • Find all product areas affected by a new trigger kind
  • Review implementation and validation steps before a trigger PR
windmill-labs/windmill18.3KUpdated Oct 26, 2026

ai-chat

FreeSummary

Improve Windmill’s AI chat by reviewing its tools, prompts, result shapes, and context usage. The guidance helps place shared instructions where chat and CLI can use them, reduce repeated token costs, and compare behavior before and after changes with A/B evaluations.

  • Edit Windmill chat tools or system prompts
  • Reduce chat context window usage
  • Benchmark a chat behavior change
windmill-labs/windmill18.3KUpdated Oct 26, 2026

ai-evals

FreeSummary

Create and run black-box benchmarks for Windmill AI generation modes such as flows, apps, scripts, CLI, and global requests. Each case exercises the production path, checks hard requirements, and uses an LLM judge to assess user-facing behavior before and after changes.

  • Adding a benchmark case for an AI mode
  • Comparing AI chat behavior before and after a change
  • Checking copilot changes with realistic requests
windmill-labs/windmill18.3KUpdated Oct 26, 2026

cli-commands

FreeSummary

Use this reference to work with Windmill resources from the command line, including scripts, flows, datatables, and workspace settings. It also covers listing jobs, inspecting details and logs, retrieving results, and rerunning or restarting executions when investigating failures.

  • Inspecting a failed job and its logs
  • Reviewing recent runs and retrieving job results
  • Managing scripts and flows from the command line
windmill-labs/windmill18.3KUpdated Oct 26, 2026

codebase-design

FreeSummary

Use this skill to shape modules with small interfaces and substantial behavior behind them. It helps you decide where a seam belongs, reduce complexity exposed to callers, and make code easier to test and maintain.

  • Designing a module interface
  • Finding places to simplify a module
  • Choosing where behavior should vary
windmill-labs/windmill18.3KUpdated Oct 26, 2026

commit

FreeSummary

Use this skill to review pending changes, select only the relevant files for staging, and create a focused Git commit. It formats the single-line message with a Conventional Commits type such as feat, fix, or docs, and checks the resulting status.

  • Committing a new feature
  • Recording a bug fix
  • Committing documentation changes
windmill-labs/windmill18.3KUpdated Oct 26, 2026

See all skills by windmill-labs

Report a problem with this skill