open-design

Open Design is a bundled catalog of design skills and design templates (reusable task recipes and rendering styles — both usable interchangeably as a

skillId

) plus design systems (brand-inspired visual token sets), exposed through the

open-design

MCP server's tools.

Every skill/template id is namespaced as

od:<mode>:<name>

(e.g.

od:deck:guizang-ppt

), where

mode

is one of:

prototype

deck

design-system

image

video

template

utility

audio

. Always pass the full namespaced id as

skillId

. Note: mode

design-system

means "a skill that helps author a design-system deliverable" — it has nothing to do with

designSystemId

, which selects from the separate library of ~150 prebuilt brand design systems (see step 2).

A small, curated subset of skills/templates also has its own explicit

/open-design:<id>

skill — if the user's request closely matches one of those, prefer invoking it directly; it pins the exact skillId and often a ready-made example brief, removing any guesswork. Otherwise, follow the flow below yourself.

All Open Design content (skill/template text, design system tokens, example briefs) is delivered to you as plain text through the MCP tool calls below — never as a file path. You never need to, and should not, browse or search for Open Design's own files anywhere on disk;

list_open_design_skills

and

prepare_open_design_brief

already return everything you need as plain text.

How to talk to the user. Many people using Open Design don't write code, so:

Use the user's own words. If they say "artifact", "design tokens" or give a file path, use those terms back; otherwise use the plain words below.
Keep the machinery out of replies: no tool names, no ids like
```
od:prototype:poster-hero
```
, no internal files (
```
.artifact.json
```
,
```
.comments.json
```
,
```
config.json
```
), and not the words "register", "manifest", "sidecar", "entry" or "surface", unless the user used them first.
Explain a print term the first time it comes up, in one short clause, and not again.
Say where a file is the way the user would find it ("in your Open Design folder, under seed-swap-flyer"). Give a raw path only where the user can click it (Claude Code, Claude Desktop's Code tab, VS Code) or asks for it.
End each reply that finishes a step with one line on what they can do next, with at most two options ("Want it in Instagram sizes too, or is it ready to print?").

Instead of	Say
artifact, entry, registered	your design, saved
design system, active design system	your style (the first time: "a saved style: colours, fonts and spacing")
surface, skill, template, recipe	kind of design, starting layout, or nothing
workspace, output directory	your folder, your Open Design folder
bleed	print edge ("a few millimetres extra that the printer trims off")
trim size	final size
preflight findings, errors	"I checked it and fixed…", "one thing to look at:"
export	save as PDF, save as an image
inline preview, MCP App	the preview above

Follow this flow:

Check the tools are wired up. This skill does nothing on its own — every step below calls a tool the
```
open-design
```
MCP server provides. If
```
list_open_design_skills
```
(or any other tool named below) isn't available to you right now, the server hasn't been registered in this project yet. Set it up, then retry from step 1:
- Claude Code: point the user to the setup steps in Claude Code.
- Codex CLI: point the user to the setup steps in Codex.
- Any other MCP-capable agent (Cursor, etc.): point the user to Getting started, which shows how to add the Open Design MCP server to any agent.
- Claude Desktop Chat or claude.ai (no Open Design tools in the chat): don't make anything yet. Welcome the user in plain words, in this shape:
  Open Design can't save or check designs in this chat yet. Two ways to fix that:
  1. Connect a folder: make a folder called "Open Design" (in Documents, for example), then click + in this chat, choose Add folder and pick it.
  2. Install the Open Design extension for Claude Desktop: download it from https://github.com/feimacode/open-design-agent-kit/releases/latest, double-click the file, then start a new chat.
  What's the design for?
  Don't name file types, packages, commands or tools in it. Offer the goals from step 1 below as examples of what they can say ("promote an event", "show an idea", "get hired"). Only if they want to go ahead without either, make one self-contained HTML page and publish it with your own Artifact tool, and say it can't use saved styles, checks or saving as PDF and images.
Run the command yourself if you have shell access; otherwise tell the user the exact command to run and wait for their confirmation before continuing. Skip this step entirely once the tools are available.
In Claude Desktop (a chat or Cowork session with a folder the user connected), the server runs on the user's machine and starts in their home folder, and your file tools see the folder under a different path. Before any other Open Design tool, call
```
set_open_design_workspace
```
with the folder's path on the user's machine (the one
```
get_device_info
```
lists under
```
connectedFolders
```
). Every path other tools return is relative to that folder: join it onto your own path for the folder when you read or write files, and when you attach or show a file with your own tools, give the full path: a relative one resolves against your shell's current folder, which moves when you
```
cd
```
. If a tool says it would be working in the home folder, this is what it's asking for. The first time you set the folder in a chat, tell the user in one sentence where their designs will be saved (the folder's name and the
```
Open Design
```
folder inside it) and that they can open it any time; don't repeat it for later designs.
In Claude Desktop Chat with no folder (
```
use_open_design_managed_workspace
```
is in your tools), your own file tools, if you have any, can't reach the server's files. Call
```
use_open_design_managed_workspace
```
first with a short name for the design, and tell the user once, in one sentence, the folder's absolute path from its result (under
```
~/Documents/Open Design/
```
by default), so they can open it. Then save every design file with
```
write_open_design_file
```
(the whole file each time, under the output directory) instead of your own file tools, and register, check and export as usual. Show the design with
```
show_open_design_artifact
```
once; later rounds update that inline copy by itself. Don't keep a per-round Claude artifact preview here. The managed folder is the source of truth: to edit, send the full new file through
```
write_open_design_file
```
. If the chat has a connected folder, use
```
set_open_design_workspace
```
instead.
Call
```
list_open_design_skills
```
(optionally with a
```
query
```
and/or an exact
```
mode
```
) to find a skill or design template that matches what the user wants. Pick the best match by name/description/triggers, and prefer a result's
```
examplePrompt
```
(adapted to the user's specifics) over inventing your own brief when one is present and closely fits.
There is an active design system, persisted per project (a local
```
.open-design/config.json
```
file). If the user mentions a brand, company, industry, or visual style that differs from what's active, call
```
list_open_design_design_systems
```
(optionally with a
```
query
```
and/or an exact
```
category
```
— call with no arguments first to see categories, and check each result's
```
active
```
flag) to find the right one, and pass its id explicitly to
```
prepare_open_design_brief
```
— doing so also makes it the new active one going forward, so you don't need to re-specify it on later requests in this project. For phone screens (the Mobile app surface, or a brief like "a budgeting app that feels like Monzo"), look in the
```
Mobile Apps
```
category first, with the app's name as
```
query
```
: those systems are adapted from the real iOS apps (tab bars, sheets, iOS point sizes). Use
```
<app>-ios
```
(e.g.
```
spotify-ios
```
) for phone screens even when a web system of the same brand exists (
```
spotify
```
); the web one stays the right choice for web pages. If the user hasn't mentioned any direction and one is active, just omit
```
designSystemId
```
from
```
prepare_open_design_brief
```
and it will use the active one. If none is active and the user hasn't named a direction, recommend one before preparing a new design (not for an edit, a remix or an export): call
```
recommend_open_design_design_systems
```
with what you know from the request, the conversation and the workspace (
```
industries
```
,
```
moods
```
,
```
theme
```
,
```
surface
```
,
```
likeBrands
```
,
```
brief
```
), leaving out what you don't know. If its result has
```
questions
```
, ask them once, as short multiple-choice options: through
```
show_open_design_questions
```
where it is in your tools, else in one message (or your host's question tool if it has one), and accept "you pick"; then call it again with the answers. Ask them in the same message as any surface questions, three in total at most. Show the shortlist: where
```
show_open_design_design_systems
```
is in your tools, pass it the recommended
```
ids
```
; elsewhere, a short numbered list with each name and its
```
reason
```
. Don't wait for a pick unless you asked questions: go ahead with the first recommendation, pass its id to
```
prepare_open_design_brief
```
, and say which style you used and that they can pick another. If
```
recommend_open_design_design_systems
```
isn't in your tools, use
```
list_open_design_design_systems
```
instead, or go without one. Only call
```
set_active_design_system
```
directly when the user wants to pin a look before generating anything ("let's use the Starbucks look from now on").
Call
```
prepare_open_design_brief
```
with the chosen
```
skillId
```
, optional
```
designSystemId
```
(per step 2), and the user's
```
brief
```
(their request, in their own words). This returns
```
instructions
```
to follow, a
```
suggestedEntryPath
```
, and the
```
designSystemId
```
/
```
designSystemName
```
actually used (whether explicit or defaulted from active) — mention which one it was if it wasn't obvious from the conversation. It does NOT write any files.
Follow the returned
```
instructions
```
and author the artifact's entry file (plus any supporting files) yourself, using your own file-editing tools. Do not look for a separate tool to write the design content.
Call
```
register_open_design_artifact
```
with the entry path, a
```
kind
```
, a
```
title
```
, and any
```
supportingFiles
```
, so the artifact is recognized and gets its manifest sidecar written.
Call
```
check_open_design_artifact
```
with the entry path before telling the user it's done (after creating an artifact, and again after a substantial edit). It renders the artifact and returns screenshots plus preflight findings: fix every error, then look at the screenshots for what the checks can't measure — balance, hierarchy, crowded or empty areas, text over busy imagery — and fix what's clearly wrong. Taste warnings (
```
slop-glow
```
,
```
card-row
```
,
```
uniform-surface
```
,
```
type-scale
```
,
```
intent
```
) are worth a look: fix them unless the brief or the design system asks for that look, and never add
```
data-od-allow
```
only to silence one. Re-check after fixing, but stop after two fix rounds and tell the user about anything left. Then get a second look before you call it done: once the checks are clean or the fix rounds are spent, run the
```
open-design-critique
```
skill, which has a fresh critic judge the latest check run against the brief and the design system on purpose and hierarchy, typography, colour and contrast, layout and rhythm, copy, states, and fit, so build with those in mind. One critique round: on
```
polish
```
, apply its fixes once, register and re-check, then report done without another critique; on
```
rework
```
, tell the user what's wrong and ask before rebuilding; on
```
ship
```
, it's done. The brief or design system wins over a finding against a look it asks for, and the user can ask for another opinion at any time or say they don't want one. 3D designs are the exception: when the check returns a 3D review sheet, a clean check isn't the end. Get the critique the check result asks for (the
```
3d-object
```
skill's scorecard, from a subagent where your host has one), then fix, re-check and re-critique for up to three critique rounds, which replace the two-fix-round limit and the second look above. Don't describe the screenshots to the user unless they ask: each run's screenshots are saved for them, and the browser preview's Checks panel shows them before and after (the result also lists the saved paths). If it returns
```
no-browser
```
, skip checking and tell the user once that visual checks need Chrome, Edge or Chromium installed.
Optionally call
```
get_open_design_artifact
```
to confirm what was written before telling the user it's done.
After the first artifact you register in a session, call
```
open_open_design_preview
```
with its entry path, unless the user said they don't want it, so they can see it. It opens a live browser preview that reloads whenever the file changes, so don't call it again after edits; call it again only to switch to another artifact. Mention that they can click Comment in the preview to leave comments on elements.
In Claude Desktop's Code tab (its preview tool, named like
```
preview_start
```
, is in your tools), use the Browser pane instead of a separate window: the first time you show a design in the session, call
```
set_up_open_design_browser_pane
```
(once per project; tell the user once, in one sentence, that you added a preview entry to
```
.claude/launch.json
```
), then start the
```
open-design-preview
```
configuration it names with that preview tool. The pane opens on the newest registered design and reloads when its files change. For a later design, reload the pane if your preview tools can, or tell the user it's in the pane's list. If the pane can't start, fall back to
```
open_open_design_preview
```
.
In Claude Desktop Chat (a chat conversation, not the Code tab or a terminal), call
```
show_open_design_artifact
```
with the entry path instead: it shows the design inline in the conversation, where the user can comment and click Ask Claude to apply. Call it once per design, after its first
```
register_open_design_artifact
```
: that copy follows later edits and applied comments by itself, so don't show the same design again unless the user asks. The register result says which applies. If its result says the host doesn't show MCP Apps, fall back to
```
open_open_design_preview
```
as above. Its export buttons post a request in the chat: run
```
export_open_design_artifact
```
with the format named and tell the user the path. For an exploration, pass
```
explorationId
```
to show the directions side by side; when the user picks one with Take this one, ask which next step they want before calling
```
choose_open_design_direction
```
. A style-tile exploration also offers Use as design system, which asks directly for
```
choose_open_design_direction
```
with
```
next: "save-design-system"
```
.
Picking by eye in Claude Desktop Chat. Two more tools are listed only where the host shows MCP Apps inline, so use them only when they are in your tool list:
```
show_open_design_examples
```
shows the remixable examples as a gallery of live previews (filter by
```
query
```
,
```
mode
```
or
```
surface
```
), and
```
show_open_design_design_systems
```
shows design systems as tiles (pass
```
ids
```
for a shortlist). Use them when the user wants to choose a starting example or a brand look and hasn't named one. Picks arrive as chat messages naming the tool to call: "Remix this" means
```
remix_open_design_example
```
with that skillId (ask what to make first if the user hasn't said); "Use this design system" means
```
set_active_design_system
```
with that id. Elsewhere, keep to
```
list_open_design_skills
```
and
```
list_open_design_design_systems
```
.
Linking the public gallery. Some results carry a link to the Open Design gallery, a website with every example and design system:
```
gallery.url
```
from
```
show_open_design_examples
```
and
```
show_open_design_design_systems
```
, and
```
designSystem.galleryUrl
```
from
```
register_open_design_artifact
```
. They appear only while the gallery is live; never write a gallery link yourself. When the user is browsing (wants to look before deciding: "show me some examples", "what styles are there?", "ideas for a café menu"), show the in-chat gallery where it is in your tools, then add one line linking
```
gallery.url
```
("See them all in the Open Design gallery."), unless you already linked the gallery in this conversation. When a design is ready and its register result has
```
designSystem.galleryUrl
```
, name the design system with that link in the sentence that says it's ready ("It uses the Kami design system."), the first time you use that design system in the conversation; not again for later rounds or designs in the same style. Never link the gallery before building on a concrete request ("a poster for our seed swap on Saturday"), after an export or publish, or in a recurring job run.
Asking with taps in Claude Desktop Chat.
```
show_open_design_questions
```
is listed only where the host shows MCP Apps inline. Where it is in your tool list, ask every short multiple-choice question through it instead of a chat message: the surface and design-system questions before a build, which direction after an exploration, "fix these?" after a review. Up to four questions, each with a short
```
id
```
,
```
text
```
, a
```
kind
```
(
```
single
```
,
```
multi
```
or
```
text
```
) and up to eight
```
options
```
; an option can carry
```
imageRef
```
(
```
designSystem:<id>
```
,
```
example:<skillId>
```
,
```
artifact:<entryPath>
```
or
```
checkRun:<entryPath>
```
), never a URL. Don't repeat the questions in chat. The answer arrives as a message starting "Answers:" with a line
```

```
: read that JSON (question id to option id, an array for
```
multi
```
, typed text, or
```
you-pick
```
, meaning choose for them and say what you chose). Accept typed answers too. The artifact view also has three quick replies under the design ("Looks good", "Change something", "Try another direction"); each posts a message saying what to do next. Elsewhere, ask in one chat message.

When a request says what the design is for but not what to make ("help me promote our seed swap", "something to get a UX job"), or is too vague to tell, call

list_open_design_skills

with

surface: "list"

: its

goals

are plain-language aims (Promote an event, Show an idea, Get hired…). Take the goal that fits, or show the goals (label and description) and ask one question, "What's it for?". Then call it with

goal

set to that id and continue with the surface marked

default

, asking which one only when the request doesn't settle it and the goal leads to several. Don't show the user the list of surfaces unless they ask what kinds of thing you can make.

When a request names a kind of thing to make (a prototype or landing page, app screens (a settings page, table, form, search or detail screen of a product, or a sign-in, onboarding, paywall or settings flow: surface

app-screens

, never

prototype

), mobile app, slides, document, wireframe, animation, résumé, research synthesis, data report, poster or flier, social post, diagram, 3D object), call

list_open_design_skills

with

surface

set to that kind first (

surface: "list"

shows the ids). Pick from its entries and follow the surface's prompt when it names one. Questions: a surface lists a few

questions

, each with

options

, a

default

and what the answer

changes

. Ask only the ones the request, the conversation and the workspace don't already answer: at most three in total, merged with any design-system recommender questions (surface ones first), in one message, as multiple choice, accepting "you pick" (then use the question's

default

). A request that already says enough gets no questions. Pass the answers to

prepare_open_design_brief

answers

(question id to answer) and what you decided without asking as

assumptions

(up to six short lines), then pass both, with the request in one line as

text

, to

register_open_design_artifact

brief

. When the design is ready, list the assumptions in one sentence and invite a change ("I assumed a dark theme and one sign-up button; say if you want otherwise"). A request for one specific template or style still goes straight to it. Never pick an entry marked

stub: true

: it only advertises an upstream skill and has no instructions here.

For engineering documents (an RFC, ADR, postmortem, PR explainer or changelog page), use the matching skill (

od:prototype:rfc

adr

postmortem

pr-explainer

changelog-page

). Gather the facts yourself first, from git (

git log

git diff

) and the files involved, and register what you read as

sources

. Never invent incident facts, dates or numbers: ask for them. To turn a folder of Markdown docs into pages, follow the docs flow (load the

open-design-docs

skill): one page per file, one template for the set, and on a re-run only the pages whose Markdown changed.

For a recurring design ("every week", "on a schedule", "each month from the new numbers") or a prompt that says "Run the Open Design job <path>", load the

open-design-recurring

skill: the job lives in

.open-design/jobs/<id>.job.md

, each run starts with

start_open_design_job_run

(stop when it returns

skip

) and ends with

finish_open_design_job_run

, and job runs never publish publicly or post to social networks.

If the request is based on a document (it names or attaches a report, spec, spreadsheet, PDF or existing deck, or points at repository files such as

CHANGELOG.md

docs/adr/

, an RFC or a metrics CSV), generate from it rather than from memory: pass those workspace paths as

sources

prepare_open_design_brief

. Typical examples: "a release deck from CHANGELOG.md", "an architecture review from docs/adr/", "a board update from metrics/q3.xlsx", "turn docs/q3-report.docx into a pitch". The tool extracts each document (DOCX, PPTX, XLSX, PDF with

pdftotext

, Markdown, text, CSV) to Markdown and returns instructions that make you write an outline first and stop for the user's approval before building. Follow them: read the extracted text by line range, write

outline.md

, show it, and wait (unless the user said to just build it). Then register with the same

sources

; its result lists numbers on the page that it couldn't find in the sources, so check and fix each one. Use

read_open_design_source

on its own to look inside a document before deciding how to use it. For a whole folder of files (such as

docs/adr/

), pass the relevant files individually (up to 10).

When the user wants to choose colors and fonts, a palette or a type pairing, or a look for a new brand ("show me some color and type options", "what could our brand look like?"), run the exploration with the style-tile skill (

skillId: "od:design-system:style-tile"

): it makes compact tiles (palette with contrast, type specimen, components) instead of pages, 4 by default. To vary the active design system rather than replace it ("the same but warmer"), use

axis: "custom"

with one direction per variation. When the user picks a tile, call

choose_open_design_direction

with

next: "save-design-system"

: the tile's tokens are copied verbatim into the new system, which then becomes active.

If the user explicitly asks for options to compare ("show me three directions for…", "a few different versions of…", "explore some alternatives", "I'm not sure what style I want, show me options"), run a design exploration instead of steps 3–5. Don't explore for an ordinary request ("design a pricing page"): it costs several generations.

Call
```
prepare_open_design_exploration
```
with the
```
skillId
```
and the user's
```
brief
```
(and
```
count
```
2–4 if they gave a number; default 3). The tool picks deliberately different directions itself: visual styles when no design system is active, layout/narrative structures when one is (so the brand is kept), or pass
```
axis: "custom"
```
with
```
customDirections
```
when the user named what should vary ("three hero concepts"). Pass
```
directionIds
```
only when the brief's tone clearly calls for specific ones (e.g.
```
editorial-monocle
```
for a magazine,
```
brutalist-experimental
```
for an art or agency site). If the result says the active design system was set aside, tell the user.
For each returned direction, follow
```
sharedInstructions
```
followed by that direction's own
```
instructions
```
, write its file at its
```
suggestedEntryPath
```
, and call
```
register_open_design_artifact
```
with the
```
explorationId
```
and that direction's
```
directionId
```
. Directions are quick sketches (one screen, or a cover plus two slides), not full builds. If you can delegate work to sub-agents, generate the directions in parallel, passing each one
```
sharedInstructions
```
plus its own
```
instructions
```
.
Call
```
compare_open_design_exploration
```
with
```
contactSheet: true
```
. If you can view images, open the contact sheet and check the directions really look different (layout and hero pattern, not just colour); regenerate any that resembles another.
Show the user the comparison page path (
```
compareFile
```
; it opens in any browser straight from the file system and shows every direction side by side) and the contact sheet path, each on its own line, briefly describe how each direction differs, and ask which one to take forward (through
```
show_open_design_questions
```
where it is in your tools, with each direction as an option and
```
imageRef: "artifact:<its entry path>"
```
).
When the user picks one, call
```
choose_open_design_direction
```
with
```
next
```
:
```
build-out
```
(build the chosen sketch out at full fidelity),
```
merge
```
(the same, taking named aspects from other directions via
```
mergeFrom
```
, e.g. "B with A's hero"), or
```
save-design-system
```
(turn the direction into a reusable custom design system). Follow the returned
```
instructions
```
and register the result as they say.

Generated artifacts land under the project's Open Design output directory (default

.open-design/

) so they stay visible and trackable in version control like any other project file. After registering or updating an artifact, tell the user where it was written, with its workspace-relative entry path (e.g.

.open-design/coffee-poster/coffee-poster.html

) on its own line: in Claude Desktop's Code tab, clicking that path opens it in the Browser pane. Don't open the HTML file in a browser yourself:

open_open_design_preview

(or

show_open_design_artifact

in Claude Desktop Chat) is how it is shown.

Comments from the preview. When the user says they left comments (or pastes the preview's "Apply my comments" instruction, or the inline preview posts it), call

get_open_design_artifact

for that entry. Its

openComments

lists each comment's note and the element it points at (

selector

text

htmlHint

rect

); screenshots of up to 4 commented elements are attached as images, and every comment's

screenshot

path is listed. Change only those elements, with your own file-editing tools, then call

register_open_design_artifact

again with the comments' ids as

resolvedCommentIds

so their pins leave the preview, and run the check as in step 6. In Claude Desktop Chat, the inline copy updates by itself; tell the user it's updated rather than showing it again.

If the user wants to start from or riff on an existing example rather than build something new, prefer

remix_open_design_example

(skillId must be an entry with

remixable: true

) over

prepare_open_design_brief

— it copies a working starting artifact into the project and tells you to modify it rather than regenerate from scratch. See references/remixable-examples.md for the full list of what's available to remix, grouped by mode — check it before calling

list_open_design_skills

with

remixableOnly: true

if a quick skim already answers the question.

If the user wants a brand/style that isn't one of the ~150 bundled design systems ("use our own brand colors", "match our website", "set up a custom design system for..."), call

create_open_design_design_system

with a

name

, a

brief

describing the brand, and an optional

sourceUrl

if they gave you a website to match. It returns

instructions

for writing a new

DESIGN.md

yourself (same file shape as every bundled design system) plus, when a

sourceUrl

was given, a best-effort extracted starting palette/font list to incorporate — treat that as a rough starting point, not ground truth. It does NOT write any files. After writing the file, call

set_active_design_system

with the returned

id

— there's no separate "register" step for design systems; a written

DESIGN.md

is immediately selectable, the same way generated artifacts are immediately visible once written.

Once the user is happy with a generated or refined artifact and wants it turned into real, working code in this app ("turn this into a real component", "add this to the app", "wire this into my codebase"), call

port_open_design_artifact_to_app

with the artifact's

entryPath

. It returns

instructions

for reproducing the artifact's design as idiomatic code in this project's actual application — read the returned instructions carefully: they'll tell you to find and follow a real existing component in this codebase as your pattern reference (its styling approach, conventions, file organization) rather than copying the artifact's HTML/CSS verbatim, and to leave routing/navigation wiring as a separate step for the user. It does NOT write any files itself.

Working with Impeccable. After porting, if a skill named

impeccable

is in your own skill list, end your reply with one suggestion: run

/impeccable polish

(or

/impeccable audit

) on the component you just wrote. Say nothing about Impeccable when you don't have that skill. In a code project, once you've set a design system there and the project has no

DESIGN.md

, you may offer once to save it as the project's

DESIGN.md

so other tools can read it; when the user agrees, call

set_active_design_system

again with

writeProjectDesignMd: true

(it never overwrites an existing file).

When the user wants reusable components rather than one page in the app ("make Material 3 components for my React app from this", "a component library from this design", "an MUI / shadcn set for these screens"), call

prepare_open_design_component_library

instead, with the artifact's

entryPaths

(or the

collectionId

for every screen) and

library

mui

shadcn

auto

. Follow its stages in order: write the

components.md

inventory and stop for the user's yes before any code, use the generated theme as is, wrap the library's own components, add the gallery, run the app's type check, then call the tool again with

record

. It writes no app code itself. "Material 3" means

mui

When the artifact is meant to be posted or uploaded as an image (an X/Twitter post, Instagram or LinkedIn image, Xiaohongshu cards, a YouTube thumbnail, a poster), call

export_open_design_artifact

with its

entryPath

after registering it. It renders the artifact in a headless browser and writes PNG/JPEG file(s) under the artifact's own

exports/

folder, sized from the source skill automatically unless you pass

width

height

. For multi-card designs, give each card a

data-od-card

attribute and pass

selector: "[data-od-card]"

to get one numbered image per card. Pass

maxBytes

with the platform's upload limit (X 5000000, YouTube thumbnail 2000000, Instagram 8000000). Tell the user the exported file paths. For any social-post request ("make an X post…", "an Instagram carousel…", "a YouTube thumbnail…"), load the

open-design-social-post

skill first. It maps each platform and format to the right canvas size, skillId and export arguments (and asks the user which platform when that's unclear), then walks through generate → register → export. Animated designs (motion frames, title cards, animated charts, sprite or WebGL animations) export as video or GIF: call

export_open_design_artifact

with

format: "mp4"

"webm"

"gif"

. Time runs on a virtual clock, so the frames are exact and the same on every run; the length comes from the page (

data-duration

frames or the longest animation) unless you pass

duration

. Before exporting, call

check_open_design_artifact

with

at

(e.g.

[0, 1.5, 3]

) to see the start, middle and end. Export needs an installed ffmpeg: if it reports

no-ffmpeg

ffmpeg-missing-encoder

, tell the user what to install rather than trying another way. Compositions built with the HyperFrames framework are the exception: the brief's own instructions render them with the HyperFrames CLI. After registering a slide deck, offer to export it as PowerPoint or PDF, and when the user wants that, call

export_open_design_artifact

with

format: "pptx"

"pdf"

(one full-bleed image per slide: exact, but not editable). When the user wants slides they can edit (in PowerPoint, Keynote, Google Slides or Canva), add

editable: true

to the

pptx

export: text boxes, shapes and pictures they can change, close to the deck but not identical, with gradients, SVG diagrams and effects kept as a background picture. Tell them what the result lists as staying a picture and which fonts they need installed. Never write your own conversion script for this.

format: "pdf"

on an ordinary page prints it as a vector PDF.

For a diagram of a system — architecture, dependencies, a request flow, a database schema (ERD), a state machine or a sequence of calls ("diagram how our services talk", "draw the schema", "how does checkout work?") — use the

diagram

skill (

od:prototype:diagram

, or remix its example

od:prototype:diagram:example

). Read the relevant code first and draw only what you read. Write nodes with

data-rank

data-lane

and hidden links, never coordinates, then call

add_open_design_diagram_runtime

(it inserts the layout runtime; never write that script yourself), register with kind

diagram

and the files you read as

sources

, and check it. When a later check or

get_open_design_artifact

reports that its sources changed, offer to redraw it.

For a 3D object — a product shot, a 3D logo, a turntable, or the user's own

.glb

.gltf

model ("make a 3D render of our bottle", "turn the logo into 3D", "a product shot of models/headphones.glb") — use the

3d-object

skill (

od:prototype:3d-object

). It's one three.js scene with studio lighting, materials from the design system's tokens, a ground shadow and a turntable. Load three.js exactly as the skill says (its import map for the pinned

three@0.160.0

module build): older

three.min.js

and

examples/js

script tags no longer exist and leave the page blank. Copy a user's model under

assets/

next to the design and load it with

GLTFLoader

, framing the camera from its bounding box. The page must expose

window.odScene

(

ready

, resolved after a direct render once everything has loaded, and

rotate

); exports and checks turn on software WebGL and wait for it. Fix

webgl

findings before exporting. For a cut-out to place on slides or pages, export

format: "png"

with

transparent: true

from a scene with no background; for a turntable,

format: "mp4"

"gif"

with

duration

equal to one rotation.

For an HTML email (newsletter, launch or product-update email), use the

email-campaign

skill: it builds a table-based, inbox-safe email marked

data-od-email

. Check it, then export with

export_open_design_artifact

and

format: "email"

(add

baseUrl

once the user has hosted the

assets/

folder, so image URLs become absolute), and tell the user to send themselves a test before sending to a list. When the user wants a design pasted into another editor (a WeChat Official Account article, a Notion page, a newsletter tool), export with

format: "paste"

and

target

wechat

notion

newsletter

generic

; styles are inlined from what the browser rendered. To use either file, the user opens it in a browser, selects all and copies.

For a campaign (one message across several channels or sizes, ad banners in several sizes, or the same creative in several languages), load the

open-design-campaign

skill first: agree a copy deck saved as a CSV, build one fluid master bound to it with

data-od-field

(headline and subhead marked

data-od-fit

for long translations), check every chosen shape per row, and export with

presets

data

and

campaignSheet: true

For a poster, flyer, certificate or other print piece, or when the user wants an existing design in other sizes or as a print-ready PDF, load the

open-design-poster

skill first. In short: ask print or screen and which size if unclear; pass that canvas

format

(e.g.

a3

a2

ig-portrait

story

) with

fluid: true

prepare_open_design_brief

and the same

format

register_open_design_artifact

(a fluid poster reflows to any shape, so the size can change later); make any QR code with

create_open_design_qr_code

(never draw a fake one); run

check_open_design_artifact

and fix every preflight error; then export with

preset

set to the format id (print formats give a PDF with bleed, trim and bleed boxes).

presets

exports several shapes at once and

shapeSheet: true

shows them all in one image;

adapt_open_design_artifact

tunes a shape that looks wrong (in place, for fluid posters), and

data

on the export makes one file per row of the user's spreadsheet. Print PDFs are RGB: say so.

When the user wants to share a design with people who don't have this project open: for a link ("publish this", "deploy it", "give me a link to send the team", "host it somewhere"), call

publish_open_design_artifact

with its

entryPath

(pass

provider

only if they already said where; otherwise it returns the choices to show them). It builds a deploy-ready folder and returns step-by-step instructions to run with your terminal under the user's own CLI login, or as a temporary no-account link. Follow them exactly: they stop for the user's explicit yes before anything goes online, and after a successful deploy you call the tool again with

published

to record the link. For a single file to attach or send ("export it as one HTML file"), call

export_open_design_artifact

with

format: "standalone"

instead; nothing goes online. The

open-design-publish

skill walks through the whole flow.

For Figma: to turn a frame into code, call

pull_open_design_figma_frame

with the frame link ("Copy link to selection"); to put a finished design into Figma as editable layers, call

push_open_design_artifact_to_figma

with its

entryPath

. Both work through the user's Figma connection, and fall back to the Figma import plugin.

When a step would hand work to another service (import into Canva, read or push a Figma frame, save to Google Drive, write a Notion page, share in Slack, or post to a social network), call

list_open_design_integrations

first with the

capability

(plus

platform

for a social post). Then:

Check your own tools for one matching the returned patterns, including deferred or on-demand tools you can search for. If one is there, use it, calling its tools by their server-defined names (e.g. Canva's
```
import-design-from-url
```
).
If none is, offer to set up the first provider, once per conversation and only when the step needs it: say what it does and what sign-in it needs. Only after the user says yes, follow the returned setup steps (user-level configuration only). Never install silently, and never ask for an API key or write one into a file: the user sets it themselves.
Help the user sign in and reload if needed, then confirm by listing your tools.
If the user declines or setup fails, carry on with the workflow's manual path.

Anything that publishes, sends or posts on the user's account still needs their go-ahead first.

Help

When the user asks how something works, or a tool reports an error, point them to the relevant page:

Documentation index: https://github.com/feimacode/open-design-agent-kit/blob/main/docs/README.md
Troubleshooting (export errors, missing browser or FFmpeg, blank slides, MCP connection): https://github.com/feimacode/open-design-agent-kit/blob/main/docs/troubleshooting.md
Exploring design directions: https://github.com/feimacode/open-design-agent-kit/blob/main/docs/guides/explore-directions.md
Turning a document into a deck: https://github.com/feimacode/open-design-agent-kit/blob/main/docs/guides/deck-from-a-document.md
Sharing and publishing: https://github.com/feimacode/open-design-agent-kit/blob/main/docs/guides/share-and-publish.md
Connecting Canva, Figma, Notion, Google Drive, Slack or a posting service: https://github.com/feimacode/open-design-agent-kit/blob/main/docs/guides/integrations.md
Social media posts: https://github.com/feimacode/open-design-agent-kit/blob/main/docs/guides/social-posts.md
Posters and print: https://github.com/feimacode/open-design-agent-kit/blob/main/docs/guides/posters.md
Export images: https://github.com/feimacode/open-design-agent-kit/blob/main/docs/guides/export-images.md · Export decks and PDFs: https://github.com/feimacode/open-design-agent-kit/blob/main/docs/guides/export-decks.md
Tools reference: https://github.com/feimacode/open-design-agent-kit/blob/main/docs/reference/tools.md

open-design

NPX Install

Tags

SKILL.md Content

Help