Update to Beautiful.ai

{
  "description": "Edit, add, split, combine and review Beautiful.ai slides with the Beautiful.ai MCP tools - the workflow every slide change goes through. Use whenever the user asks to change a slide or presentation in Beautiful.ai, add slides, or wants advice on a slide; a whole new deck starts with the presentation building skill and comes back here for each slide.",
  "included_files": [],
  "name": "beautiful-ai-slide-editing",
  "skill_md_contents": "---\nname: beautiful-ai-slide-editing\ndescription: Edit, add, split, combine and review Beautiful.ai slides with the Beautiful.ai MCP tools - the workflow every slide change goes through. Use whenever the user asks to change a slide or presentation in Beautiful.ai, add slides, or wants advice on a slide; a whole new deck starts with the presentation building skill and comes back here for each slide.\n---\n\n# Editing Beautiful.ai slides\n\nYou work on the user's Beautiful.ai presentations through the Beautiful.ai MCP tools. A presentation is a deck of slides; a slide is a JSON model: `template_id` (which template renders it), `states[0]` (the element tree: `header`, `primary`, optional `tray`), `layout` and a few version fields. The app renders the model with the presentation's theme (colors, fonts, styles, logo). The user knows a theme as a **Brand Kit**, a shared team theme as a Shared Brand Kit: that is the app's name for it everywhere the user looks, while the tools, fields and models keep the internal name (`theme`, `sharedThemeId`, `list_themes`, `list_shared_themes`), so say \"Brand Kit\" to the user and \"theme\" to the tools. You read models, change them, render them to check the result, and save them; every save is visible to the user in the editor right away.\n\n## Tools\n\n- Shared knowledge base: `list_shared_knowledge_notes`, `read_shared_knowledge_note`, `write_shared_knowledge_note`\n- The user's notes: `list_user_notes`, `read_user_note`, `write_user_note`\n- Workspaces and presentations: `list_workspaces`, `find_presentations`, `get_presentation`, `get_presentation_theme`, `get_presentation_links`, `create_presentation`, `update_presentation`, `export_presentation`, `list_themes`, `list_shared_themes`\n- Sharing: `create_public_link`, `create_password_protected_link`, `share_presentation_with_user`\n- Slides: `get_slide`, `create_slide`, `update_slide`\n- Templates: `list_slide_templates`, `get_slide_examples`\n- Images and icons: `generate_image_asset`, `create_upload_url`, `save_image_asset`, `list_icons`\n- Rendering: `render_slide`\n- Interactive app: `open_presentation`\n\n## Workflow\n\n1. **Understand the request and find the slide.** You need a presentation id: the user gives it (it is in the editor's url), you find it by name (`find_presentations` in a workspace from `list_workspaces`: a loose match on the words of the name, most recent first, editable presentations only; search each workspace when the user has several and does not say which; pick the one that fits by name, slide count and last change, and ask when several do), or you are building a new deck (the presentation building skill, see \"The reference skills\"). `get_presentation` gives the deck (`slideIds` in order, \"slide 5\" is the fifth) and the presentation document; `get_slide` gives a slide's model. Read the slides the request is about, and the deck when the request refers to it or consistency matters (see \"The rest of the presentation\").\n2. **Check the notes.** `list_user_notes`, then `read_user_note` for the ones that apply (once per task, not per slide): the user's preferences, brand, audience and what they told you to remember shape every slide you make for them. Then `list_shared_knowledge_notes` and `read_shared_knowledge_note` for the notes whose names match the template or task (for example `dashboard-charts`, `tray-images`): the fastest way to learn a model shape or a renderer pitfall. Trust the notes, but verify in the render and correct a note that turns out wrong.\n3. **Learn the template and its elements.** The slide-elements skill (see \"The reference skills\") documents the model of the template's root element and of everything it nests: read the documents for the elements you are about to write. `list_slide_templates` with the `templateId` gives the template's `defaultData` (what an empty slide starts with) and capabilities (header, tray layouts, color backgrounds, ...). `get_slide_examples` gives complete, real slide models of the template: the quickest way to see which fields a working slide has. Pick an example whose amount of content resembles yours; one or two are enough. When the content needs a template (new slides, restructured content), pick it with the slide-templates skill.\n4. **Build the new model.** Apply the minimal change that fulfills the request, keeping ids of existing elements and everything unrelated to the request untouched, and make the result look good: follow the design guidelines skill (see \"The reference skills\"), in particular give a slide a visual (an image from the source the user chose, see \"Images, logos and icons\", or icons) when it would otherwise be dull, and choose a layout that fills the canvas when the content is small. Keep the data consistent (adding a table column means a cell in every row; adding a chart series means a data point for every category). Keep text short: the slide has fixed space, so new or edited text should be as concise as the text around it. A new slide model carries the current version fields (`version: 10`, `migrationVersion: 10.03`, `textStylesVersion: 2`, see `Slide.md` in the slide-elements skill); without them the renderer runs legacy migrations over your model and rewrites it. Switch templates, add or remove slides only when the request asks for it or clearly requires it (see the sections below).\n5. **Render and check.** `render_slide` with the model and the presentation's theme (`presentationId`, or the theme from `get_presentation_theme`). The renderer swallows layout errors and still produces a broken or partly empty image: `ok: false` with `renderErrors`/`pageErrors` tells you what failed, usually naming the element class and model field at fault, with the tail of the renderer log. Always look at the image and run the design guidelines' checklist before saving: it rendered without errors and shows the requested change; every piece of text is readable with enough contrast; nothing is crowded; nothing is left empty; the slide has something to look at; the whole looks coherent and matches the deck. If anything is off, fix the model and render again (at most 3 attempts). If a problem cannot be fully fixed within that budget, save the best working version and tell the user what remains.\n6. **Save.** `update_slide` for an existing slide (send the full value of every field you change, e.g. the whole `states`; a placeholder of a deck being built is an existing slide, see the presentation building skill), `create_slide` for a new one (a full model, at the position you want in the deck). Only ever save a model you have rendered and checked in step 5: the change reaches the user immediately. A slide with a `libraryItemId` is tied to a shared slide of the team's library (see `Slide.md` in the slide-elements skill): `update_slide` takes `libraryItemId: null` along with the changes to turn it into a regular slide the user's deck owns, and tell the user it no longer follows the shared slide.\n7. **Tell the user** what you changed (including slides added or removed) and any assumptions or caveats, in a few sentences; no model internals. Let them see the result: `open_presentation` in a client that renders apps (together with the editor link, recommended for its own tab, see \"Previewing and showing slides\"), otherwise the link to the editor opened on the slide you worked on (`get_presentation_links`, or `editorUrl` from `get_slide`) unless they are already in it, and the player link when they want to present.\n8. **Leave notes.** Go back over everything you had to look up or figure out about the app and write it down with `write_shared_knowledge_note` (with nothing of the user in it, see \"Knowledge base and user notes\"), and over everything you learned about the user (a preference, a correction, a fact about their company or audience) and write that down with `write_user_note`. Only skip this when the notes already covered everything.\n\n## Previewing and showing slides\n\n`render_slide` returns the rendered slide as an image (one per stage), for any model: a stored slide (`get_slide`, then render it with its presentation's theme), a model you are working on, an alternative you are considering, or an example of a template. Use it to see a slide before you touch it and to check your work before saving. A preview changes nothing; only `update_slide` and `create_slide` do.\n\nThe rendered image is for you: most chat clients do not display images returned by tools, so never tell the user an image is \"shown above\" or attached. To show the user a presentation:\n\n- In a client that renders MCP Apps (Claude, ChatGPT), `open_presentation` puts the presentation's editor in the chat itself: the app shows a button to open the editor, and the editor opens fullscreen when the user clicks it (on a phone or tablet the app only says that editing needs a desktop, so give such a user the player link; the user needs edit access, for a view-only presentation the tool answers with the player link instead). The fullscreen editor hides the conversation (the user can still type below it), which makes it the lesser experience: the better one is the editor open in its own browser tab next to the chat, where it updates live as you work. So whenever you open the app, say in the same message that the in-chat editor works but that the editor link (from the tool's result) in a separate tab is the better way to follow along, and give that link. Use it when the user wants to see, work on or present a presentation without leaving the chat, and after you changed a deck so they can look at the result in place. The editor is live (it shows the presentation as it is and picks up every save), so for a change open it after saving; when building a whole deck, open it right after creating it so the user can watch its placeholders fill in (see the presentation building skill). While the editor is open in the chat, the app tells the host which slide the user is looking at (presentation id, slide number and id), and that arrives as context with their next message: \"this slide\" or a request that names no slide means that one, so you do not need to ask which slide they mean.\n- Otherwise give them the link to the editor opened on the slide: `get_slide` returns it as `editorUrl` (and `get_presentation_links` builds it from a slide number), and the player link when they want to see the deck as the audience does.\n\nDescribe the slide in a sentence next to the app or link (render it first so the description is right); when the client does display tool images, that is a bonus, not something to rely on.\n\n## The rest of the presentation\n\nThe slide is part of a deck. `get_presentation` lists the slides in order; `get_slide` reads any of them; `render_slide` shows how one looks.\n\n- Use the other slides when the request points to them (\"make it match slide 2\", \"use the same numbers as the previous slide\", \"a summary of the deck\"), when consistency matters (naming, number formats, capitalization, tone, how similar slides are structured: look at the neighbors or slides of the same template), or when the request is ambiguous and the deck makes the intent clear. A simple, self-contained edit does not need them.\n- Change only the slides the request is about. If the user asks for a change elsewhere, say so instead of silently changing other slides.\n\n## The reference skills\n\nFour more skills carry the rest of the knowledge; read them as the task needs them (they are served as resources of the Beautiful.ai MCP, and ship with the plugin):\n\n- **Presentation building** (`beautiful-ai://skills/presentation-building`): building a whole new deck: outline, theme, `create_presentation` with a placeholder per slide, opening the deck for the user right away, filling the placeholders with `update_slide`. Read it when the user asks for a new presentation; each of its slides then goes through this skill's workflow.\n- **Slide design** (`beautiful-ai://skills/slide-design`): what makes a slide look good: not dull (images, icons, color), not empty (layouts that fill the canvas), not crowded, coherent with the deck; and the checklist to run on every render. Read it before building and apply its checklist before saving.\n- **Slide templates** (`beautiful-ai://skills/slide-templates`): which template fits which content (with the item counts to stay within), how dashboards are composed, and how to switch a slide to another template. Read it whenever you pick a template for new or restructured content, or when the user asks for a different layout.\n- **Slide elements** (`beautiful-ai://skills/slide-elements`): the model reference, one document per element: the fields of `states[0]` for every template's root element and for the elements they nest (text blocks, media slots, dashboard cells, chart data, tables, items of lists and diagrams), with allowed values, limits and pitfalls. Its SKILL.md maps each template to its root element and lists the documents (`beautiful-ai://skills/slide-elements/elements/<Element>.md`). Read the documents for the elements you are about to write before building a model, and always `TextElement.md` and `ContentElement.md` the first time you write text or media.\n\n## Images, logos and icons\n\nPictures on a slide live in media elements that take a `content_type` (`\"image\"`, `\"logo\"` or `\"icon\"`) and a `content_value` (an asset id, or an icon key). Keep the slide's existing ones and never invent asset ids or icon keys.\n\n- Icons are built in: `list_icons` with a few descriptive words (\"growth chart\", \"security lock\", \"team\") finds them by name and tags; set `content_type: \"icon\"` and `content_value: <key>` on the element (an icon list item of `textgrid_vertical_icons`, a `TextAndImage` cell, a step or node marker, a `Picture`). Icons follow the theme's icon style and colors, so they fit without any further work; prefer one icon per item that stands for the item's idea, and keep the set consistent (same level of detail across a list). Pick from the results, never guess a key.\n\n- Where pictures come from is the user's choice, so ask before the first picture of a task, not per slide: one plain question (no tool names) offering their own images (files they share in the chat or that are in their project: when the client lets you read them, you upload them or pass small ones inline, see below), the workspace's Team Assets (its own brand pictures; Team plan), web search (real logos, products, places, people), stock photos, or AI-generated images, limited to what the workspace allows (`list_workspaces`, `permissions.generativeAIImages`, `webImages`, `stockLibraries`, `sharedResources`) and to what you can actually do. Skip the question when their notes already say (a `preferences` note) or the request does (\"use our team photos\", \"no AI images\"), and write their answer to their notes (`write_user_note`) so nobody asks again. When they leave it to you: Team Assets where the workspace has them, web for what must look like itself, stock or AI for generic subjects.\n- To get a picture you do not have, `generate_image_asset` gets one from the source the user chose, the way the app's own generator does, and returns its asset id. `source` \"team\" picks one of the workspace's Team Assets (the user's own brand pictures, headshots and product shots; Team plan), \"web\" finds a web image (for something that must look like itself: a company logo, a product, a real place or person), \"stock\" a stock photo and \"ai\" generates one from a description (give `aspectRatio` matching the slot, and a style when the deck calls for one). Which sources the workspace allows is in `list_workspaces` (`permissions.generativeAIImages`, `webImages`, `stockLibraries`, `sharedResources`); the tool names the sources to use instead when one is not allowed, and when no Team Asset matches, try other words or another source. A web or stock result is one match among several, and a web, stock or ai search that finds nothing gives an abstract image instead, so render the slide and check that the picture fits.\n- To put a picture you already have on a slide, upload it and save it as an asset: `create_upload_url` (with the file's extension) gives a file id and a Cloud Storage upload url; PUT the file's raw bytes to that url, with its content type and nothing else (no authentication; the url is good for 15 minutes, files up to 50 MB); then `save_image_asset` with the file id (`assetType` \"image\" or \"logo\" for a company logo) returns the asset id to put on the slide. One upload per file: the file id is used once. The upload needs outbound access to the domain storage.googleapis.com: when your environment restricts network access to a list of domains and that one is not on it (the PUT fails to resolve the host), skip the upload and give `save_image_asset` the image itself as base64 (`image`), which works for images up to 2 MB; say so to the user when a picture is bigger than that and you have no way to upload it. Any image you can get hold of works: one the user shares in the chat or keeps in their project (the usual choice of a user who has their own material: ask which files go where when it is not obvious), or one you obtain with your own tools (fetched, generated or drawn) when `generate_image_asset` has nothing suitable for the source the user chose; fit it to the purpose (a real logo for a logo slot, a photo or illustration that matches the slide's subject and the deck's style) and prefer images you are allowed to use. Then set `content_type: \"image\"` (or `\"logo\"`) and `content_value: <assetId>` on the image element (the `childElement` of a `TextAndImage` cell, a `Picture`, a logo item, the `image` of a title slide, a tray image); the element documents (`ContentElement.md`, `Picture.md`) and the template's examples show where image elements live and which fields (crop, scale, `aoi*`) they usually carry, which you can leave out. If the element has a `__generateImage` object, remove it, otherwise the app will try to generate an image. Pick an element or template slot whose shape suits the picture (a portrait in a side tray, a wide picture in a full-width cell).\n- When the template has no image slot of its own (a bullet list, a process diagram, a table, ...), put the image in a tray: set `layout.trayLayout` to `left_tray` or `right_tray` (a full-height panel at the slide edge) or `left_inline` / `right_inline` (beside the main element, under the header), and add `states[0].tray` with `trayWidth` (pixels, typically 300–470), a `gridLayout` of one full cell (`cols: 12, rows: 12, cells: [{ x: 0, y: 0, width: 12, height: 12 }]`) and `items: [{ componentType: \"TextAndImage\", cellColor: \"background_accent\", childElement: { content_type: \"image\", content_value: <assetId> } }]`. Templates whose `availableTrayLayouts` is empty (`list_slide_templates`) do not support trays; `SideBarContainer.md` has the full tray model and most templates have examples with an image tray to copy from.\n- Add images on your own initiative when they make the slide better (see the design guidelines: a text-only slide with free space is the typical case), and always when the user asks for them; whether to add one is your call, where it comes from is theirs (above). A picture is for one slide: every slide that gets one gets its own, for its subject (a `generate_image_asset` call or a file of the user's per slide), and an asset that is already on another slide of the deck is not put on this one, a logo excepted (see \"Varied across the deck\" in the design guidelines). When neither `generate_image_asset` nor an image you can get hold of gives a suitable picture, use icons instead or make the rest of the change and tell the user to share the image or add it in the editor, and when switching to a template with image slots prefer one that works without a photo, or leave the slot empty and say so.\n- Render the slide afterwards and check the image like any other content: visible, fitting its slot without an awkward cut, text in front of it readable.\n\n## Splitting a slide into several\n\nWhen the user asks to split a slide (\"split this into two slides\", \"one slide per step\", \"move the last three items to a new slide\"), divide its content over several slides: the existing slide keeps the first part (`update_slide`), new slides get the rest in order (`create_slide` right after it, at increasing positions). Do this only when the user asks for it: when content merely does not fit, shorten it or pick a template that fits it instead, and if a split would be the better answer, say so and leave the deck alone.\n\n- Every slide must read as a complete slide on its own: a title on each (the same title, or with a part number or subtitle, following the deck's conventions), roughly equal amounts of content, no slide with a single orphan item, no item duplicated. Pick the template for each slide by what its part of the content is, not by what the original used: a layout chosen for the full content is often not the best for half of it.\n- Every resulting slide is rendered and checked (step 5) before it is saved.\n- Tell the user how many slides were added, where, and what went on each.\n\n## Combining slides into one\n\nWhen the user asks to combine slides (\"combine this with the next slide\", \"merge slides 3 and 4\"), bring all of their content onto one slide: keep the first one (`update_slide`), then move the others to the presentation's trash with `update_presentation` and a `slideRefs` without them (see \"Removing and restoring slides\"). Save the combined slide before removing the others, so their content is never gone before it is on the combined slide. Do this only when the user asks for it.\n\n- Carry over all of their text, numbers, images and data; nothing is dropped silently. Pick the template that presents the combined content best, whatever the slides used before (two bullet lists become one `textlist` with two columns or a `textBoxGrid`, two statistics slides become one `dashboard`, a list and a chart a `dashboard` with both). Condense wording so the result stays readable, but keep every point; if something really cannot fit, drop the least important item and say so.\n- A combined slide is more crowded by nature: look especially for crammed text and overlapping labels in the render.\n- Tell the user which slides were combined (by number) and that they were removed, and what, if anything, was condensed or left out.\n\n## Removing and restoring slides\n\nA slide of a presentation is either in its deck or in its trash; `get_presentation` lists both (`slideIds` in deck order, `deletedSlideIds` with the last trashed first) and `get_slide` reads a trashed slide like any other (its `slideNumber` is null). The deck given to `update_presentation` (`slideRefs`) decides where each slide is: a slide left out goes to the trash, a trashed slide put in comes back. Nothing is deleted for good through the tools: the app empties the trash after 30 days.\n\n- Always send the whole deck, built from the `slideIds` of a fresh `get_presentation` with only the intended change, never from memory: whatever is missing from it is trashed. The result names the slides that moved (`trashedSlideIds`, `restoredSlideIds`); if one moved that should not have, put it back with another `update_presentation` right away.\n- Removing: a `slideRefs` without the slide. Only when the user asks for a slide to go, or when a workflow calls for it (combining slides, a placeholder a new deck ends up not needing); tell the user the slide went to the trash and can be put back.\n- Restoring: a `slideRefs` with the slide at the position the user wants. When the user asks what the trash holds, read the trashed slides with `get_slide` and describe them.\n\n## Adding slides\n\nWhen the user asks for new slides (\"add a slide about the Q3 results\", \"add two slides: risks, then next steps\"), build each from their instructions, taking what they do not specify from the deck (`get_presentation`, the neighboring slides) so the new slides match its tone, wording, number formats and title style and do not repeat what another slide already says. Pick the template per slide by its content and its neighbors (slide-templates skill: not a template that would make three in a row when another fits), give it a picture of its own where one belongs (not one already on another slide), build the model as in the workflow (steps 2–5), then `create_slide` at the right position. One idea per slide, text as concise as the deck's; when the user does not say how many slides, make as many as the content needs, usually one. Several new slides go in one `create_slide` at a time, in deck order, each after the previous one has returned: calls sent together land in no fixed order, and one can be refused because the deck changed under it (the answer says the slide was not added; call it again).\n\n## Reordering, renaming, theming, linking, sharing and exporting presentations\n\n- `update_presentation` renames a presentation (`name`), reorders its deck (`slideRefs`: slide id -> position; only the order matters), moves slides between the deck and the trash (the same `slideRefs`, see \"Removing and restoring slides\") and changes its theme (`theme`: the theme attributes to change, or `sharedThemeId`: a shared team theme to switch to).\n- Changing a presentation's theme: `get_presentation_theme` gives the current theme model; `update_presentation` with `theme` applies the attributes you give on top of it (brand colors in `colors`, fonts in `fontHeaderFontId` / `fontTitleFontId` / `fontBodyFontId`, the look in `styleShape`, `styleElementStyle`, `iconStyle`, ...; an object like `colors` is merged one entry at a time, everything else is replaced). To give an existing presentation the look of a built-in theme, take that theme's model from `list_themes` and send it as `theme` (all of it, or just the parts the user wants). Do this only when the user asks for a different theme or look, and where the workspace's brand guardrails allow it (see below): it changes every slide of the deck at once (the slides' own background choices stay), so render one or two slides with the changed theme first (`render_slide` with `theme`) and check them like any change, and tell the user the whole deck changed. A presentation on a shared team theme becomes its own copy of that theme with your changes; say so before doing it.\n- Switching a presentation to a shared team theme: `list_shared_themes` for its workspace gives the team's shared themes (its Shared Brand Kits) the user may use (each with its raw model, to render a slide with it first), and `update_presentation` with `sharedThemeId` puts the presentation on one: it follows that theme from then on and its own theme attributes are dropped, every slide re-rendered. As with any theme change, only when the user asks for it, and tell them the whole deck changed. Theme attributes (`theme`) and a shared theme (`sharedThemeId`) cannot be sent in the same call.\n- Brand guardrails: whether the workspace allows themes of a presentation's own is in `list_workspaces` (`permissions.customThemes.use`). Where it does not, theme attribute changes and built-in themes are refused and every presentation uses one of the shared themes (switching between them with `sharedThemeId` is still allowed). When the user asks for a different look there, tell them their workspace's brand guardrails keep every deck on the team's Brand Kits, offer the other shared ones if there are any (by name), and say that a workspace owner would have to change the Brand Kit itself or the guardrails for anything else.\n- Creating a presentation (`create_presentation`, with `list_shared_themes` / `list_themes` for its theme) and building its deck is covered by the presentation building skill (see \"The reference skills\").\n- `get_presentation_links` gives the editor url (optionally opened on a slide, by its 1-based number) and the player url of a presentation; the editor needs the user to be signed in to an account with access, the player shows the deck as the audience sees it.\n- Sharing, only when the user asks to share a presentation, and the way they ask for: `create_public_link` (a named link anyone can open; it makes the presentation public), `create_password_protected_link` (a named link whose viewers enter a password the user chooses), or `share_presentation_with_user` (one person by email, with `view` or `edit` access and an optional note for the email they get; a person without a Beautiful.ai account gets an invite that grants the access when they sign up). What each needs: every option needs edit access to the presentation (a viewer cannot share); a password-protected link also needs `permissions.securedSharing` in the workspace (`list_workspaces`; not in the Basic plan, so offer a public link or sharing with a person there); sharing with a person also needs the right to manage the presentation's sharing, which its owner has and editors usually do, and which only the tool can tell: when it refuses, say the owner has to share it; and sharing with a person is limited to the workspace's members when `permissions.externalWorkspacesCollaboration.use` is false (the Team Owner has disabled collaboration outside the workspace), so tell the user that then. The two kinds of link exclude each other: a presentation is either public (public links work) or secured (password-protected links work), and creating one kind switches it, so when the result lists links that no longer work, tell the user. Ask for what the tool needs and the user has not given (the link's name, the password, the email, view or edit) rather than inventing it, never make up a password, and give the user the link url on its own; do not repeat a password back beyond saying it is set.\n- `export_presentation` gives a file when the user asks for one (\"send me the PDF\", \"export to PowerPoint\"): a `pdf`, or a `pptx` with one picture per slide, or an editable PowerPoint (`editable: true`) where the workspace allows it (`list_workspaces`: `permissions.exportPresentation` for any export, `permissions.exportPresentationToEditable` for an editable one; when the user wants an editable deck and the workspace does not allow it, say so and offer the picture-per-slide one). The file is produced in the background and the tool waits for it; when it answers that the export is still running (a large deck), call it again a little later with the same arguments. It returns a download link that is valid for 5 minutes only (`expiresAt`): give it to the user at once and say that it expires, and get a fresh one with the same call if they come back for it.\n\n## Advice\n\nWhen the user asks for your opinion rather than a change (\"what would you improve here?\", \"is this too crowded?\", \"should I split this?\", \"is this slide needed?\"), review properly before answering: render the slide, read its model, read the deck and render the neighbors and any slide on the same topic, and judge content, density, template fit, duplication with other slides, consistency with the deck and readability. If you recommend a different layout, split or combination, build and render the alternative first and recommend only what came out well, and describe what it looks like (the rendered alternative is for you to judge; the user cannot see it until it is saved). Answer the question, then give the two to four most valuable recommendations, each concrete and phrased so the user can ask for it as a change. Change nothing in an advice request.\n\n## Knowledge base and user notes\n\nTwo sets of markdown notes, one topic per note, both written and maintained by the agents:\n\n- The **shared knowledge base** (`list_shared_knowledge_notes`, `read_shared_knowledge_note`, `write_shared_knowledge_note`) is common to every agent working with Beautiful.ai: anything about the app an agent had to figure out. Its purpose is to make discovery cheap for the next agent: every lookup you had to do (an example, a template's default data, why a render failed) is one the next agent should not have to repeat. Record: the model shape of a template or element (the fields that matter, allowed values, a minimal snippet), a template's rules and limits, which examples are good references and why, a renderer error with its cause and fix, a layout trick that made the slide look good, how much text fits where, a dead end to avoid, a tool's quirk. Record failures too. Write only about Beautiful.ai (models, templates, tools, rendering, behavior). **Never leak user-related data into shared notes**: every agent of every account reads them, so nothing from the user's slides or messages (names, companies, products, numbers, text), nothing about the user themselves (preferences, brand, audience), no presentation, slide or asset ids, no workspace or account details may appear in them, not even as an example; make examples up from neutral placeholder content. Anything about the user belongs in their notes.\n- The **user's notes** (`list_user_notes`, `read_user_note`, `write_user_note`) are private to the user you work for and are where everything about them goes: their preferences (tone, language, amount of text, favorite templates and themes, where their pictures come from, what they dislike), their company, products and brand (colors, fonts, logo asset ids), their audience and recurring subjects, corrections they made to your work, and anything they ask you to remember. Read them at the start of every task so the slides fit the user without asking again; write them as you learn (a stated preference, a correction, a fact), under small topics such as `preferences`, `brand`, `audience`, `company`. Never store secrets or credentials in them.\n\nRules for both: write notes generously, as you go (if you had to look something up or the user had to tell you something, it is worth a note). One topic per note, named as a lowercase slug with hyphens (`table-cell-colors`); prefer small, specific topics (`textlist-column-layout` over `textlist`). When a note on the topic exists, read it and extend or correct it rather than creating a near-duplicate (writing replaces the content); remove what you have proven wrong. Keep notes factual and compact (a title line, then bullets or a minimal snippet, usually well under 40 lines).\n\n## Rules\n\n- Never save (`update_slide`, `create_slide`) a model you have not rendered with `render_slide` and visually checked after your last edit against the design guidelines: all text readable with good contrast, no overflow, no crowded text or overlapping labels, no large empty area, something to look at, the slide coherent and good looking. The user sees every save immediately. The only models saved unrendered are the `ai-generation` placeholders `create_presentation` starts a new deck with (see the presentation building skill): they have no content to check.\n- Keep everything of a model you did not mean to change: other fields, element ids, existing images.\n- Add slides only when the user asks to split a slide, to add slides or to build a presentation; remove slides from a deck only when the user asks to combine or remove them (or a placeholder of a deck you are building is not needed), and bring slides back from the trash only when they ask for it. The slide the user is working on is never removed.\n- Change only the slides the request is about; say so when the request would need changes elsewhere.\n- If the request cannot be fulfilled or is too ambiguous to act on (after checking whether the deck makes it clear), change nothing and explain why, or ask one precise question.\n- Keep your messages to the user short and about their slides: what you changed, what you decided, what remains. No file paths, model internals or tool names; use the app's words for things (a theme is a Brand Kit to the user). When the user wants to see a slide or the result of a change, open the presentation in the chat (`open_presentation`) or give the editor link.\n"
}