本文へ移動
cccskills
無料GitHub で公開日本語紹介

svelte-frontend

WindmillのフロントエンドでSvelteの画面や部品を変更するとき、既存コンポーネントやデザイン規約に沿った実装を支援します。

原文原文の説明を見る

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

windmill-labs/windmillスター 18,276(GitHub 18,276 + cccskills 0)
連携ツールPlaywright

実行スコア 未検証

インストール方法を見る

こんなときに便利

  • 既存部品を使って画面を追加したいとき
  • Svelteのフォームを修正したいとき
  • デザイン規約に沿ってUIを整えたいとき
  • ブラウザーで画面変更を確認したいとき

日本語での紹介

できること

Windmillのfrontend/でSvelteの画面やコンポーネントを作成・変更する際の実装指針を示します。まず既存のコンポーネントを探し、ブランドガイドラインで見た目や文言のルールを確認してから組み立てます。ボタン、テキスト入力、セレクトなどのデザインシステム部品の使い方や、Tailwind CSSによるスタイリング、アイコンの扱いも説明します。新しい画面の利用状況を計測する場合の登録先や、ブラウザー上で変更を確かめる手順にも触れています。

こんなときに便利

Windmillのフロントエンドに画面やフォームを追加したい人、既存UIを修正したい人に向いています。既存部品やデザイン規約を踏まえ、サイズや色、文言の一貫性を保って実装したいときにも役立ちます。

使い方の例

  • 「既存の部品を使って設定画面にフォームを追加して」
  • 「このSvelte画面のボタンと入力欄をガイドラインに合わせて」
  • 「変更した画面をブラウザーで確認して」

注意点

Windmillのfrontend/を対象とします。Svelteの一般的な構文資料にはSvelte MCPサーバーを使い、変更の確認にはPlaywright MCPを使う手順です。Svelteコードは最終化前にsvelte-autofixerで確認します。

この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。

含まれるファイル(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 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

adding-a-trigger

無料概要あり

Windmillに新しいTriggerCrud型のトリガーを追加する際、バックエンドからCLI、画面、同期やキャプチャ機能まで必要な変更箇所を確認できる開発チェックリストです。

  • 新しい外部サービスのトリガーを追加したいとき
  • 実装箇所の抜け漏れを点検したいとき
  • トリガー追加のPR前に検証したいとき
windmill-labs/windmill1.8万2026年10月26日 更新

ai-chat

無料概要あり

WindmillのAIチャットを変更するときに、ツールやプロンプト、結果の返し方、コンテキスト量を整理し、評価で変更前後の挙動を比べるための指針です。

  • チャットツールを変更したいとき
  • プロンプトの配置を見直したいとき
  • コンテキスト消費を抑えたいとき
windmill-labs/windmill1.8万2026年10月26日 更新

ai-evals

無料概要あり

WindmillのAI生成モード向けに、実際の利用要求に沿ったベンチマークケースを作成・実行します。生成結果を決定的な検証とLLM評価で確認し、AIチャットやcopilotの変更前後を比較できます。

  • AI生成モードの評価ケースを追加したいとき
  • AIチャットの変更前後を比較したいとき
  • copilotの生成品質を確認したいとき
windmill-labs/windmill1.8万2026年10月26日 更新

cli-commands

無料概要あり

Windmill CLIのコマンドを使い、スクリプトやフローなどの管理、ジョブの実行履歴確認、失敗原因の調査を進めるためのリファレンスです。

  • 失敗したジョブの原因を調べたいとき
  • 実行履歴やジョブログを確認したいとき
  • CLIでスクリプトやフローを管理したいとき
windmill-labs/windmill1.8万2026年10月26日 更新

codebase-design

無料概要あり

モジュールのインターフェースを小さく保ちながら、内部に複雑な処理をまとめる設計を支援します。テストしやすさや変更のしやすさを考え、処理の境目を整理できます。

  • モジュールのインターフェースを設計したいとき
  • 既存モジュールの複雑さを整理したいとき
  • 処理を差し替える境目を決めたいとき
windmill-labs/windmill1.8万2026年10月26日 更新

commit

無料概要あり

変更内容を確認し、対象ファイルだけを選んで、形式や長さの規則に沿ったConventional Commits形式のGitコミットを作成するスキルです。

  • 機能追加をコミットしたいとき
  • バグ修正を記録したいとき
  • 変更内容に合うコミット文を作りたいとき
windmill-labs/windmill1.8万2026年10月26日 更新

windmill-labs のスキルをすべて見る

このスキルの問題を報告する