菜单
Use when creating or editing any UI component, styling, button, input, form, card, modal, or layout. Enforces the project design system — Inter font, 8-pixel grid, green/navy palette, named color tokens, dark/light theming, responsive layout, and icon/spacing rules.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Use when building, packaging, or releasing a connector (or later a tool/job) as an EXTERNAL wick PLUGIN — a separate binary in the plugins monorepo that wick downloads and runs over gRPC, instead of an in-tree module compiled into wick. Covers the plugins repo layout (one folder per plugin under connector/<key>/), the key==folder one-identity rule, `wick plugin build` (zip output, --kind, --target list / --all, BUILD_TARGETS, signing), `wick plugin catalog` (regenerate plugins.json from releases), DefaultTags categorization via plugins/tags, install/enable/disable via the app, the install dir resolved from appname.Resolve(), and the dispatch-driven release CI flow. The MODULE contract itself (Meta, Configs, Operations, Ctx, wick:"..." tags) is identical to in-tree modules — defer to the connector-module / tool-module skills for that; this skill is ONLY the plugin packaging + shipping layer on top.
Use for ANY work on the Svelte SPAs or shared FE libraries under fe/ — adding or editing a component, writing API calls, creating a new SPA workspace, porting templ-embedded JS into a SPA, wiring a new route, or extracting shared code. Covers the npm-workspaces layout (fe/common/* shared libs + fe/agents/* SPAs), the Effect-based HTTP client contract in @wick-fe/common-api, the @wick-fe/common-stores and @wick-fe/common-ui packages, the three TDD layers (Effect mock layer, @testing-library/svelte, store tests), the Go SPA routing/thin-shell contract, and the ENFORCED deduplication rule (2+ copies of an api fn / UI component / store must be extracted to common/* in their own commit).
Use for ANY work on a connector in the wick core repo — creating a new connector under internal/connectors/, refactoring/improving an existing one, fixing bugs, adding operations, editing the Configs or per-op Input structs, or touching anything that affects the MCP surface (internal/mcp/) or the registry (internal/connectors/registry.go). Covers the full module contract — pkg/connector.{Meta, Module, Operation, Op, OpDestructive, ExecuteFunc, Ctx} — plus the wick:"..." tag grammar shared with Tools and Jobs, the destructive-opt-in model, the typed-response convention, the http.NewRequestWithContext rule that prevents goroutine leaks, and the Bootstrap auto-seed contract. Also mandates the "ask before adding ops" question whenever a new connector is requested.
Use for ANY work on a workflow node type — creating a new node executor under internal/agents/workflow/nodes/, refactoring/improving an existing one, adding fields to a node's schema, or wiring the executor into setup/manager.go. Covers the full executor contract — workflow.Executor interface, engine.NodeDescriptor for MCP catalog, schema reflection via wick:"..." tags, output field documentation, the engine.Register/RegisterWithDesc dispatch, and the goroutine-context discipline shared with connectors. Also mandates the "Descriptor() method is the source of truth" rule — schema and output docs live next to the executor, never in mcp/.
Use for ANY work on a tool OR job in this wick-based project — creating new, improving/refactoring existing, fixing bugs, editing view/handler/service/JS, adding features, or touching anything under tools/{tool}/ or jobs/{job}/. Enforces the wick module contract (top-level stateless Register(r tool.Router) for tools or Run(ctx) for jobs, Key-driven mount path, typed Config with wick:"..." tags, JS-first compute, per-module //go:embed js, no CDN, dark/light + responsive). MANDATORY clarify+plan loop before writing any new tool/job code — first reply is always questions + a written plan, never files. Only after the user confirms does code get written. Also mandates reading tools/convert-text/ end-to-end before any new tool and asking the "do you need runtime-editable configs?" question with the widget catalog.
Use for ANY work on an agent channel transport — creating a new channel under internal/agents/channels/<name>/ (Slack, Telegram, Discord, …), refactoring an existing one, fixing bugs in event fan-out / approval flow / hot-reload, or touching the registry, setup composer, or shared interfaces in internal/agents/channels. Covers the Channel contract — Name/Start/Stop/IsConfigured plus the opt-in setter and receiver interfaces (SendFuncSetter, SessionCheckerSetter, SessionStartHookSetter, ApproveFnSetter, PublicURLSetter, AgentEventReceiver, ApprovalReceiver, HTTPHandlerProvider) — the ConfigSource hot-reload contract, the registry-driven type-assertion wiring, and the per-transport ConfigStore abstraction that keeps gorm out of subpackages.
| name | design-system |
| description | Use when creating or editing any UI component, styling, button, input, form, card, modal, or layout. Enforces the project design system — Inter font, 8-pixel grid, green/navy palette, named color tokens, dark/light theming, responsive layout, and icon/spacing rules. |
| allowed-tools | Read, Grep, Glob, Edit, Write |
| paths | ["**/*.templ","**/*_templ.go","**/*.go","**/*.js","**/*.css","**/tailwind.config.*"] |
Enforces the project's visual language whenever Claude writes or edits UI
code — templ components, Tailwind classes, CSS tokens, theme files, or
tailwind.config.*. Every rule below is derived from the living token set
in tailwind.config.js and web/src/input.css.
tailwind.config.*Skip for purely backend / non-visual work.
Inter font only. All text uses Inter via font-sans. No other
typeface in the UI.
8-pixel grid. Spacing, padding, margin, width, and height are
multiples of 8 (8, 16, 24, 32, 40, 48, 56, 64, 72, 80). The
sub-8 exceptions 4px, 12px, and 20px are allowed when 8-grid
is too coarse.
Named tokens only. Every color maps to a Tailwind token defined in
tailwind.config.js (see tokens.md). Raw hex is allowed only
inside the token definition itself.
Accent vs. status separation. green-* is the primary accent
color — never reuse it for "success." navy-* is for dark surfaces
and login — never reuse it for "info." Status intent uses the
dedicated ramps: pos-*, prog-*, cau-*, neg-*, error-*,
warning-*, link-*.
Text from Black ramp. All body/title/paragraph text uses
black-600 through black-900. Never color body text with
green or navy.
Dark + light mode required. Every color class must have a dark:
counterpart. Use the themed CSS-variable tokens (navy-*, black-*,
white-*) so themes work automatically. See the "Theming" section
below.
Mobile-first and responsive. Build for narrow viewports first,
then layer sm: / md: / lg: overrides. Test mentally at ≤375px
before declaring done.
Icons. Container is a multiple of 8 (16, 18, 24, 32, 40, 48px).
Stroke width 2px. Padding 1–2px between glyph and container edge.
Font weights: 400 / 500 / 600 only. font-normal (400),
font-medium (500), font-semibold (600). No bold (700), no light
(300), no italic — unless the user explicitly asks.
No invented values. If a token doesn't exist, reuse the closest
project value or ask the user. Never add arbitrary Tailwind values
like p-[13px] or inline hex.
Full catalog in tokens.md. Most-used values:
| Purpose | Token | Hex |
|---|---|---|
| Primary accent (buttons, sidebar) | green-500 | #27B199 |
| Secondary accent (login, dark surfaces) | navy-500 | #01416C |
| Body text default | black-900 | #0A0A0A |
| Body text muted / subtitle | black-800 | #565656 |
| Disabled text | black-700 / black-600 | #A0A0A0 / #BFBFBF |
| Page background | white-100 | #FFFFFF |
| Surface / subtle bg | white-200 | #FAFAFA |
| Border / divider | white-300 / white-400 | #ECECEC / #DFDFDF |
| Success | pos-400 | #288C7A |
| Info | prog-400 | #56CCF2 |
| Warning | cau-400 / warning-400 | #D78E08 |
| Destructive / error | neg-400 / error-400 | #EB5757 / #EF4C00 |
| Hyperlink | link-400 | #007BFF |
Spacing (px): 4, 8, 12, 16, 20, 24, 32, 40, 48, 56, 64, 72, 80
Font: Inter, sans-serif — weights 400, 500, 600
Shadows: shadow-sm → shadow-md → shadow-lg → shadow-xl
Radius: rounded-sm (4px) → rounded (8px) → rounded-lg (12px)
→ rounded-xl (16px) → rounded-full
The project ships 12 themes. Colors that change per theme (navy-*,
black-*, white-*) are backed by CSS variables in web/src/input.css.
Green is fixed across all themes for visual consistency.
What this means for you:
bg-white-100 dark:bg-navy-700,
text-black-900 dark:text-white-100, border-white-300 dark:border-navy-600.rgb(...) or #hex for themed colors — use the
Tailwind tokens which resolve to CSS vars at runtime.green-200 through green-800) are hardcoded, not
themed — they look the same in every theme. This is intentional.<main class="mx-auto w-full max-w-container px-6 py-8">@ui.Layout(title) — never write raw <html>.@ui.Navbar(user) — never build a custom nav.1120px (Tailwind max-w-container).Read on demand — don't load all at once:
tokens.md — Complete color palette (all hex values), spacing
scale, typography rules, icon sizing, shadow tiers. Load when picking
colors, setting spacing, or editing tailwind.config.*.components.md — Patterns for buttons, inputs, cards, tabs, modals,
badges, etc. with correct and incorrect examples in templ/Tailwind.
Load when building or editing a specific component..templ → templ generate./bin/tailwindcss* -i web/src/input.css -o web/public/css/app.css --minifygo build ./...make generate runs all three.font-sans (mapped to Inter)pos / prog / cau / neg / error / warning / linkdark: counterpart