Windmillに新しいTriggerCrud型のトリガーを追加する際、バックエンドからCLI、画面、同期やキャプチャ機能まで必要な変更箇所を確認できる開発チェックリストです。
- 新しい外部サービスのトリガーを追加したいとき
- 実装箇所の抜け漏れを点検したいとき
- トリガー追加のPR前に検証したいとき
WindmillのフロントエンドでSvelteの画面や部品を変更するとき、既存コンポーネントやデザイン規約に沿った実装を支援します。
Svelte coding guidelines for the Windmill frontend. MUST use when writing or modifying code in the frontend directory.
実行スコア 未検証
インストール方法を見るWindmillのfrontend/でSvelteの画面やコンポーネントを作成・変更する際の実装指針を示します。まず既存のコンポーネントを探し、ブランドガイドラインで見た目や文言のルールを確認してから組み立てます。ボタン、テキスト入力、セレクトなどのデザインシステム部品の使い方や、Tailwind CSSによるスタイリング、アイコンの扱いも説明します。新しい画面の利用状況を計測する場合の登録先や、ブラウザー上で変更を確かめる手順にも触れています。
Windmillのフロントエンドに画面やフォームを追加したい人、既存UIを修正したい人に向いています。既存部品やデザイン規約を踏まえ、サイズや色、文言の一貫性を保って実装したいときにも役立ちます。
Windmillのfrontend/を対象とします。Svelteの一般的な構文資料にはSvelte MCPサーバーを使い、変更の確認にはPlaywright MCPを使う手順です。Svelteコードは最終化前にsvelte-autofixerで確認します。
この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
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.
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:
| Building | Section 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.
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.
<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.
<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'
<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'
lucide-svelteNever write inline SVGs. Import from lucide-svelte:
<script>
import { ChevronLeft, X } from 'lucide-svelte'
</script>
<ChevronLeft size={16} />
Form components (TextInput, Toggle, Select, etc.) should use the unified size system when placed together.
frontend/brand-guidelines.md)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.
Use the Svelte MCP tools when working on Svelte code:
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.
まだレビューはありません。使ってみた感想をお寄せください。
ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。
まだコメントはありません。最初のコメントを書いてみませんか。
Windmillに新しいTriggerCrud型のトリガーを追加する際、バックエンドからCLI、画面、同期やキャプチャ機能まで必要な変更箇所を確認できる開発チェックリストです。
WindmillのAIチャットを変更するときに、ツールやプロンプト、結果の返し方、コンテキスト量を整理し、評価で変更前後の挙動を比べるための指針です。
WindmillのAI生成モード向けに、実際の利用要求に沿ったベンチマークケースを作成・実行します。生成結果を決定的な検証とLLM評価で確認し、AIチャットやcopilotの変更前後を比較できます。
Windmill CLIのコマンドを使い、スクリプトやフローなどの管理、ジョブの実行履歴確認、失敗原因の調査を進めるためのリファレンスです。
モジュールのインターフェースを小さく保ちながら、内部に複雑な処理をまとめる設計を支援します。テストしやすさや変更のしやすさを考え、処理の境目を整理できます。
変更内容を確認し、対象ファイルだけを選んで、形式や長さの規則に沿ったConventional Commits形式のGitコミットを作成するスキルです。