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 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.
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.
Use for ANY work on a connector in this project — creating a new connector under connectors/, refactoring/improving an existing one, fixing bugs, adding new operations, editing the Configs or per-op Input structs, or wiring a connector up in main.go. Connectors are the third class of wick module beside Tools and Jobs, designed specifically to be consumed by LLM clients (Claude, Cursor, custom agents) over MCP. MANDATORY clarify+plan loop before writing any new connector or op — first reply is always a recommendation + plan, never files. For well-known APIs (Loki, Gmail, GitHub, Slack, Jira, Notion, Stripe, Datadog, …) explore on the user's behalf and propose a concrete recommended starter operation set with rationale, plus a translated `Configs` shape — don't ask the user to design the connector for you. For unknown / proprietary APIs, ask for sample requests + responses + auth scheme. Plan is presented as business flow (Scope, Configs, Operations, Inputs, auth/error-envelope, registration, open questions) —