Plugins turn context into repeatable workflows

OpenDesign's plugin system addresses the point where a reusable skill stops being enough. A skill can tell an agent how to make a landing page; a plugin can package that skill with inputs, previews, design-system references, permissions, stages, and provenance so a person or another agent can apply it as a real task. The focus here is the plugin lifecycle—from pure resolution to a bounded run—because that is what lets the reader judge whether OpenDesign's composability is operational or merely a collection of portable files.

The distinction is subtle but important. A plugin is not a miniature application panel that runs beside the canvas. In OpenDesign's model, the active process is still an agent run. The plugin is the typed envelope that tells the daemon which portable behavior to resolve, what context to show, which capabilities may be needed, and how the task should progress.

A plugin is a package with a stable boundary

The foundation remains SKILL.md. Its Markdown body is the portable agent contract: a compatible coding agent can read it without knowing anything about OpenDesign. The optional open-design.json sidecar adds information for the host product. It can supply a title and version, a use-case query, typed inputs, preview assets, references to skills and design systems, craft requirements, capabilities, pipeline stages, and other context. The sidecar enriches discovery and application; it does not create a second, proprietary language for the underlying agent behavior.

That “one folder, two consumption modes” arrangement is the plugin system's first useful boundary. Outside OpenDesign, a folder with SKILL.md can remain an ordinary skill. Inside OpenDesign, the same folder can become a marketplace card, an inline workflow, or a headless CLI input. The user may fill in a few declared values, inspect context chips, and see a preview before starting the run. The project can also retain which plugin was applied. None of that requires the plugin to own a UI process or to mutate the project merely because someone opened its detail page.

The daemon's apply operation makes that separation concrete. Applying a plugin is designed to be pure: it validates and coerces the declared inputs, resolves references to skills, design systems, craft, assets, MCP servers, or connectors, computes a digest of the applied manifest and context, determines the capabilities required and granted, and returns an ApplyResult. The result can hydrate a brief, show context items, expose input fields, and describe the prospective pipeline. At this stage, the operation does not write project files, start an agent, or persist a database snapshot as a side effect of simply inspecting and resolving the plugin.

Purity matters because applying and running are different decisions. A person should be able to click through a plugin, see that it requires a connector or a particular capability, and then cancel without leaving staged files behind. A headless caller should be able to inspect the result before authorizing a process with wider access. The separation also gives the system a clean place to reject missing required inputs. A blank audience field or absent topic is an input problem, not a failed model run.

Side effects happen when the user or caller crosses the run boundary. Project creation or run start can stage plugin assets, establish MCP or connector state, and attach the applied context to the project or conversation—but only after the trust and capability checks. The daemon then composes the plugin's resolved context into the same system-prompt and execution path used by other OpenDesign tasks. In this design, a plugin is not a hidden shortcut around the main architecture; it is an explicit input to that architecture.