본문으로 건너뛰기
cccskills
무료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.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

원문원문 설명 보기

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

windmill-labs/windmill스타 18,282(GitHub 18,282 + cccskills 0)
연동 도구Playwright

실행 점수 미검증

설치 방법 보기

이럴 때 유용합니다

  • 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

포함된 파일(1)

  • SKILL.md6.0 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

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.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

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/windmill1.8만2026년 10월 26일 업데이트

ai-chat

무료

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/windmill1.8만2026년 10월 26일 업데이트

ai-evals

무료

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/windmill1.8만2026년 10월 26일 업데이트

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/windmill1.8만2026년 10월 26일 업데이트

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/windmill1.8만2026년 10월 26일 업데이트

commit

무료

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/windmill1.8만2026년 10월 26일 업데이트

windmill-labs의 스킬 모두 보기

이 스킬의 문제 신고