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

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

@@ -0,0 +1,60 @@
+---
+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
+---
+
+<!-- generated:open-design-agent-kit -->
+
+Build a campaign with Open Design: one message, one visual system, every channel.
+
+Brief: the rest of the user's message (if there is none, 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.
+
+## 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.

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

@@ -0,0 +1,38 @@
+---
+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
+---
+
+<!-- generated:open-design-agent-kit -->
+
+Build a deck (or a one-pager) from existing documents with Open Design, storyline first, keeping every fact traceable to its source.
+
+Request: the rest of the user's message (if there is none, 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.
+
+## 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/codex-skills/open-design-docs/SKILL.md

@@ -0,0 +1,51 @@
+---
+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
+---
+
+<!-- generated:open-design-agent-kit -->
+
+Turn existing Markdown documents into designed HTML pages with Open Design, one page per file.
+
+Request: the rest of the user's message (if there is none, 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/codex-skills/open-design-explore/SKILL.md

@@ -0,0 +1,45 @@
+---
+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
+---
+
+<!-- generated:open-design-agent-kit -->
+
+Explore several deliberately different design directions with Open Design, compare them side by side, and take the chosen one forward.
+
+Brief: the rest of the user's message (if there is none, 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.

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

@@ -0,0 +1,39 @@
+---
+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
+---
+
+<!-- generated:open-design-agent-kit -->
+
+Show the user Open Design's integrations and whether each one is connected here.
+
+Request: the rest of the user's message (if there is none, 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/codex-skills/open-design-new/SKILL.md

@@ -0,0 +1,30 @@
+---
+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
+---
+
+<!-- generated:open-design-agent-kit -->
+
+Start a new design with Open Design.
+
+Request: the rest of the user's message (if there is none, 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.
+
+Never pick an entry marked `stub: true`.

package/assets/codex-skills/open-design-poster/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: open-design-poster
+description: Design a poster or flyer for print or screen, check it, and export print-ready PDFs or upload-ready images, including other sizes and one version per row of a spreadsheet — use whenever the user wants a poster, flyer, event or gig poster, print piece, handout, certificate or name card set, or wants an existing design in other sizes or as a print-ready PDF, even if they don't mention Open Design
+---
+
+<!-- generated:open-design-agent-kit -->
+
+Design a poster with Open Design, check it, and export files that are ready to print or post.
+
+Brief: the rest of the user's message (if there is none, ask the user: "What is the poster for, and is it for print (which size) or screens?")
+
+## 1. Pick the medium and a default shape
+
+Decide whether this is for **print** or **screens**. If the brief doesn't say, ask the user before doing anything else. Don't guess between print and screen: the units, bleed and type sizes are different.
+
+You don't need the final size yet. The poster is built **fluid**: it reflows to any shape, so the user can pick or change the size later, when exporting. Use the size the user names as the default shape; otherwise use `a3` for print and `ig-portrait` for screens, and tell the user they can change it at any time.
+
+| Use | Format id | Size |
+|---|---|---|
+| Print, small: flyer, handout | `a4` · `letter` | 210×297 mm · 8.5×11 in |
+| Print, medium: notice-board poster | `a3` · `tabloid` | 297×420 mm · 11×17 in |
+| Print, large: wall poster | `a2` · `a1` · `poster-18x24` · `poster-24x36` | 420×594 mm · 594×841 mm · 18×24 in · 24×36 in |
+| Print, conference or research poster | `a0` | 841×1189 mm |
+| Instagram portrait | `ig-portrait` | 1080×1350 px |
+| Story / Reels / TikTok cover | `story` | 1080×1920 px |
+| X single image | `x-image` | 1600×900 px |
+| Square (Instagram / LinkedIn) | `ig-square` | 1080×1080 px |
+
+A handout and a wall poster carry different amounts of text, so if the user says which it is, write the copy for that; the shape itself can still change.
+
+## 2. Generate
+
+If the user asked for options ("show me a few directions"), run a design exploration first and build out the direction they pick, with the same `format` and `fluid: true`.
+
+Otherwise call `prepare_open_design_brief` with:
+
+- a `skillId`: `od:prototype:poster-hero` for a bold marketing poster, `od:prototype:magazine-poster` for an editorial or type-led one, or another skill whose style fits better (`list_open_design_skills` with query "poster");
+- the brief, in the user's words;
+- `format`: the default shape from step 1;
+- `fluid: true`.
+
+Call `list_open_design_design_systems` first only if the user names a brand or visual direction.
+
+Author the file yourself, following the returned instructions. Their **Canvas** section is authoritative: one `data-od-card data-od-fluid` element sized by `--od-w`/`--od-h`, everything inside sized in container units, and layout rules for wide and tall shapes. Also:
+
+- Use real copy from the brief, with no lorem ipsum. A poster is read from a distance: one dominant headline, then the what / when / where, then the call to action.
+- If the user gives a list of names, sessions or locations to make one poster each, mark the changing text with `data-od-field="<column name>"` (and a per-person QR slot with `data-od-qr-field="<column>"`), and fill the design with the first row's values.
+- No external image URLs unless the user supplied them. No emoji as key visuals; draw them as inline SVG.
+
+## 3. Add a QR code, if it needs one
+
+Register the artifact first (step 4), then call `create_open_design_qr_code` with the entry path and the URL, and paste the returned inline SVG where the code goes. Never draw a fake or placeholder QR code.
+
+## 4. Register
+
+Call `register_open_design_artifact` with the entry path, kind `html`, a title, `sourceSkillId`, and `format` set to the default shape.
+
+## 5. Check and fix
+
+Call `check_open_design_artifact` with the entry path. It returns the poster as an image plus preflight findings. Fix every **error** in its findings (text cut off, overlapping or in the bleed, a QR code that doesn't decode), and fix warnings where you reasonably can (sizes that don't scale with the poster, small type, low contrast, low-resolution images). Look at the image too: the headline should dominate and nothing important should be cramped or cut. Check again until there are no errors (at most two fix rounds; tell the user about anything left).
+
+## 6. Other shapes
+
+When the user wants other sizes, or before the final export of a print piece, call `export_open_design_artifact` with `shapeSheet: true` and `checkOnly: true` (add `presets` with just the shapes they care about, or leave it out for every shape). It writes one image of the poster at each shape, marking shapes with errors; show it to the user. If you can view images, look at it too: the headline should dominate every shape and nothing important should be cropped.
+
+For a shape that has errors or looks wrong, call `adapt_open_design_artifact` with the entry path and those format ids. For a fluid poster it returns **tune** instructions: fix that shape inside the same file with its `@container` rule, then check every shape again with a shape sheet. Don't create new files for other sizes.
+
+## 7. Export
+
+- **One shape:** call `export_open_design_artifact` with the entry path and `preset` set to the format id. A print format gives a PDF the size of the bleed box, with trim and bleed boxes set and the bleed added automatically; add `cropMarks: true` if the user's printer wants crop marks. A screen format gives a PNG within the platform's size limit.
+- **Several shapes:** pass `presets` with the format ids instead: one file per shape, named `<name>-<format>`.
+- **One per row of a list:** add `data` with the workspace path of the user's CSV, XLSX or JSON file, and `nameField` with the column to name files by. Images come out one per row; print PDFs come out as one multi-page PDF per shape (add `split: true` for one file per row).
+
+## 8. Report
+
+List each exported file's path, size and any remaining warnings. For print files, also give the trim size and bleed, and tell the user the PDF is RGB: most print shops convert it, but they should ask if theirs needs CMYK. Mention that the poster can be exported at any other size later without regenerating it. Don't print, post, upload or order anything yourself.

package/assets/codex-skills/open-design-preview/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: open-design-preview
+description: Open an Open Design artifact in a live browser preview, where you can see it update as it changes, click elements to comment on them, and compare check screenshots before and after — use whenever the user asks to see, show, preview or open an Open Design artifact, or wants to comment on one visually
+---
+
+<!-- generated:open-design-agent-kit -->
+
+Show an Open Design artifact in the browser preview.
+
+Request: the rest of the user's message (if there is none, ask the user: "Which design should the preview show?")
+
+1. Work out which artifact is meant. Registered artifacts are the files under the Open Design output folder (default `.open-design/`) that have a `.artifact.json` file next to them. Use the one the request names; if it names none, use the one you made or changed most recently in this conversation. If that still doesn't settle it, call `open_open_design_preview` without `entryPath`: the preview then lists every design, and the user picks there.
+2. Call `open_open_design_preview` with that `entryPath`.
+3. Tell the user in one or two sentences what happened, using the tool's result: where the preview opened (or the URL to open, when it couldn't open a window), that it reloads by itself when the design changes, and that they can click **Comment**, then an element, to leave a comment, and **Send to agent** when they want you to apply them.

package/assets/codex-skills/open-design-publish/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: open-design-publish
+description: Share an Open Design artifact as a live link (a temporary no-account link, or your own Netlify, Vercel, Cloudflare Pages or GitHub Pages), or as one self-contained HTML file — use whenever the user wants to share, publish, deploy or host an Open Design artifact, or get a link to send to teammates or stakeholders; also when they want a single HTML file to attach or send
+---
+
+<!-- generated:open-design-agent-kit -->
+
+Share an Open Design artifact with people who don't have this project open.
+
+Request: the rest of the user's message (if there is none, ask the user: "Which design should we share, and how?")
+
+## 1. Find the artifact
+
+If the request names a design, find its entry file (`get_open_design_artifact`, or the `.open-design/` folder). If several match or none is named, ask the user which one. It must be registered; if it isn't, register it first with `register_open_design_artifact`.
+
+## 2. A file, or a link?
+
+- **A file to attach or send** (email, Slack, a ticket): call `export_open_design_artifact` with `format: "standalone"`. It writes one self-contained `.html` under the artifact's `exports/` folder, with its local CSS, scripts, images and fonts inlined. Give the user the path, and mention anything it still loads from the internet (such as web fonts). Nothing goes online. Stop here.
+- **A link**: continue below.
+
+## 3. Prepare the link
+
+Call `publish_open_design_artifact` with the `entryPath`. Pass `provider` only if the user already said where:
+
+- `netlify-temporary` or `cloudflare-temporary`: no account, the link lasts about an hour unless claimed
+- `netlify`, `vercel`, `cloudflare-pages` or `github-pages`: the user's own account, a link that lasts
+
+Without a provider, the tool returns the choices: show them to the user and call it again with their pick.
+
+## 4. Follow the returned instructions exactly
+
+They check the host's CLI, then **stop for the user's explicit yes** before anything goes online. That stop is mandatory: say what goes out, who can see it, how long it lasts, and that the small "Made with Open Design" footer badge is included unless they ask for `badge: false`. Deploy only the bundle folder the tool names.
+
+## 5. Finish
+
+Give the user the link. For a temporary link, also give the claim URL and when it expires, for them only. Then record it by calling `publish_open_design_artifact` again with `published`, as the instructions show, so a later publish updates the same site.

package/assets/codex-skills/open-design-recurring/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: open-design-recurring
+description: Set up a design that rebuilds itself on a schedule (a weekly report deck, next week's social posts, a refreshed one-pager), or run one such job — one job file, one supervised run, then a one-line prompt for the scheduler — use whenever the user wants a design made again every day, every week or every month, on a schedule, or as a recurring job, or when a prompt says "Run the Open Design job <path>", even if they don't mention Open Design
+---
+
+<!-- generated:open-design-agent-kit -->
+
+Recurring Open Design jobs: one job file describes what to make each period, and a scheduler runs it.
+
+Request: the rest of the user's message (if there is none, ask the user: "What should be rebuilt, from which sources, and how often?")
+
+If the request names a job file (".open-design/jobs/<id>.job.md", usually "Run the Open Design job …"), go to **Run**. Otherwise go to **Set up**.
+
+If `start_open_design_job_run` isn't one of your tools (VS Code has no scheduler, so it doesn't offer it), you can still write the job file in **Set up**, but say that scheduled runs need Claude Code or Claude Desktop with the Open Design MCP server, and stop there.
+
+## Run
+
+1. Call `start_open_design_job_run` with the job path (and `runNow: true` only when the person asked for a fresh run in this conversation, never from a scheduled prompt).
+2. If it returns `skip`, report the reason in one line and stop. Make no changes.
+3. If it asks you to check out the state branch, do that and call it again.
+4. Otherwise follow its steps in order. This run is unattended: don't ask questions, never publish publicly and never post to social networks.
+5. End with `finish_open_design_job_run`, follow the steps it returns, and reply with its summary.
+
+## Set up
+
+### 1. Agree the job
+
+With the person, settle:
+
+- **What** to make, and with which recipe: `open-design-deck-from-source` for a report deck or one-pager from data, `open-design-social-post` for a batch of posts, `open-design-poster` for a print piece, `open-design-docs` for pages from Markdown.
+- **Sources**: workspace files (a CSV, a CHANGELOG, a report), or data a connector pulls (a sheet in Google Drive, a Notion database). Each connector source needs a `snapshot` workspace path the pulled data is saved to, so every number stays traceable.
+- **How often**: `day`, `week` or `month`, and the time zone (an IANA name such as `Europe/Berlin`).
+- **One file or one per period**: `mode: update` rewrites the same design each period (a living report); `mode: series` keeps one file per period, with `{period}` in the target (a weekly social batch).
+- **Outputs**: export formats (`pdf`, `png`, `pptx`, `standalone` …). PNG, PDF, PowerPoint and video need a browser; runs without one record them as skipped.
+- **Delivery**: `preview` (the private Claude artifact, the default), `pr` (a pull request from the state branch), or a connector action such as "Post the preview link to #design in Slack". Never a public publish or a social post: the scheduler's prompt can't stand in for the person's yes, so the job tools refuse those.
+- **Checks**: `best-effort` (default) or `required`, which holds back the PR and connector deliveries when a run had no browser for the visual check.
+
+### 2. Write the job file
+
+Write `.open-design/jobs/<id>.job.md` (the id is lowercase with hyphens and matches the file name):
+
+```markdown
+---
+id: weekly-kpis
+title: Weekly KPI deck
+recipe: open-design-deck-from-source
+period: week
+timezone: Europe/Berlin
+mode: update
+target: .open-design/weekly-kpis/weekly-kpis.html
+outputs: [pdf]
+sources:
+  - data/kpis.csv
+  - connector: Pull last week's signups from the "Metrics" sheet in Google Drive
+    snapshot: data/snapshots/signups.csv
+deliver: [preview, pr]
+checks: best-effort
+---
+
+A five-slide KPI update for the leadership team: headline numbers first, then
+signups, revenue and churn against last week, with one takeaway per slide.
+```
+
+The brief is the body: write everything a run needs to decide without asking, since nobody answers questions mid-run.
+
+### 3. One supervised run
+
+Run it now, with the person watching: call `start_open_design_job_run` and follow **Run**. Here you may ask questions; fold the answers back into the brief so later runs don't need them. If the start result lists problems by field, fix the job file and start again.
+
+### 4. Schedule it
+
+Give the person the exact prompt to save, and the steps for where they work:
+
+> Run the Open Design job `.open-design/jobs/<id>.job.md`
+
+- **Claude Code cloud scheduled task** (claude.ai/code/routines, or `/schedule`): runs without their computer. The repository needs the Open Design MCP server and skills committed (`npx @feimacode/open-design-agent-kit init --tool claude`, then commit `.mcp.json` and `.claude/skills`, and the job file). There's no browser by default, so PNG, PDF and PowerPoint outputs are skipped unless the environment's setup script installs one. The run log lives on the state branch `claude/open-design-job-<id>`. Schedule a few minutes past the hour, mid-period.
+- **Claude Desktop local scheduled task** (Code tab, Routines, New, Local): runs on their computer with local files and Chrome, only while the app is open and the computer is awake; a missed run gets one catch-up run, which the job skips if the period is already done. Tell them to click **Run now** once and approve each tool, so later runs aren't stopped by a prompt.
+- **`/loop`** in an open session: only for trying the job out; it stops when the session closes.
+- **Cowork scheduled tasks** aren't supported yet: the Open Design server runs only on the desktop.
+
+Point them to the [recurring jobs guide](https://github.com/feimacode/open-design-agent-kit/blob/main/docs/guides/recurring-jobs.md) for details.

package/assets/codex-skills/open-design-social-post/SKILL.md

@@ -15,20 +15,22 @@ If the brief names a platform or format, use it. Otherwise ask the user to pick
 
 | Format | Canvas | skillId | Export |
 |---|---|---|---|
-| X single image | 1600×900 | `od:prototype:card-twitter` | `selector: "[data-od-card]"`, `maxBytes: 5000000` |
+| X single image | 1600×900 | `od:prototype:card-twitter` | `preset: "x-image"` |
 | X post mock (for a video overlay or quote) | card element | `od:prototype:social-x-post-card` | `selector: "[data-od-card]"`, `maxBytes: 5000000` |
-| Square carousel (Instagram / LinkedIn) | 1080×1080 per card | `od:prototype:social-carousel` | `selector: "[data-od-card]"`, `maxBytes: 8000000` |
-| Instagram portrait | 1080×1350 | `od:prototype:poster-hero` | `width: 1080, height: 1350`, `selector: "[data-od-card]"`, `maxBytes: 8000000` |
-| Story / Reels / TikTok cover | 1080×1920 | `od:prototype:poster-hero` | `width: 1080, height: 1920`, `selector: "[data-od-card]"`, `maxBytes: 8000000` |
-| Xiaohongshu cards | 1080×1440 per card | `od:prototype:card-xiaohongshu` | `selector: "[data-od-card]"` |
-| YouTube thumbnail | 1280×720 | `od:prototype:social-youtube-thumbnail` | `width: 1280, height: 720`, `selector: "[data-od-card]"`, `maxBytes: 2000000` |
+| Square carousel (Instagram / LinkedIn) | 1080×1080 per card | `od:prototype:social-carousel` | `preset: "ig-square"` |
+| Instagram portrait | 1080×1350 | `od:prototype:poster-hero` | `preset: "ig-portrait"` |
+| Story / Reels / TikTok cover | 1080×1920 | `od:prototype:poster-hero` | `preset: "story"` |
+| Xiaohongshu cards | 1080×1440 per card | `od:prototype:card-xiaohongshu` | `preset: "xhs-card"` |
+| YouTube thumbnail | 1280×720 | `od:prototype:social-youtube-thumbnail` | `preset: "yt-thumbnail"` |
 | YouTube video | 1920×1080 MP4 | `od:video:hyperframes` | MP4 via the HyperFrames CLI (see step 4) |
 
+A preset fills in the canvas size, `selector: "[data-od-card]"` and the platform's upload limit (X 5 MB, Instagram 8 MB, YouTube thumbnail 2 MB).
+
 For several platforms at once, run steps 2–4 once per format and keep each one as its own artifact.
 
 ## 2. Generate
 
-Call `prepare_open_design_brief` with the row's `skillId` and the brief. Call `list_open_design_design_systems` first only if the user names a brand or visual direction. In the brief you pass, say the exact canvas size from the table.
+Call `prepare_open_design_brief` with the row's `skillId`, the brief, and `format` set to the row's preset id (leave it out for the X post mock and YouTube video). Call `list_open_design_design_systems` first only if the user names a brand or visual direction. For the X post mock, say in the brief that it is one card element.
 
 Author the files yourself with your own file-editing tools, following the returned instructions, and add these rules for social posts:
 
@@ -39,11 +41,11 @@ Author the files yourself with your own file-editing tools, following the return
 
 ## 3. Register
 
-Call `register_open_design_artifact` with the entry path, kind `html`, a title, and `sourceSkillId` set to the row's `skillId`, so the export can find the right size.
+Call `register_open_design_artifact` with the entry path, kind `html`, a title, `sourceSkillId` set to the row's `skillId`, and the same `format` you passed to the brief, so the export can find the right size.
 
 ## 4. Export
 
-- **Image formats**: call `export_open_design_artifact` with the entry path and the row's export arguments. If it returns warnings (failed fonts or images, over budget), fix the artifact and export again.
+- **Image formats**: call `export_open_design_artifact` with the entry path and the row's export arguments. If its preflight reports errors (text cut off, a card that isn't the canvas size) or it returns warnings (failed fonts or images, over budget), fix the artifact and export again. Before exporting, call `check_open_design_artifact` to see the post as an image with its preflight findings, without writing files; fix every error first.
 - **YouTube video**: follow the brief's "Host override" section. Render with `npx hyperframes render … --output <artifact-dir>/exports/<name>.mp4`, and check `ffmpeg -version` first.
 
 ## 5. Report