@feimacode/open-design-agent-kit 0.2.0 → 0.3.0

package/assets/claude-skills/article-magazine/SKILL.md

@@ -11,4 +11,4 @@ Use the Open Design skill `od:prototype:article-magazine` (Magazine Article).
 
 Brief: "$ARGUMENTS", or if empty: "Use the Magazine Article template to turn my content into a Huashu / huashu-md-html-inspired long-form HTML essay. Preserve the template's visual signature, use real content and data, and avoid lorem ipsum or placeholder images."
 
-Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:prototype:article-magazine" and this brief — call `list_open_design_design_systems` first only if the user names a brand or visual direction. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.
+Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:prototype:article-magazine" and this brief — call `list_open_design_design_systems` first if the user names a brand or visual direction, or `recommend_open_design_design_systems` if they name none and no design system is active. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.

package/assets/claude-skills/card-twitter/SKILL.md

@@ -11,4 +11,4 @@ Use the Open Design skill `od:prototype:card-twitter` (Twitter Share Card).
 
 Brief: "$ARGUMENTS", or if empty: "Use the Twitter Share Card template to turn my content into a Twitter quote or data card designed to pair with a post. Preserve the template's visual signature, use real content and data, and avoid lorem ipsum or placeholder images."
 
-Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:prototype:card-twitter" and this brief — call `list_open_design_design_systems` first only if the user names a brand or visual direction. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.
+Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:prototype:card-twitter" and this brief — call `list_open_design_design_systems` first if the user names a brand or visual direction, or `recommend_open_design_design_systems` if they name none and no design system is active. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.

package/assets/claude-skills/card-xiaohongshu/SKILL.md

@@ -11,4 +11,4 @@ Use the Open Design skill `od:prototype:card-xiaohongshu` (Xiaohongshu Card).
 
 Brief: "$ARGUMENTS", or if empty: "Use the Xiaohongshu Card template to turn my content into a Xiaohongshu-style swipeable knowledge-card carousel. Preserve the template's visual signature, use real content and data, and avoid lorem ipsum or placeholder images."
 
-Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:prototype:card-xiaohongshu" and this brief — call `list_open_design_design_systems` first only if the user names a brand or visual direction. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.
+Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:prototype:card-xiaohongshu" and this brief — call `list_open_design_design_systems` first if the user names a brand or visual direction, or `recommend_open_design_design_systems` if they name none and no design system is active. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.

package/assets/claude-skills/data-report/SKILL.md

@@ -11,4 +11,4 @@ Use the Open Design skill `od:prototype:data-report` (Data Visualization Report)
 
 Brief: "$ARGUMENTS", or if empty: "Use the Data Visualization Report template to turn my CSV, Excel, or JSON data into a polished visual report page. Preserve the template's visual signature, use real content and data, and avoid lorem ipsum or placeholder images."
 
-Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:prototype:data-report" and this brief — call `list_open_design_design_systems` first only if the user names a brand or visual direction. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.
+Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:prototype:data-report" and this brief — call `list_open_design_design_systems` first if the user names a brand or visual direction, or `recommend_open_design_design_systems` if they name none and no design system is active. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.

package/assets/claude-skills/deck-guizang-editorial/SKILL.md

@@ -11,4 +11,4 @@ Use the Open Design skill `od:deck:deck-guizang-editorial` (Guizang Editorial E-
 
 Brief: "$ARGUMENTS", or if empty: "Use the Guizang Editorial E-Ink Deck template to turn my content into an editorial magazine x e-ink horizontal deck with 10 layouts and 5 palettes. Preserve the template's visual signature, use real content and data, and avoid lorem ipsum or placeholder images."
 
-Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:deck:deck-guizang-editorial" and this brief — call `list_open_design_design_systems` first only if the user names a brand or visual direction. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.
+Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:deck:deck-guizang-editorial" and this brief — call `list_open_design_design_systems` first if the user names a brand or visual direction, or `recommend_open_design_design_systems` if they name none and no design system is active. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.

package/assets/claude-skills/deck-open-slide-canvas/SKILL.md

@@ -11,4 +11,4 @@ Use the Open Design skill `od:deck:deck-open-slide-canvas` (Open-Slide 1920 Canv
 
 Brief: "$ARGUMENTS", or if empty: "Use the Open-Slide 1920 Canvas Deck template to turn my content into a locked 1920x1080 free-composition deck with React component-level layout. Preserve the template's visual signature, use real content and data, and avoid lorem ipsum or placeholder images."
 
-Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:deck:deck-open-slide-canvas" and this brief — call `list_open_design_design_systems` first only if the user names a brand or visual direction. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.
+Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:deck:deck-open-slide-canvas" and this brief — call `list_open_design_design_systems` first if the user names a brand or visual direction, or `recommend_open_design_design_systems` if they name none and no design system is active. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.

package/assets/claude-skills/deck-swiss-international/SKILL.md

@@ -11,4 +11,4 @@ Use the Open Design skill `od:deck:deck-swiss-international` (Swiss Internationa
 
 Brief: "$ARGUMENTS", or if empty: "Use the Swiss International Deck template to turn my content into a 16-column-grid deck with one saturated accent and 22 locked layouts. Preserve the template's visual signature, use real content and data, and avoid lorem ipsum or placeholder images."
 
-Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:deck:deck-swiss-international" and this brief — call `list_open_design_design_systems` first only if the user names a brand or visual direction. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.
+Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:deck:deck-swiss-international" and this brief — call `list_open_design_design_systems` first if the user names a brand or visual direction, or `recommend_open_design_design_systems` if they name none and no design system is active. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.

package/assets/claude-skills/doc-kami-parchment/SKILL.md

@@ -11,4 +11,4 @@ Use the Open Design skill `od:prototype:doc-kami-parchment` (Kami Parchment Docu
 
 Brief: "$ARGUMENTS", or if empty: "Use the Kami Parchment Document template to turn my content into a warm parchment document with monochrome ink-blue accents, one serif family, and editorial-grade typography. Preserve the template's visual signature, use real content and data, and avoid lorem ipsum or placeholder images."
 
-Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:prototype:doc-kami-parchment" and this brief — call `list_open_design_design_systems` first only if the user names a brand or visual direction. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.
+Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:prototype:doc-kami-parchment" and this brief — call `list_open_design_design_systems` first if the user names a brand or visual direction, or `recommend_open_design_design_systems` if they name none and no design system is active. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.

package/assets/claude-skills/frame-data-chart-nyt/SKILL.md

@@ -11,4 +11,4 @@ Use the Open Design skill `od:video:frame-data-chart-nyt` (NYT-Style Data Chart
 
 Brief: "$ARGUMENTS", or if empty: "Use the NYT-Style Data Chart Frame template to turn my content into a frame with NYT-newsroom typography, staggered reveal animation, and editorial-grade charts. Preserve the template's visual signature, use real content and data, and avoid lorem ipsum or placeholder images."
 
-Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:video:frame-data-chart-nyt" and this brief — call `list_open_design_design_systems` first only if the user names a brand or visual direction. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.
+Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:video:frame-data-chart-nyt" and this brief — call `list_open_design_design_systems` first if the user names a brand or visual direction, or `recommend_open_design_design_systems` if they name none and no design system is active. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.

package/assets/claude-skills/frame-flowchart-sticky/SKILL.md

@@ -11,4 +11,4 @@ Use the Open Design skill `od:video:frame-flowchart-sticky` (Sticky Flowchart Fr
 
 Brief: "$ARGUMENTS", or if empty: "Use the Sticky Flowchart Frame template to turn my content into a whiteboard-brainstorm frame with SVG curve connectors, sticky-note nodes, and cursor interaction. Preserve the template's visual signature, use real content and data, and avoid lorem ipsum or placeholder images."
 
-Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:video:frame-flowchart-sticky" and this brief — call `list_open_design_design_systems` first only if the user names a brand or visual direction. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.
+Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:video:frame-flowchart-sticky" and this brief — call `list_open_design_design_systems` first if the user names a brand or visual direction, or `recommend_open_design_design_systems` if they name none and no design system is active. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.

package/assets/claude-skills/frame-glitch-title/SKILL.md

@@ -11,4 +11,4 @@ Use the Open Design skill `od:video:frame-glitch-title` (Glitch Title Frame).
 
 Brief: "$ARGUMENTS", or if empty: "Use the Glitch Title Frame template to turn my content into a digital-glitch, chromatic-offset, data-corruption title frame for a video transition or cyberpunk hero. Preserve the template's visual signature, use real content and data, and avoid lorem ipsum or placeholder images."
 
-Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:video:frame-glitch-title" and this brief — call `list_open_design_design_systems` first only if the user names a brand or visual direction. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.
+Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:video:frame-glitch-title" and this brief — call `list_open_design_design_systems` first if the user names a brand or visual direction, or `recommend_open_design_design_systems` if they name none and no design system is active. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.

package/assets/claude-skills/frame-light-leak-cinema/SKILL.md

@@ -11,4 +11,4 @@ Use the Open Design skill `od:video:frame-light-leak-cinema` (Light-Leak Cinemat
 
 Brief: "$ARGUMENTS", or if empty: "Use the Light-Leak Cinematic Frame template to turn my content into a cinematic opening or chapter card with film light leaks, grain, letterbox framing, and large serif type. Preserve the template's visual signature, use real content and data, and avoid lorem ipsum or placeholder images."
 
-Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:video:frame-light-leak-cinema" and this brief — call `list_open_design_design_systems` first only if the user names a brand or visual direction. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.
+Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:video:frame-light-leak-cinema" and this brief — call `list_open_design_design_systems` first if the user names a brand or visual direction, or `recommend_open_design_design_systems` if they name none and no design system is active. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.

package/assets/claude-skills/frame-liquid-bg-hero/SKILL.md

@@ -11,4 +11,4 @@ Use the Open Design skill `od:video:frame-liquid-bg-hero` (Liquid Background Her
 
 Brief: "$ARGUMENTS", or if empty: "Use the Liquid Background Hero template to turn my content into a WebGL-style fluid displacement background with a quote overlay for a video intro, landing hero, or poster. Preserve the template's visual signature, use real content and data, and avoid lorem ipsum or placeholder images."
 
-Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:video:frame-liquid-bg-hero" and this brief — call `list_open_design_design_systems` first only if the user names a brand or visual direction. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.
+Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:video:frame-liquid-bg-hero" and this brief — call `list_open_design_design_systems` first if the user names a brand or visual direction, or `recommend_open_design_design_systems` if they name none and no design system is active. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.

package/assets/claude-skills/frame-logo-outro/SKILL.md

@@ -11,4 +11,4 @@ Use the Open Design skill `od:video:frame-logo-outro` (Logo Outro Frame).
 
 Brief: "$ARGUMENTS", or if empty: "Use the Logo Outro Frame template to turn my content into a video outro or brand closing frame with segmented logo assembly, glow bloom, and tagline reveal. Preserve the template's visual signature, use real content and data, and avoid lorem ipsum or placeholder images."
 
-Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:video:frame-logo-outro" and this brief — call `list_open_design_design_systems` first only if the user names a brand or visual direction. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.
+Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:video:frame-logo-outro" and this brief — call `list_open_design_design_systems` first if the user names a brand or visual direction, or `recommend_open_design_design_systems` if they name none and no design system is active. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.

package/assets/claude-skills/frame-macos-notification/SKILL.md

@@ -11,4 +11,4 @@ Use the Open Design skill `od:video:frame-macos-notification` (macOS Notificatio
 
 Brief: "$ARGUMENTS", or if empty: "Use the macOS Notification Banner template to turn my content into a realistic macOS notification banner for a video overlay or product teaser. Preserve the template's visual signature, use real content and data, and avoid lorem ipsum or placeholder images."
 
-Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:video:frame-macos-notification" and this brief — call `list_open_design_design_systems` first only if the user names a brand or visual direction. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.
+Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:video:frame-macos-notification" and this brief — call `list_open_design_design_systems` first if the user names a brand or visual direction, or `recommend_open_design_design_systems` if they name none and no design system is active. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.

package/assets/claude-skills/guizang-ppt/SKILL.md

@@ -11,4 +11,4 @@ Use the Open Design skill `od:deck:guizang-ppt` (Write a Brand-to-Revenue Story
 
 Brief: "$ARGUMENTS", or if empty: "Create \"Write a Brand-to-Revenue Story like a Growth Strategy Lead\" as a Marketing and GTM deck in the Guizang Ppt visual system. Scene: annual-marketing-plan. First ask only for missing essentials: audience, decision target, source-of-truth materials, deadline, and must-keep numbers. Then produce a commercial-grade slide plan, written slides, visual direction, speaker-ready structure, and critic pass against this rubric: can the plan connect creative choices to measurable growth."
 
-Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:deck:guizang-ppt" and this brief — call `list_open_design_design_systems` first only if the user names a brand or visual direction. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.
+Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:deck:guizang-ppt" and this brief — call `list_open_design_design_systems` first if the user names a brand or visual direction, or `recommend_open_design_design_systems` if they name none and no design system is active. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.

package/assets/claude-skills/mockup-device-3d/SKILL.md

@@ -11,4 +11,4 @@ Use the Open Design skill `od:prototype:mockup-device-3d` (Device 3D Showcase).
 
 Brief: "$ARGUMENTS", or if empty: "Use the Device 3D Showcase template to turn my content into a static iPhone and MacBook 3D-style showcase with real HTML embedded on the screens. Preserve the template's visual signature, use real content and data, and avoid lorem ipsum or placeholder images."
 
-Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:prototype:mockup-device-3d" and this brief — call `list_open_design_design_systems` first only if the user names a brand or visual direction. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.
+Call `prepare_open_design_brief` (the open-design MCP server's tool) with skillId "od:prototype:mockup-device-3d" and this brief — call `list_open_design_design_systems` first if the user names a brand or visual direction, or `recommend_open_design_design_systems` if they name none and no design system is active. Author the files yourself with your own file-editing tools per the returned instructions, then call `register_open_design_artifact`.

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

@@ -11,26 +11,82 @@ A small, curated subset of skills/templates also has its own explicit `/open-des
 
 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.
 
+<!-- voice:start -->
+**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 |
+<!-- voice:end -->
+
 Follow this flow:
 
 0. **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:** 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. 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` 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 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, in one message, as short multiple-choice options (use your host's question tool if it has one), and accept "you pick"; then call it again with the answers. 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").
 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. 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. Don't describe the screenshots to the user unless they ask. If it returns `no-browser`, skip checking and tell the user once that visual checks need Chrome, Edge or Chromium installed.
+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 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, 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.
@@ -39,12 +95,14 @@ If the user explicitly asks for **options to compare** ("show me three direction
 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, briefly describe how each direction differs, and ask which one to take forward.
+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.
+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](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.
 
@@ -64,6 +122,10 @@ For a **poster, flyer, certificate or other print piece**, or when the user want
 
 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:

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

@@ -1,6 +1,6 @@
 # Remixable Open Design examples
 
-192 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
 
@@ -12,6 +12,7 @@
 - **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.

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

@@ -10,6 +10,25 @@ 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?")
 
+**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 |
+
 ## 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:
@@ -50,6 +69,10 @@ Ask which channels the campaign needs, unless the brief says. Offer this menu (f
 
 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`.
@@ -58,4 +81,7 @@ If the user wants a landing page or an email, build each with its own skill (`od
 
 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.
+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

@@ -10,6 +10,25 @@ Build a deck (or a one-pager) from existing documents with Open Design, storylin
 
 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?")
 
+**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 |
+
 ## 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.
@@ -34,6 +53,10 @@ Build from the approved outline. Use numbers, names and quotes exactly as in the
 
 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-design-system-from-url/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: "open-design-design-system-from-url"
+description: Make a design system from a website — measure its real colours, fonts, spacing and button states in a browser, write DESIGN.md and tokens.css that agree, and check the result side by side with the site before saving — use whenever the user wants a design system, brand kit, theme or tokens taken from a website or URL ("make a design system from stripe.com", "match our site's look", "extract the brand from this page"), even if they don't mention Open Design
+argument-hint: the website address, and optionally light/dark/both and whether it's your brand (e.g. "https://example.com, dark, our brand")
+---
+
+<!-- generated:curated-entry -->
+
+Make an Open Design design system from a website: measure the rendered site, write `DESIGN.md` and `tokens.css` from one set of measurements, and check the result against the site before saving it.
+
+Request: "$ARGUMENTS" — or, if that is empty, the user's request in this conversation (if it isn't clear, ask the user: "Which website should the design system come from?")
+
+**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 |
+
+## 1. Ask only what's missing
+
+Three things decide the run. Take each from the request when it says so, and ask only about the ones it leaves open, in one message:
+
+1. **The address** (and, optionally, up to 3 more pages on the same site, such as a pricing or product page).
+2. **Light, dark or both.** Default to light if the user doesn't care.
+3. **Their own brand, or a reference?** For a reference site the design system is named "<Name>-inspired" and no logos or images are copied.
+
+If the request already answers all three ("make a dark design system from https://example.com, it's our brand"), ask nothing and go straight on.
+
+## 2. Measure the site
+
+Call `extract_open_design_design_system` with `url`, `extraUrls` if there are any, and `theme`.
+
+- **`ok`**: you get a `draft` (contract tokens, a `[data-theme="dark"]` set only if the site has a dark theme), `sources` saying which element each value came from, the `unmeasured` tokens, and the screenshot. Look at the screenshot and the role crops in the evidence bundle before writing anything.
+- **`partial`** (no browser installed): only candidate colours and fonts from the page source. Tell the user, show the candidates, and ask them to confirm the brand colour and font, or to install Chrome for a full measurement.
+- **`blocked`**: show the user the screenshot and the reason. Ask for the site's CSS, a screenshot of the page they mean, or another public page. Don't retry the same page.
+- An invalid-args error (a private address, an extra page on another site): tell the user what was refused and why.
+
+If the user asked for dark and the result notes that no dark theme was found, say so. Don't invent dark values.
+
+## 3. Write both files from the draft
+
+Call `create_open_design_design_system` with a `name` (for a reference site, "<Name>-inspired") and a `brief` describing the site in a sentence. Don't pass `sourceUrl`: you have better measurements already. It returns the `suggestedEntryPath`, the `id` and the token contract.
+
+Write `DESIGN.md` at `suggestedEntryPath` and `tokens.css` beside it, **both from the same draft**:
+
+- **`tokens.css`**: start from `draftCss`. Keep every measured value exactly as measured. For an `unmeasured` token, leave it out so the contract fallback applies, or derive it from measured ones (a `color-mix()` of `--accent` for a missing hover); never make one up, and don't fill two steps with the same value.
+- **Sanity-check each role against the screenshot first.** If a measured value plainly can't be that role (text that would be unreadable on `--bg`, a hairline as a spacing step), drop it and say so; don't write prose to explain it away.
+- **`DESIGN.md`**: the values it names (primary colour, surface, text, the font families, the type scale) must be the same values as `tokens.css`. Write the prose (atmosphere, layout, components, voice, do and don't) from the screenshots. For a reference site, say near the top that it is inspired by the site and name it.
+- **Marks**: for the user's own brand, copy the files in the result's `marks` into an `assets/` folder beside `DESIGN.md` and mention them there. For a reference site, copy none.
+
+## 4. Review it side by side
+
+Write a review page next to the design system as `review.html`, and register it with `register_open_design_artifact`. One page, two columns:
+
+- **Left, "The site":** the desktop screenshot from the evidence bundle (an `<img>` with a relative path to it), cropped with `object-fit: cover` to the top 900px.
+- **Right, "The design system":** a sample page that uses only the new `tokens.css` (`<link rel="stylesheet">` to it, or its `:root` block inlined): a hero with a heading and a primary and secondary button, a card with text, and a form row with a label, an input and a button.
+
+Call `check_open_design_artifact` on it. Compare the two columns yourself (colours, font, button shape, density), fix anything that's clearly off, then show the user the review and ask whether it matches.
+
+Apply what the user says ("the buttons are rounder on the site" → raise the radius tokens) in both files, rebuild the review and check again. Stop after **two rounds** of fixes: save then, and list anything still open.
+
+## 5. Save
+
+Call `set_active_design_system` with the returned `id` if the user wants to design with it now (offer it). Tell the user the design system's id and where its files are, and that the measurements are kept in the evidence bundle.
+
+<!-- claude-only -->
+**Claude Design.** If you have Claude's Artifact tool, offer to copy the design system into Claude Design as a Design System artifact. Export it with `npx tsx scripts/claude-design-system.ts export <its folder> <out-dir>` when you're in a checkout of the agent kit; that writes Claude's format and checks it. Otherwise follow the Open Design design systems guide, "Use one in Claude Design".
+<!-- /claude-only -->

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

@@ -10,6 +10,25 @@ Turn existing Markdown documents into designed HTML pages with Open Design, one
 
 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?")
 
+**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 |
+
 ## 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.

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

@@ -10,6 +10,25 @@ Explore several deliberately different design directions with Open Design, compa
 
 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?")
 
+**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 |
+
 ## 1. Plan the directions
 
 If the brief is empty, ask the user what to design before doing anything else.
@@ -44,3 +63,7 @@ Give the user the comparison page path (it opens in any browser straight from th
 ## 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

@@ -10,6 +10,25 @@ 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)")
 
+**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 |
+
 ## 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.