- Introduced `specVersion` and `version` fields to the plugin and marketplace schemas, ensuring better versioning and compatibility tracking. - Updated various components and functions to handle the new fields, including database migrations, plugin snapshots, and marketplace management. - Enhanced tests to validate the presence and correctness of the new fields in plugin manifests and marketplace entries. - Improved documentation to reflect the changes in schema requirements and provide guidance on the new versioning system. This update strengthens the plugin ecosystem by providing clear versioning, enhancing the reliability and maintainability of plugins and marketplaces.
7.6 KiB
Open Design Plugin Spec
Language: English | 简体中文
This spec is the compact contract for portable Open Design plugins. The canonical product spec remains docs/plugins-spec.md; this document is optimized for contributors and external coding agents.
1. Minimum Plugin
Every publishable plugin should be a directory with a SKILL.md:
my-plugin/
SKILL.md
SKILL.md is the portable agent contract. It must have YAML frontmatter with:
---
name: my-plugin
description: Use this plugin when the user wants...
---
The folder name, name, and manifest name should match. Use lowercase letters, numbers, and hyphens.
2. Enriched Open Design Plugin
Add open-design.json when the plugin should appear in Open Design as a marketplace card or starter:
my-plugin/
SKILL.md
open-design.json
README.md
preview/
examples/
assets/
references/
evals/
open-design.json points at the skill and declares the product surface:
{
"$schema": "https://open-design.ai/schemas/plugin.v1.json",
"specVersion": "1.0.0",
"name": "my-plugin",
"title": "My Plugin",
"version": "0.1.0",
"description": "One sentence marketplace description.",
"license": "MIT",
"tags": ["create", "prototype"],
"compat": {
"agentSkills": [{ "path": "./SKILL.md" }]
},
"od": {
"kind": "skill",
"taskKind": "new-generation",
"mode": "prototype",
"scenario": "product",
"useCase": {
"query": "Create a prototype for {{audience}} about {{topic}}."
},
"pipeline": {
"stages": [
{ "id": "discovery", "atoms": ["discovery-question-form"] },
{ "id": "plan", "atoms": ["direction-picker", "todo-write"] },
{ "id": "generate", "atoms": ["file-write", "live-artifact"] },
{
"id": "critique",
"atoms": ["critique-theater"],
"repeat": true,
"until": "critique.score>=4 || iterations>=3"
}
]
},
"inputs": [
{ "name": "audience", "type": "string", "required": true },
{ "name": "topic", "type": "string", "required": true }
],
"capabilities": ["prompt:inject", "fs:write"]
}
}
3. Workflow Taxonomy
Use one primary lane. Put the lane in tags, od.scenario, or od.mode so search and facets can classify the plugin.
| Lane | Use when | Typical taskKind |
Useful atoms |
|---|---|---|---|
import |
Bring external sources into OD | figma-migration or code-migration |
figma-extract, code-import, design-extract, token-map, rewrite-plan |
create |
Generate a new artifact | new-generation |
discovery-question-form, direction-picker, todo-write, file-write, live-artifact, media-image, media-video, media-audio, critique-theater |
export |
Convert an accepted artifact to a downstream format | tune-collab or code-migration |
file-read, file-write, handoff, diff-review |
share |
Publish or send an artifact to collaborators | tune-collab |
file-read, handoff, connector |
deploy |
Ship an artifact to hosted infrastructure | code-migration or tune-collab |
file-read, build-test, handoff, connector |
refine |
Improve an existing artifact | tune-collab |
file-read, patch-edit, critique-theater, diff-review |
extend |
Help authors create more plugins | new-generation |
file-read, file-write, todo-write, critique-theater |
4. Create Modes
Use od.mode for the main output surface:
| Mode | Output |
|---|---|
prototype |
Interactive single-page web artifact |
deck |
Slide deck artifact |
live-artifact |
Dashboard, report, calculator, simulator, or other live UI |
image |
Generated image, storyboard frame, poster, ad, or visual asset |
video |
Video prompt, storyboard, rendered clip, or motion package |
hyperframes |
HyperFrames-ready HTML motion composition |
audio |
Voice, music, sonic branding, or sound-design asset |
design-system |
Reusable brand or interface system |
HyperFrames plugins may use od.mode: "video" plus a hyperframes tag when they should appear beside video tooling, or od.mode: "hyperframes" when the distinction matters more than the broad video bucket.
5. SKILL.md Authoring Rules
- Write the description for activation: "Use this plugin when..."
- Keep
SKILL.mdunder 500 lines when possible. - Put long API notes, visual rules, or exporter details in
references/. - Reference support files by relative path from the plugin root.
- Include an explicit workflow with checkpoints and expected outputs.
- Describe what to ask the user only when the input is genuinely missing.
- Avoid OD-only marketplace data in
SKILL.md; keep it portable.
6. Manifest Rules
nameis the stable plugin id.specVersionis the Open Design plugin spec version that this manifest follows. Use the current spec kit value (1.0.0) unless the schema moves.versionis required. Use semver when possible.versionis the plugin package version, independent fromspecVersion.compat.agentSkills[0].pathshould point to./SKILL.md.od.taskKindmust be one ofnew-generation,figma-migration,code-migration, ortune-collab.od.pipeline.stages[].atoms[]should use known first-party atoms unless the plugin clearly targets a future OD release.- A repeated stage must include
until. od.capabilitiesshould start small. Restricted installs getprompt:injectby default.
Known v1 capabilities:
prompt:injectfs:readfs:writemcpsubprocessbashnetworkconnectorconnector:<id>
7. Inputs And GenUI
Use od.inputs for simple apply-time values. Use od.genui.surfaces[] when the agent needs controlled human input during a run.
Built-in GenUI surface kinds:
formchoiceconfirmationoauth-prompt
Persistence options:
run- only this run.conversation- future turns in the same conversation.project- future runs in the same project.
8. Examples And Preview
Visual plugins should include one of:
preview/index.htmlpreview/poster.pngpreview/demo.mp4examples/<case>/index.htmlexamples/<case>/README.md
The preview should show the real output shape, not a decorative splash screen.
9. Evals
Add evals/evals.json for repeatable quality checks:
{
"skill_name": "my-plugin",
"evals": [
{
"id": "happy-path",
"prompt": "Create a prototype for a B2B SaaS onboarding flow.",
"expected_output": "A usable HTML artifact with states, polished layout, and no text overflow.",
"assertions": [
"The output includes a runnable artifact file",
"The visual hierarchy is clear",
"The workflow has meaningful empty/loading/success states"
]
}
]
}
Also add evals/trigger-queries.json for activation testing when the description is easy to over-broaden.
10. Publish And PR
Before opening a PR:
- Validate JSON syntax.
- Confirm
open-design.jsonincludesspecVersionand a bumped pluginversionwhen behavior changed. - Run
pnpm guard. - Run
pnpm --filter @open-design/plugin-runtime typecheck. - If available, run
od plugin validate ./path/to/plugin. - Include one screenshot, rendered preview, or example output when the plugin is visual.
- Explain trust and capabilities in the PR body.
For external registry distribution, follow PUBLISHING-REGISTRIES.md. In short: keep GitHub or the Open Design PR as source of truth, make the folder installable as a generic SKILL.md skill, then publish or list it on skills.sh, ClawHub, or other registries only after local validation passes.