@feimacode/open-design-agent-kit 0.1.8 → 0.3.0-beta.3

package/README.md

@@ -85,13 +85,14 @@ Once `init` has run, just talk to your agent — no further CLI commands needed.
 
 The agent picks a matching skill and produces a real design, saved into your project as plain HTML/JSX/CSS you can keep editing.
 
-### 3. Export or render from a script (optional)
+### 3. Export, check or render from a script (optional)
 
-Once an artifact exists, export it to an image, PDF, or PowerPoint, or render a HyperFrames composition to video — no agent needed:
+Once an artifact exists, export it (image, PDF, PowerPoint, animation, standalone HTML…), check how it renders, or render a HyperFrames composition to video — no agent needed:
 
 ```bash
 npx @feimacode/open-design-agent-kit export .open-design/launch/launch.html --max-bytes 5000000
 npx @feimacode/open-design-agent-kit export .open-design/pitch/pitch.html --format pptx
+npx @feimacode/open-design-agent-kit check .open-design/landing/landing.html --fail-on error
 npx @feimacode/open-design-agent-kit render-video .open-design/promo --output .open-design/promo/exports/promo.mp4
 ```
 

package/assets/claude-skills/open-design/SKILL.md

@@ -17,16 +17,60 @@ Follow this flow:
    - **Claude Code:** run `npx @feimacode/open-design-agent-kit init --tools claude` in the project root, or `claude mcp add open-design -- npx -y @feimacode/open-design-agent-kit-mcp`.
    - **Codex CLI:** run `npx @feimacode/open-design-agent-kit init --tools codex` in the project root.
    - **Any other MCP-capable agent** (Cursor, etc.): register `npx -y @feimacode/open-design-agent-kit-mcp` as a stdio MCP server using this agent's own MCP config mechanism.
+   - **Claude Desktop Chat or claude.ai** (no Open Design tools in the chat): don't make anything yet. Tell the user what's missing: connect a folder to the chat (Claude Desktop, with the Open Design plugin installed), or install the Open Design desktop extension (`open-design-<version>.mcpb` from the project's GitHub releases) to use it in Claude Desktop without a folder. Only if they want to go ahead anyway, make one self-contained HTML page and publish it with your own Artifact tool, and say it skips Open Design's design systems, checks and exports.
 
    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. If a tool says it would be working in the home folder, this is what it's asking for.
+
+   **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 the folder's absolute path from its result (under `~/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` after each round; 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.
 1. 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.
-2. 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. If the user hasn't mentioned any direction, just omit `designSystemId` from `prepare_open_design_brief` and it will silently use whatever is currently active (or none). 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").
+2. 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, just omit `designSystemId` from `prepare_open_design_brief` and it will silently use whatever is currently active (or none). 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").
 3. 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.
 4. 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.
 5. 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.
-6. Optionally call `get_open_design_artifact` to confirm what was written before telling the user it's done.
+6. 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. Re-check after fixing, but stop after two fix rounds and tell the user about anything left. **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. 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.
+7. Optionally call `get_open_design_artifact` to confirm what was written before telling the user it's done.
+8. 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 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 after every `register_open_design_artifact`, including after applying comments, since the inline page doesn't reload by itself. 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`.
+
+<!-- claude-only -->
+**The artifact preview (Claude Code and Claude Desktop).** If you have an Artifact tool, keep one private Claude artifact per design as the user's preview, so they can look at it on claude.ai without opening files:
+- Publish it with `publish_open_design_artifact` and `provider: "claude-artifact"`, and follow what it returns: publish the file by its path, then record the link. Later publishes go to the recorded link, so the same artifact gets a new version and an open tab shows it.
+- Publish after the first successful registration and check of a design, and after each round of the user's feedback you've applied, not after every small edit. For an exploration, wait until the user picks a direction, then preview what you build from it.
+- Give the link the first time; after that, just say the preview was updated. `get_open_design_artifact` returns it as `previewUrl`.
+- Take feedback in chat. When the user wants to share, they share this same artifact from claude.ai: don't make a second one.
+- It's private, so it needs no confirmation and carries no badge. Without an Artifact tool, skip all of this.
+
+**Sync to continue elsewhere (Claude Code and Claude Desktop).** The preview artifact can also carry the design's working files (entry, manifest, comments, supporting files), so the design can be picked up on another device, in a new cloud session, or in a chat without this folder:
+- When the user says they'll continue somewhere else (their laptop, another session, a chat without the folder), offer sync once. Turn it on only after they agree: publish the preview with `sync: true`. Later preview publishes keep it up to date without asking; `sync: false` turns it off. Pass on what the instructions tell you to say: anyone they share the artifact with can read the files, and earlier versions keep their copy.
+- **Picking a design back up:** when the user gives a Claude artifact link for a design that isn't here, read the artifact with your Artifact tool (it saves the page to a file), then call `restore_open_design_artifact` with that file's path and the link. In Claude Desktop with a folder, save or copy the page into the connected folder and pass that path, as for other kit paths. If it lists files that differ from the local ones, ask which to keep before calling again with `overwrite: true`. Then carry on as usual: the next preview publish updates the same artifact.
+- **Without Open Design's tools** (a chat where you have an Artifact tool but none of the `*_open_design_*` tools): to change a synced design, read the artifact and find its `<script type="application/od-sync+json">` block. Take the text of the file named by its `entry` from `files`, edit it, and publish to the same artifact URL a page made of the edited entry followed by the block, with that file's `content` replaced by the edited text and its `sha256` set to `null`. Leave the rest of the block as it is, and keep every `</` inside it written as `<\/`. A later restore reports the file as edited outside the kit. A page published without the block holds only the preview, with nothing to edit.
+<!-- /claude-only -->
+
+When a request names a **kind of thing to make** (a prototype or landing page, 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, ask only the surface's questions the request doesn't answer, and follow the surface's prompt when it names one. 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`, `gh pr view` when available) 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` to `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.
+1. 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.
+2. 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`.
+3. 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.
+4. 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.
+5. 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. This host has no live preview editor — after registering an artifact, just tell the user where it was written; there is nothing further to open automatically.
+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, then call `show_open_design_artifact` again so the user sees the result.
 
 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 have a non-empty `exampleArtifactPath`) 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](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.
 
@@ -34,7 +78,33 @@ If the user wants a brand/style that isn't one of the ~150 bundled design system
 
 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.
 
-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. Videos (HyperFrames) aren't exported with this tool: the brief's own instructions say how to render them to MP4 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"` or `"pdf"` (one full-bleed image per slide; not editable text). `format: "pdf"` on an ordinary page prints it as a vector PDF.
+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"` or `"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` or `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"` or `"pdf"` (one full-bleed image per slide; not editable text). `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"` or `"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` or `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` to `prepare_open_design_brief` and the same `format` to `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.
+
+<!-- claude-only -->
+If you have an Artifact tool (Claude Code or Claude Desktop), offer a Claude artifact first: `provider: "claude-artifact"` returns one file to publish by its path with your Artifact tool, private to the user until they share it from claude.ai, so there's no confirmation step; record its link the same way. PNG, PDF and PowerPoint exports stay files on disk.
+<!-- /claude-only -->
+
+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 a token or the 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:
+1. 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`).
+2. 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.
+3. Help the user sign in and reload if needed, then confirm by listing your tools.
+4. 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
 
@@ -42,6 +112,11 @@ When the user asks how something works, or a tool reports an error, point them t
 
 - 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

package/assets/claude-skills/open-design/references/remixable-examples.md

@@ -1,12 +1,18 @@
 # Remixable Open Design examples
 
-167 vendored examples have an actual rendered starting artifact you can copy into the workspace and modify, via `remix_open_design_example` with the `id` shown below as `skillId`, instead of generating from scratch with `prepare_open_design_brief`.
+193 vendored examples have an actual rendered starting artifact you can copy into the workspace and modify, via `remix_open_design_example` with the `id` shown below as `skillId`, instead of generating from scratch with `prepare_open_design_brief`.
 
 ## prototype
 
+- **od:prototype:adr:example** — ADR-0007: Lay diagrams out in the browser: An example of the adr skill: ADR-0007: Lay diagrams out in the browser.
 - **od:prototype:blog-post:example** — blog-post: A long-form article / blog post — masthead, hero image placeholder, article body with figures and pull quotes, author byline, related posts. Use when the brief asks for "blog", "article", "post", "essay", or "case study".
 - **od:prototype:clinical-case-report:example** — clinical-case-report: Structured medical case presentation for clinical rounds, conferences, and documentation. Generates SOAP-format or narrative case reports with physiologically accurate vitals, labs, and evidence-based plans. Use when the brief mentions "case report", "case presentation", "SOAP note", "clinical case", "ward rounds", "case summary", or "patient presentation".
 - **od:prototype:codex-interactive-capability-map** — Codex Interactive Capability Map: Turn a long-form article, thread, memo, or product narrative into a compact clickable capability map with a workflow loop, use-case matrix, and responsive detail panel.
+- **od:prototype:competitive-teardown:example** — Competitive Teardown: Positioning map, feature matrix, pricing comparison and opportunity windows: turns competitor research into a product decision report.
+- **od:prototype:competitive-teardown-analyst-dossier** — Competitive Teardown — analyst dossier style: Positioning map, feature matrix, pricing comparison and opportunity windows: turns competitor research into a product decision report. The analyst dossier style variant.
+- **od:prototype:competitive-teardown-radar-map** — Competitive Teardown — radar map style: Positioning map, feature matrix, pricing comparison and opportunity windows: turns competitor research into a product decision report. The radar map style variant.
+- **od:prototype:competitive-teardown-war-room-grid** — Competitive Teardown — war room grid style: Positioning map, feature matrix, pricing comparison and opportunity windows: turns competitor research into a product decision report. The war room grid style variant.
+- **od:prototype:3d-scene:example** — Courtyard at dusk — 3D scene: A small stone courtyard at dusk built from a scene spec: a Poly Haven sky, cobblestone and stone-wall textures, a brass lantern and two wooden planters (all CC0), with a 10-second camera flythrough.
 - **od:prototype:critique:example** — critique: Run a 5-dimension expert design review on any HTML artifact in the project — Philosophy / Visual hierarchy / Detail / Functionality / Innovation, each scored 0–10. Outputs a single self-contained HTML report with a radar chart, evidence-backed scores, and three lists: Keep / Fix / Quick-wins. Use when the brief asks for a "design review", "design critique", "5 维度评审", "design audit", or "what's wrong with my design".
 - **od:prototype:dashboard:example** — dashboard: Admin / analytics dashboard in a single HTML file. Fixed left sidebar, top bar with user/search, main grid of KPI cards and one or two charts. Use when the brief asks for a "dashboard", "admin", "analytics", or "control panel" screen.
 - **od:prototype:data-report:example** — Data Visualization Report: Turns CSV, Excel, or JSON data into a polished visual report page.
@@ -14,12 +20,24 @@
 - **od:prototype:mockup-device-3d:example** — Device 3D Showcase: Static iPhone and MacBook 3D-style showcase with real HTML embedded on screens, glass-lens refraction, and 360-degree turntable composition.
 - **od:prototype:digital-eguide:example** — digital-eguide: A two-spread digital e-guide preview — page 1 is a cover (display title, author, "What's inside" stats, table of contents teaser); page 2 is a spread (lesson body with pull-quote and a step list). Lifestyle / creator brand tone. Use when the brief asks for an "e-guide", "digital guide", "lookbook", "lead magnet", "creator guide", "playbook", "PDF guide", or "电子指南".
 - **od:prototype:docs-page:example** — docs-page: A documentation page — inline-start nav, scrollable article body, inline-end table of contents. Use when the brief mentions "docs", "documentation", "guide", "API reference", or "tutorial".
+- **od:prototype:article-sketchnote-editorial:example** — Editorial Sketchnote: Turns one concept into a magazine-style feature dossier — the real question, early failures, the turning point, the insight and its name — across six layout moulds.
 - **od:prototype:email-marketing:example** — email-marketing: A brand product-launch email — masthead with wordmark, hero image block, headline lockup with skewed-italic accent, body copy, primary CTA, and a specifications grid. Pure HTML email layout (centered single column, table fallback). Use when the brief asks for an "email", "newsletter blast", "MJML", "product launch email", or "email template".
 - **od:prototype:eng-runbook:example** — eng-runbook: An engineering runbook — service overview, alerts table, dashboards links, common procedures with copy-pasteable commands, on-call rotation, and an incident-response checklist. Use when the brief mentions "runbook", "ops doc", "on-call guide", "SRE doc", or "运维手册".
+- **od:prototype:exec-briefing-memo:example** — Executive Briefing Memo: A one-page decision memo: the decision needed, a clear recommendation with confidence, key facts, tradeoffs, risks and next actions — compressed so a decision-maker can sign off in three minutes.
+- **od:prototype:exec-briefing-memo-board-memo** — Executive Briefing Memo — board memo style: A one-page decision memo: the decision needed, a clear recommendation with confidence, key facts, tradeoffs, risks and next actions — compressed so a decision-maker can sign off in three minutes. The board memo style variant.
+- **od:prototype:exec-briefing-memo-board-paper** — Executive Briefing Memo — board paper style: A one-page decision memo: the decision needed, a clear recommendation with confidence, key facts, tradeoffs, risks and next actions — compressed so a decision-maker can sign off in three minutes. The board paper style variant.
+- **od:prototype:exec-briefing-memo-decision-command** — Executive Briefing Memo — decision command style: A one-page decision memo: the decision needed, a clear recommendation with confidence, key facts, tradeoffs, risks and next actions — compressed so a decision-maker can sign off in three minutes. The decision command style variant.
+- **od:prototype:experiment-readout:example** — Experiment Readout: Hypothesis, metrics, results, interpretation and decision: turns an A/B test or product experiment into a ship / stop / iterate recommendation.
+- **od:prototype:experiment-readout-growth-console** — Experiment Readout — growth console style: Hypothesis, metrics, results, interpretation and decision: turns an A/B test or product experiment into a ship / stop / iterate recommendation. The growth console style variant.
+- **od:prototype:experiment-readout-lab-notebook** — Experiment Readout — lab notebook style: Hypothesis, metrics, results, interpretation and decision: turns an A/B test or product experiment into a ship / stop / iterate recommendation. The lab notebook style variant.
+- **od:prototype:experiment-readout-product-readout** — Experiment Readout — product readout style: Hypothesis, metrics, results, interpretation and decision: turns an A/B test or product experiment into a ship / stop / iterate recommendation. The product readout style variant.
+- **od:prototype:3d-object-glb** — Field bottle — product shot from a GLB: A product model loaded from a .glb, centered and framed automatically, with a soft ground shadow. The user's model variant.
 - **od:prototype:finance-report:example** — finance-report: Quarterly / monthly financial report — masthead with KPIs, revenue and burn charts, P&L summary table, top-line highlights, and an outlook paragraph. Use when the brief mentions "financial report", "Q3 report", "MRR review", "P&L", or "财报".
 - **od:prototype:flowai-live-dashboard-template:example** — flowai-live-dashboard-template: Team-management dashboard skill in the FlowAI aesthetic — three tabs (Team Members, Team Details, Activity Log), KPI stat row, member table, role distribution bar chart, online presence and activity sparklines, and a top-contributors panel, all in a single self-contained HTML file with light/dark theming, hoverable chart tooltips, click-to-zoom panels, and CSV export. Use when the brief asks for a team / workspace admin dashboard, an interactive admin dashboard with charts, or names FlowAI.
+- **od:prototype:info-funnel:example** — Funnel Infographic: A 3–6 stage narrowing funnel that makes conversion rates, drop-off and filtering ratios obvious; vertical, sized for Stories and Xiaohongshu.
 - **od:prototype:gamified-app:example** — gamified-app: A multi-frame gamified mobile-app prototype — three phone frames on a dark showcase stage. Frame 1: cover / poster, Frame 2: today's quests with XP ribbons and a level bar, Frame 3: quest detail. Vivid quest tiles, level ribbon, bottom tab bar. Use when the brief asks for a "gamified app", "habit tracker", "RPG-style life app", "level-up app", "daily quests", "XP / streak app", or "ELI5-style explainer app".
 - **od:prototype:github-dashboard:example** — github-dashboard: GitHub repository analytics dashboard — stars, forks, contributors, issues, pull requests, recent activity, and top contributors. Use when the brief asks for a GitHub repo dashboard, open-source growth report, repository health page, or GitHub analytics view.
+- **od:prototype:3d-object:example** — Halo speaker — 3D product shot: A procedural speaker built from a lathe profile, in studio light on a turntable, colored from the design tokens.
 - **od:prototype:hr-onboarding:example** — hr-onboarding: A new-hire onboarding plan as a single page — first week schedule, buddy + manager intro, learning track, equipment checklist, and "you're set when…" outcomes. Use when the brief mentions "onboarding", "new hire", "first week plan", or "入职".
 - **od:prototype:invoice:example** — invoice: A printable invoice page — sender + recipient block, line items table, tax breakdown, totals, and payment instructions. Use when the brief mentions "invoice", "bill", "billing statement", or "发票".
 - **od:prototype:doc-kami-parchment:example** — Kami Parchment Document: Warm parchment canvas (#f5f4ed), monochrome ink-blue accent (#1B365D), one serif family, and editorial-grade typography.
@@ -34,15 +52,22 @@
 - **od:prototype:mobile-onboarding:example** — mobile-onboarding: A multi-screen mobile onboarding flow rendered as three phone frames side by side — splash, value-prop, sign-in. Status bar, swipe dots, primary CTA. Use when the brief mentions "mobile onboarding", "iOS onboarding", "phone signup", or "移动端引导".
 - **od:prototype:resume-modern:example** — Modern Resume: Modern minimal resume, single A4 page, ready for print or PDF export.
 - **od:prototype:motion-frames:example** — motion-frames: A single-frame motion-design composition with looping CSS animations — rotating type ring, animated globe, ticking timer, parallax labels. Renders as a hero video poster you can hand straight to HyperFrames or any keyframe-based exporter. Use when the brief asks for "motion design", "animated hero", "loop", "video poster", "title card", or pairs Open Claude Design with HyperFrames for a kinetic export.
+- **od:prototype:3d-object-logo** — Northwind mark — 3D logo: The brand's SVG mark extruded and bevelled in brushed gold, turning slowly. The extruded logo variant.
+- **od:prototype:changelog-page:example** — Open Design Agent Kit changelog: An example of the changelog-page skill: Changelog: Open Design Agent Kit.
 - **od:prototype:orbit-general:example** — orbit-general: Open Orbit briefing skill — selected by the Orbit pipeline when the user has two or more connectors connected. Pulls the past 24 hours of activity from every authenticated connector (GitHub, Linear, Notion, Slack, 飞书, Calendar, Gmail, Drive, Sentry, Vercel, …) and renders a single adaptive bento-grid dashboard at the top of "我的设计". Each connector module picks its own UI form (list, avatar stack, status ring, heatmap, file grid, alert card, …) based on the data shape it returns, so the layout scales as Orbit's connector ecosystem grows. This skill should not be triggered manually — it is invoked by Orbit's daily-digest scheduler against the user's live connector data.
 - **od:prototype:orbit-github:example** — orbit-github: Open Orbit briefing skill — selected by the Orbit pipeline when GitHub is the user's only connected connector, or when the user explicitly scopes their daily digest to GitHub. Pulls the past 24 hours of PRs, review requests, issues, CI runs, and merges from the user's authenticated GitHub connection and renders them in a layout that mirrors GitHub's native Notifications + PR-diff visual language. This skill should not be triggered manually — it is invoked by Orbit's daily-digest scheduler against live GitHub data.
 - **od:prototype:orbit-gmail:example** — orbit-gmail: Open Orbit briefing skill — selected by the Orbit pipeline when Gmail is the user's only connected connector, or when the user explicitly scopes their daily digest to Gmail. Pulls the past 24 hours of inbox activity (replies awaited, mentions, cc, auto- categorized bulk) from the user's authenticated Gmail connection and renders the digest as the Orbit Daily Digest email opened inside Gmail's reading view. This skill should not be triggered manually — it is invoked by Orbit's daily-digest scheduler against live Gmail data.
 - **od:prototype:orbit-linear:example** — orbit-linear: Open Orbit briefing skill — selected by the Orbit pipeline when Linear is the user's only connected connector, or when the user explicitly scopes their daily digest to Linear. Pulls the past 24 hours of issue movement, status changes, assignments, and cycle progress from the user's authenticated Linear connection and renders the digest in Linear's native Inbox + cycle-progress visual language. This skill should not be triggered manually — it is invoked by Orbit's daily-digest scheduler against live Linear data.
 - **od:prototype:orbit-notion:example** — orbit-notion: Open Orbit briefing skill — selected by the Orbit pipeline when Notion is the user's only connected connector, or when the user explicitly scopes their daily digest to Notion. Pulls the past 24 hours of document edits, comments, mentions, and database row changes from the user's authenticated Notion connection and renders the digest as a native Notion page (callout / toggle / database table primitives). This skill should not be triggered manually — it is invoked by Orbit's daily-digest scheduler against live Notion data.
+- **od:prototype:diagram:example** — Package architecture diagram: Architecture diagram of a monorepo's packages: shared foundations, the hosts built on them, runtime dependencies versus build-time copies, with each node linked to its package.json.
 - **od:prototype:pm-spec:example** — pm-spec: Product spec / PRD as a single page — problem, success metrics, scope, user stories, design notes, rollout plan, open questions. Use when the brief mentions "PRD", "spec", "product spec", "feature brief", or "需求文档".
+- **od:prototype:pr-explainer:example** — PR explainer: add campaign export functionality: An example of the pr-explainer skill: PR explainer: campaign kit.
 - **od:prototype:pricing-page:example** — pricing-page: A standalone pricing page — header, plan tiers, feature comparison table, and an FAQ. Use when the brief asks for "pricing", "plans", "subscription tiers", or a "compare plans" page.
+- **od:prototype:email-campaign:example** — Product launch email: A product launch email that renders in Gmail, Outlook and Apple Mail: table layout, three benefit rows, a bulletproof button and a compliant footer.
 - **od:prototype:social-reddit-card:example** — Reddit Post Card: Realistic Reddit post card with vote rail and comment count, suited to video overlays or story sharing.
+- **od:prototype:rfc:example** — RFC-012: Let the agent see what it built: An example of the rfc skill: Let the agent see what it built.
 - **od:prototype:saas-landing:example** — saas-landing: Single-page SaaS landing with hero, features, social proof, pricing, and CTA. Respects the active DESIGN.md color/typography/layout tokens. Trigger keywords: "saas landing", "marketing page", "product landing".
+- **od:prototype:postmortem:example** — Sample postmortem: exports hung on a confined browser: An example of the postmortem skill: Sample postmortem: exports hung on a confined browser.
 - **od:prototype:social-carousel:example** — social-carousel: A three-card social-media carousel laid out as 1080×1080 squares — three cinematic, on-brand panels with display headlines that connect across the series ("onwards." → "to the next one." → "looking ahead."). Each card has a brand mark, a number / total, a caption, and a "loop" affordance. Use when the brief asks for a "carousel post", "social carousel", "Instagram carousel", "LinkedIn series", "X thread cards", or "三连发".
 - **od:prototype:social-media-dashboard:example** — social-media-dashboard: Creator-facing social media analytics dashboard in a single HTML file. A platform switcher (X / LinkedIn / YouTube / Instagram), a row of KPI cards (followers, engagement rate, likes, reposts), a follower-growth chart, a "top post this week" preview, and a trending topics / top comments side panel. Use when the brief mentions a "social media dashboard", "creator analytics", "social analytics", or names specific platforms (X, Twitter, LinkedIn, YouTube, Instagram, TikTok) together with metrics like followers, engagement, likes, reposts.
 - **od:prototype:social-spotify-card:example** — Spotify Now-Playing Card: Spotify Now Playing-style card with album art, progress bar, and playback controls, suited to video overlays or personal homepages.
@@ -156,6 +181,10 @@
 - **od:deck:simple-deck:example** — Write an Operating Review like a Disciplined COO: OpenDesign's operating review: growth, burn, and the concrete path to sustainability without losing the open ethos. Built as a decision-grade corporate strategy deck for leadership team.
 - **od:deck:html-ppt-zhangzara-grove:example** — Write an Urban Green-Space Policy Brief like a City Sustainability Director: A municipal urban-tree-canopy policy proposal — the public need, the evidence, the options, and the funding decision. Built as a decision-grade policy briefing deck for city council, agency reviewers.
 
+## design-system
+
+- **od:design-system:style-tile:example** — Style tile: Harbor: A style tile for a calm fintech brand: cool neutrals, a deep harbor-blue accent, a serif display face with a geometric sans, soft radii.
+
 ## image
 
 - **od:image:image-poster:example** — image-poster: Single-image generation skill for posters, key art, and editorial illustrations. Defaults to gpt-image-2 but is provider-agnostic — the same workflow drives Flux, Imagen, or Midjourney via the active upstream tooling. Output is one or more PNG/JPEG files saved to the project folder.

package/assets/claude-skills/open-design-campaign/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: "open-design-campaign"
+description: Turn one brief into a whole campaign — one master design exported to every channel size (social, link previews, banners, display ads), plus an optional landing page and email, in every language you need, checked and shown on one campaign sheet — use whenever the user wants a campaign, a launch kit, assets for several channels or sizes at once, ad banners in several sizes, or the same creative in several languages, even if they don't mention Open Design
+argument-hint: what the campaign is for, and optionally the channels and languages (e.g. "launch of our reporting dashboard, Instagram + LinkedIn + display ads, English and German")
+---
+
+<!-- generated:curated-entry -->
+
+Build a campaign with Open Design: one message, one visual system, every channel.
+
+Brief: "$ARGUMENTS" — or, if that is empty, the user's request in this conversation (if it isn't clear, ask the user: "What is the campaign for, which channels, and which languages?")
+
+## 1. Agree the copy deck
+
+Before designing anything, agree the words with the user. Draft them from the brief and show them as a short table:
+
+- `headline` (≤ 6 words), `subhead` (one line), `cta` (2–4 words), and `legal` (one short line, if the brief needs one);
+- one row per language (`locale` column: `en`, `de`, `ja`…) or per audience, if the user wants several. Translate faithfully and keep each row's meaning identical.
+
+When the user is happy, save it as `copy.csv` in the campaign folder (`<output dir>/<campaign-slug>/copy.csv`), with a header row: `locale,headline,subhead,cta,legal`.
+
+## 2. Build one fluid master
+
+Call `prepare_open_design_brief` with `od:prototype:poster-hero` (or a better-fitting poster or social skill from `list_open_design_skills`), the brief, `format: "ig-portrait"` and `fluid: true`, plus `collectionId` (the campaign slug), `collectionName` and `screenRole: "master"`.
+
+Build it as the brief says, and also:
+
+- every piece of copy is an element with `data-od-field="<column>"` from the copy deck, holding the first row's text;
+- add `data-od-fit` to the headline and subhead, so long translations shrink (to at most 70%) instead of overflowing;
+- design the wide band (`@container (aspect-ratio > 1.2)`) and add a very wide band for banners (`@container (aspect-ratio > 3)`: headline and call to action side by side, everything else hidden with `data-od-priority`).
+
+Register it (`register_open_design_artifact` with the same `format`, `collectionId`, `collectionName` and `screenRole: "master"`).
+
+## 3. Pick channels
+
+Ask which channels the campaign needs, unless the brief says. Offer this menu (format ids in brackets):
+
+| Channel | Formats |
+|---|---|
+| Instagram / Facebook feed | `ig-portrait`, `ig-square` |
+| Stories, Reels, TikTok | `story` |
+| X | `x-image`, `x-header` |
+| LinkedIn | `linkedin-image`, `linkedin-banner` |
+| Link previews (website, Slack) | `og-image` |
+| Display ads (150 KB each) | `banner-mrec`, `banner-leaderboard`, `banner-skyscraper`, `banner-mobile` |
+| Email header | `email-header` |
+| Print | `a4`, `a3`, `letter`… |
+
+## 4. Check every shape
+
+Call `export_open_design_artifact` with `presets` set to the chosen formats, `data: "<campaign folder>/copy.csv"`, `nameField: "locale"` and `checkOnly: true`. Fix every **error** in the findings (per shape and per row). For a shape that looks wrong or has errors, call `adapt_open_design_artifact` with those format ids and tune it in the same file. Tiny ad sizes usually need their own `@container` rule: headline and call to action only. Repeat until there are no errors.
+
+<!-- claude-only -->
+**Artifact preview.** If you have an Artifact tool, publish this design as its private artifact preview (the master) once every shape is clean: call `publish_open_design_artifact` with `provider: "claude-artifact"` and follow what it returns. Publish again after each round of feedback you apply; it goes to the same artifact. Give the link once, then just say the preview was updated.
+<!-- /claude-only -->
+
+## 5. Other pieces (optional)
+
+If the user wants a landing page or an email, build each with its own skill (`od:prototype:saas-landing` or `od:prototype:web-prototype`, and `od:prototype:email-campaign`) using the same design system and the first row of the copy deck. Register each with the same `collectionId` and `collectionName`, and `screenRole` `landing` or `email`. Check each with `check_open_design_artifact`.
+
+## 6. Export and show the sheet
+
+1. Export the master: `export_open_design_artifact` with the same `presets`, `data` and `nameField: "locale"`, plus `campaignSheet: true`. This writes one image (or print PDF) per shape per row, named `<name>-<locale>-<format>`, and `exports/campaign-sheet.png`, which shows every shape and every other piece, with a red dot on any that still has errors. If the export says the outputs are over the limit, export one batch of locales at a time.
+2. If there's an email, export it with `format: "email"` (and `baseUrl` once its images are hosted).
+3. Show the user the campaign sheet, list the files per channel, and mention anything still flagged. The export also writes `exports/campaign-sheet.json`, which lists each tile in sheet order with its errors.
+<!-- claude-only -->
+4. In Claude Desktop Chat, call `show_open_design_artifact` with the master's `entryPath` and `campaign: true`: the sheet shows inline tile by tile, with each tile's errors. A page-type piece opens when clicked, and "Fix this piece" posts the tile and its errors in the chat; fix that piece, export again with `campaignSheet: true`, and show the sheet again. If the result says the host doesn't show MCP Apps, just show `exports/campaign-sheet.png` as above.
+<!-- /claude-only -->

package/assets/claude-skills/open-design-deck-from-source/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: "open-design-deck-from-source"
+description: Turn a document (a report, spec, spreadsheet, PDF, existing deck, or repository files such as a CHANGELOG) into a deck or one-pager, storyline first, with every number traced back to the source — use whenever the user wants slides, a deck, a presentation or a one-pager made from an existing document, spreadsheet, PDF or deck, or from repository files (CHANGELOG, RFCs, architecture decision records, metrics CSVs), even if they don't mention Open Design
+argument-hint: which document(s), and what to make (e.g. "docs/q3-report.docx as a 10-slide board update")
+---
+
+<!-- generated:curated-entry -->
+
+Build a deck (or a one-pager) from existing documents with Open Design, storyline first, keeping every fact traceable to its source.
+
+Request: "$ARGUMENTS" — or, if that is empty, the user's request in this conversation (if it isn't clear, ask the user: "Which document should the deck be built from, and for whom?")
+
+## 1. Find the sources
+
+Identify the workspace files the request is based on. If it names none, ask which documents to use before doing anything else. Repository files count: `CHANGELOG.md` for a release deck, `docs/adr/*.md` for an architecture review, a metrics CSV or spreadsheet for a board update. Use up to 10 files; for a folder, pick the relevant files.
+
+If you're unsure what a document contains, call `read_open_design_source` with its path. It returns an outline, and you can read the extracted Markdown by line range.
+
+## 2. Pick the format
+
+Call `list_open_design_skills` with `mode: "deck"` (or a query such as "pitch deck", "weekly report", "board") and choose the skill whose style fits the audience. For a single page instead of slides, choose a page or report skill.
+
+## 3. Prepare the brief with sources
+
+Call `prepare_open_design_brief` with the `skillId`, the user's request as `brief`, and the document paths as `sources`. Pass `designSystemId` only if the user names a brand or style.
+
+## 4. Storyline first
+
+Follow the returned instructions. Read the parts of the extracted text you need, then write the outline at `outlinePath`, with one entry per slide giving a takeaway headline, supporting points, a visual type and a source reference. **Show the outline to the user and stop** until they approve or change it, unless they already said to just build it.
+
+## 5. Build and check
+
+Build from the approved outline. Use numbers, names and quotes exactly as in the sources, never invent a statistic, and put the detail you cut from each slide into its speaker notes, ending with a `Source:` line.
+
+Call `register_open_design_artifact` with the same `sources`. For every number its result says it couldn't find in the sources, check it: fix it, or say in that slide's notes how it was derived. Register again after fixing.
+
+<!-- claude-only -->
+**Artifact preview.** If you have an Artifact tool, publish this design as its private artifact preview once it's registered: call `publish_open_design_artifact` with `provider: "claude-artifact"` and follow what it returns. Publish again after each round of feedback you apply; it goes to the same artifact. Give the link once, then just say the preview was updated.
+<!-- /claude-only -->
+
+## 6. Hand it over
+
+Tell the user where the deck and its outline are, mention any images reused from the documents, and offer to export it as PowerPoint or PDF with `export_open_design_artifact`. PowerPoint exports include the speaker notes.

package/assets/claude-skills/open-design-docs/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: "open-design-docs"
+description: Turn a folder of Markdown documents (ADRs, RFCs, runbooks, notes) into designed HTML pages, one per file, all in one style, and keep them in step when the Markdown changes — use whenever the user wants several Markdown files (a docs folder, ADRs, RFCs, runbooks, meeting notes) turned into HTML pages, or wants HTML versions of existing docs refreshed after edits
+argument-hint: which files, and optionally the style (e.g. "docs/adr/*.md as ADR pages")
+---
+
+<!-- generated:curated-entry -->
+
+Turn existing Markdown documents into designed HTML pages with Open Design, one page per file.
+
+Request: "$ARGUMENTS" — or, if that is empty, the user's request in this conversation (if it isn't clear, ask the user: "Which Markdown files should become pages, and in what style?")
+
+## 1. Find the files
+
+Resolve the folder or glob in the request with your own file tools (for example `docs/adr/*.md`). List what you found.
+
+- More than 20 files: tell the user how many there are and ask whether to do all of them or a subset. Don't start until they answer.
+- No files: say so and stop.
+
+## 2. Pick one template for the set
+
+All pages in a set share one template, so they read as one collection. Choose by what the files are, or use the style the user named:
+
+| Files | Skill |
+|---|---|
+| Architecture decisions | `od:prototype:adr` |
+| Proposals, design docs | `od:prototype:rfc` |
+| Incident write-ups | `od:prototype:postmortem` |
+| Runbooks | `od:prototype:eng-runbook` |
+| Release notes or changelogs | `od:prototype:changelog-page` |
+| Long-form notes, essays, anything else | `od:prototype:doc-kami-parchment` |
+
+Derive a `collectionId` from the folder name (for example `docs-adr`) and a readable `collectionName`.
+
+## 3. On a re-run, only redo what changed
+
+If pages from an earlier run exist (look for artifacts in that collection, or call `get_open_design_artifact` on each), compare: a page whose `staleSources` lists its Markdown file is out of date and gets regenerated; a page that isn't stale is skipped; a file with no page yet gets one. Tell the user what you'll regenerate and what you'll skip.
+
+## 4. Build each page
+
+For each file, in order:
+
+1. Call `read_open_design_source` with the file. Use only what it returns: never add facts the Markdown doesn't have.
+2. Call `prepare_open_design_brief` with the chosen skill, a brief naming the file, `collectionId`, `collectionName`, and `screenRole` set to the file's name.
+3. Write the page, keeping the document's own headings, structure and status (for ADRs and RFCs, its status goes in the `data-od-status` banner). Link to sibling pages in the set where the Markdown links to the sibling `.md` file.
+4. Call `register_open_design_artifact` with the same collection values and `sources: ["<the .md path>"]`, so a later run can tell when the Markdown changed.
+
+Check the first page with `check_open_design_artifact` and fix its errors before doing the rest, so mistakes aren't copied into every page. Check the others at the end.
+
+## 5. Report
+
+List each page with its source file, and anything skipped or still flagged. In VS Code, mention the Collections view, where the whole set opens with Prev/Next.

package/assets/claude-skills/open-design-explore/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: "open-design-explore"
+description: Explore 2–4 deliberately different design directions for one brief, compare them side by side, then build out the one you pick — use whenever the user explicitly asks for several options, directions, alternatives or versions of a design to compare ("show me three directions for…", "a few different takes on…"), even if they don't mention Open Design; not for a single, ordinary design request
+argument-hint: what to design, and optionally how many directions or what should vary (e.g. "pricing page, 3 directions")
+---
+
+<!-- generated:curated-entry -->
+
+Explore several deliberately different design directions with Open Design, compare them side by side, and take the chosen one forward.
+
+Brief: "$ARGUMENTS" — or, if that is empty, the user's request in this conversation (if it isn't clear, ask the user: "What should we explore directions for?")
+
+## 1. Plan the directions
+
+If the brief is empty, ask the user what to design before doing anything else.
+
+Call `list_open_design_skills` to find the skill that fits what's being designed (a landing page, a deck, a dashboard…). Then call `prepare_open_design_exploration` with that `skillId` and the brief:
+
+- `count`: the number of directions the user asked for (2–4). Default 3.
+- If the user named what should vary ("three hero concepts", "different pricing layouts"), pass `axis: "custom"` and `customDirections`, one `{ label, brief }` per direction.
+- Otherwise leave `axis` out. The tool picks visual styles when no design system is active, and layout or narrative structures when one is, so the brand is kept.
+- Pass `directionIds` only when the brief's tone clearly calls for specific directions, e.g. `editorial-monocle` for a magazine or `brutalist-experimental` for an art or agency site.
+
+If the result says the active design system was set aside, tell the user.
+
+## 2. Generate each direction
+
+For each direction in the result, follow `sharedInstructions` followed by that direction's own `instructions`. Write its file at exactly its `suggestedEntryPath`, then call `register_open_design_artifact` with the `explorationId`, the direction's `directionId`, kind, title and `sourceSkillId`.
+
+These are **sketches**: one screen, or a cover plus two slides for a deck. Divergence matters more than polish. If you can delegate to sub-agents, generate the directions in parallel and give each one `sharedInstructions` plus its own `instructions`.
+
+## 3. Compare
+
+Call `compare_open_design_exploration` with `contactSheet: true`. If you can view images, open the contact sheet and check that the directions look clearly different (layout and hero pattern, not just colour). Regenerate any direction that resembles another, then compare again.
+
+## 4. Present
+
+Give the user the comparison page path (it opens in any browser straight from the file system and shows every direction side by side), and the contact sheet path if one was made. In one line each, say how the directions differ. Ask which one to take forward, and whether to:
+
+- **build it out** at full fidelity,
+- **merge** in parts of another direction ("B, with A's hero"), or
+- **save it as a design system** for later work.
+
+## 5. Take the choice forward
+
+Call `choose_open_design_direction` with the `explorationId`, the chosen `directionId`, `next` (`build-out`, `merge` with `mergeFrom`, or `save-design-system`) and the user's own adjustments as `notes`. Follow the returned `instructions` and register the result as they say.
+
+<!-- claude-only -->
+**Artifact preview.** If you have an Artifact tool, publish the result as its private artifact preview (the built-out design, not the sketches) once it's registered: call `publish_open_design_artifact` with `provider: "claude-artifact"` and follow what it returns. Publish again after each round of feedback you apply; it goes to the same artifact. Give the link once, then just say the preview was updated.
+<!-- /claude-only -->

package/assets/claude-skills/open-design-integrations/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: "open-design-integrations"
+description: Show which services Open Design can use directly (Canva, Figma, Notion, Google Drive, Slack, social posting), whether each is connected, and how to set one up — use whenever the user asks which integrations, connectors or services Open Design can use, what's connected, or how to connect Canva, Figma, Notion, Google Drive, Slack or a social posting service
+argument-hint: optionally, a service to set up (e.g. "set up Notion")
+---
+
+<!-- generated:curated-entry -->
+
+Show the user Open Design's integrations and whether each one is connected here.
+
+Request: "$ARGUMENTS" — or, if that is empty, the user's request in this conversation (if it isn't clear, ask the user: "Anything you'd like to connect? (or leave empty to just see the list)")
+
+## 1. Get the list
+
+Call `list_open_design_integrations` with no arguments. It returns every integration grouped by purpose, each with what it does, the tool names that show it's connected on this agent, whether it can be set up here, and how to manage without it.
+
+## 2. Work out each status
+
+Use exactly three statuses:
+- 🟢 **Connected**: your own tools include one matching its "Connected if your tools include" hints. Check deferred or on-demand tools too (search for them) before deciding one is missing.
+- 🟡 **Installed, not connected**: it's configured but its tools aren't available (it needs sign-in, failed to connect, or needs a restart). If you can run shell commands, run the read-only `claude mcp list` (Claude Code) or `codex mcp list` (Codex) and look for its server name or URL; a configured server without matching tools is 🟡. Run nothing else.
+- ⚪ **Not installed**: neither of the above.
+
+If you can't run those commands, use only 🟢 and ⚪, and say that an integration you've already added may need a restart to show up.
+
+## 3. Reply
+
+Show one short table per group (Design, Docs & storage, Team, Social posting), in the order the list gives:
+
+| | Integration | What it does in Open Design | Next step |
+|---|---|---|---|
+
+- The first column is the dot only.
+- Next step: "Ready to use" for 🟢; "Sign in or restart (`/mcp` in Claude Code, `codex mcp login <name>` in Codex)" for 🟡; "Ask me to set it up" for ⚪ when it can be set up here, otherwise "Manual setup" plus one line from its manual path.
+
+End with a one-line legend (🟢 connected · 🟡 installed, not connected · ⚪ not installed) and offer to set up any ⚪ integration the user names.
+
+## 4. Setting one up (only when asked)
+
+Don't install anything from the list itself. If the request above, or the user's answer, names an integration to set up: call `list_open_design_integrations` with that `integration`, and follow its setup steps and rules. That means asking for and getting the user's yes before installing anything, and never asking for or writing an API key.

package/assets/claude-skills/open-design-new/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: "open-design-new"
+description: Start a new design by picking what to make (prototype, mobile app, slides, document, wireframe, animation, résumé, research, data report, poster, social post, diagram), then build it with the right recipe
+argument-hint: what to make, optionally followed by the brief (e.g. "a wireframe of onboarding for a budgeting app")
+---
+
+<!-- generated:curated-entry -->
+
+Start a new design with Open Design.
+
+Request: "$ARGUMENTS" — or, if that is empty, the user's request in this conversation (if it isn't clear, ask the user: "What do you want to make, and what is it for?")
+
+## 1. Pick the surface
+
+Call `list_open_design_skills` with `surface: "list"` to get the kinds of thing Open Design can make (each with an id, label and description).
+
+- If the request starts with or clearly names one of them (by id or label, e.g. "wireframe", "diagram", "a poster"), use that surface.
+- If it names none, or is empty, show the user the surfaces as a short list (label and description) and ask which one. Stop until they answer.
+
+## 2. Ask what's missing
+
+Call `list_open_design_skills` with `surface` set to the chosen id. The result has the surface's `questions` and its `entries`.
+
+Ask only the questions the request doesn't already answer, all at once, in one short message. If the request answers them all, don't ask anything.
+
+## 3. Build it
+
+- If the surface has a `prompt` (for example `open-design-poster` or `open-design-social-post`), follow that flow from its first step with the user's request as the brief. In Copilot Chat it's the `/` command of the same name; in Claude Code and Codex it's the skill of the same name.
+- Otherwise pick the entry that best fits the request. Entries come in curated order: the recipe first, then its remixable example when there is one. To start from a rendered example (an entry with an `exampleArtifactPath`), call `remix_open_design_example`; otherwise call `prepare_open_design_brief` with its id and the brief, and follow the general Open Design flow: write the files, register the artifact, then check it with `check_open_design_artifact` before saying it's done.
+
+<!-- claude-only -->
+**Picking by eye (Claude Desktop Chat).** When the user wants to choose a starting example from pictures, and `show_open_design_examples` is in your tool list (it is listed only where the host shows MCP Apps inline), call it with `surface` set to the chosen id instead of listing entries in text. "Remix this" posts the pick in the chat; then call `remix_open_design_example` with the skillId it names. Without that tool, keep to the text list above.
+<!-- /claude-only -->
+
+<!-- claude-only -->
+**Artifact preview.** If you have an Artifact tool, publish this design as its private artifact preview once it's registered and checked: call `publish_open_design_artifact` with `provider: "claude-artifact"` and follow what it returns. Publish again after each round of feedback you apply; it goes to the same artifact. Give the link once, then just say the preview was updated.
+<!-- /claude-only -->
+
+Never pick an entry marked `stub: true`.