--- name: design-studio description: Design and edit CustomerPro social post designs (Autopilot layout documents) through the CustomerPro Design Studio MCP server. Use when the user wants to create, restyle or fix a post design, poster, festival greeting, offer card, carousel or story for CustomerPro; edit the design of an Autopilot post; make a private design for their workspace; submit a design to the CustomerPro design marketplace; or review design submissions. Also use whenever the customerpro-design tools (get_layout_contract, get_design, save_post_design, save_org_design ...) are in play. --- # CustomerPro Design Studio CustomerPro draws every social post picture from a **layout document**: JSON (schema 3) describing a background and layers on a 1080×1350 card, with brand colour tokens instead of fixed colours and named text fields the AI fills in. You edit designs by reading, changing and saving these documents through the `customerpro-design` MCP server (`https://customerpro.in/mcp/design`). The server validates and stores; it cannot draw. You draw locally with `scripts/render.mjs` and look at the result. References next to this file (read them when you need them, not all up front): - `references/layout-format.md`: the document format, every layer type and key. - `references/recipes.md`: six complete, valid designs to start from. - `references/pitfalls.md`: what goes wrong and how to avoid it. - `references/tools.md`: every MCP tool with its arguments. Without the plugin, the same files are at `https://customerpro.in/design-studio/skill.md`, `https://customerpro.in/design-studio/references/.md` and `https://customerpro.in/design-studio/scripts/render.mjs`. ## Workflow 1. **Contract, once per session.** Call `get_layout_contract` before writing any document. It is the exact list of layer types, keys, tokens, icons, motifs and limits the validator enforces; `layout-format.md` explains it. 2. **Start from something.** Editing a post: `list_post_designs`, then `get_post_design` (keep its `rev`). New design: `search_designs` for a close match (or a recipe), then `get_design`. Never start from a blank page when a close design exists. 3. **Edit the document.** Keep layer `id`s stable, use brand tokens, keep text within field limits, and make the design look finished with every field empty (stacks and `when` conditions, see the recipes). 4. **Validate.** `validate_layout` on the exact JSON you will save. Fix every error; do not remove features to get past it without saying so. 5. **Render and look.** Save the document to a file and run `node scripts/render.mjs design.json --out design.png` (add `--variant n`, `--size 1:1|9:16`, `--slide n --slides m` for each variant, size and carousel slide the design has). Open the PNG and check it: nothing cut off, overlapping or unreadable, the empty-field case too (`--fields empty.json` with `{}`). Iterate until it looks right. If Playwright cannot run, call `preview_link` and give the user the link instead. 6. **Save.** `save_post_design` (with `rev`), `save_org_design`, or `save_submission` then `submit_submission`. Tell the user what changed. For a new manual post, `open_in_studio` instead and give the user the link. ## Rules - **Validate before every save.** A save of an unvalidated document is a bug. - **Pass `rev`** when saving a post's design. A conflict means someone else saved first or the post moved on: re-read with `get_post_design`, re-apply your change to the fresh document, validate, render, save again. Never overwrite blindly. - **Destructive tools need the user.** `reset_post_design`, `archive_org_design`, `approve_submission` and `reject_submission` first return a `confirm_token` and what will happen. Show that to the user and call again with the token only after they say yes, in this conversation. - **Never invent asset URLs.** A picture the design itself carries (a texture, a product cut-out, a logo variant) must be uploaded with `upload_design_asset`; put the returned URL in `assets` and reference it with `src`. Post photos are fields (`image_url`), not assets. - **Stay inside the limits**: 40 top-level layers, 120 in all, groups 4 deep, 3 variants, 96 KB, text values 200 characters, field limits 1–500. Editing a post's design keeps the post template's own fields and limits. - **Honest fields.** Facts (price, date, place, phone, offer, code, counts) come from the user, never from you: name fields so they are recognised (`price`, `date_line`, `place`, `code` …) and make the design work when they are empty. Customer words, names and ratings go in `owner_only`. - **Brand colours are tokens** (`brand.primary`, `auto`, `muted` …). A literal hex colour is almost always wrong, because every workspace has its own brand. - **Look before you claim.** Do not tell the user a design is done or looks good without having rendered it (or given them a preview link). ## render.mjs ``` node scripts/render.mjs [--fields fields.json] [--brand brand.json] [--size 4:5|1:1|9:16] [--variant 0|1|2] [--slide n --slides m] [--out out.png] [--scale 0.5] [--engine-url URL | --engine-file path] ``` - `` may be a bare document or a `get_design` / `get_post_design` result. Without `--fields` it uses the document's `example`. - `--brand` takes `{ "name": "...", "colors": ["#hex", ...], "logo_url": "https://...", "motifs": ["diya"] }`; the default is a neutral blue brand. Try a light and a dark brand for designs others will use. - It fetches the engine from `https://customerpro.in/build/design-engine.js` (the same code the app draws with) and installs Playwright into `~/.cache/customerpro-design-render` on first use. It prints the PNG path. - Exit 3 means Playwright could not be installed: fall back to `preview_link`.