Update to Beautiful.ai

{
  "description": "Build a whole Beautiful.ai presentation from scratch with the Beautiful.ai MCP tools - outline, theme, creating the presentation as a deck of placeholder slides, opening it for the user and filling the placeholders with the generated slides. Use when the user asks for a new deck or presentation; for changes to existing slides use the slide editing skill.",
  "included_files": [],
  "name": "beautiful-ai-presentation-building",
  "skill_md_contents": "---\nname: beautiful-ai-presentation-building\ndescription: Build a whole Beautiful.ai presentation from scratch with the Beautiful.ai MCP tools - outline, theme, creating the presentation as a deck of placeholder slides, opening it for the user and filling the placeholders with the generated slides. Use when the user asks for a new deck or presentation; for changes to existing slides use the slide editing skill.\n---\n\n# Building a Beautiful.ai presentation\n\nWhen the user asks for a whole presentation (\"make me a deck about X\", \"a 10-slide pitch for ...\", \"turn these notes into a presentation\"), you create the presentation with a placeholder for every slide of the outline, then build the slides one by one into their placeholders. The slide work itself (model, render, check, save) is the slide editing skill's workflow; this skill is about the deck: what goes in it, in which order, and how to keep the user in the loop while it takes shape.\n\n## The other skills\n\n- **Slide editing** (`beautiful-ai://skills/slide-editing`): the workflow for every slide you build (notes, element reference, build, render and check, save, notes), the tools, and the rules. Each slide of the deck goes through it.\n- **Slide templates** (`beautiful-ai://skills/slide-templates`): which template fits which content; pick the template of each slide with it.\n- **Slide design** (`beautiful-ai://skills/slide-design`): what makes a slide look good and the checklist to run on every render; the deck is only as good as its slides.\n- **Slide elements** (`beautiful-ai://skills/slide-elements`): the model reference for the elements you write.\n\n## Steps\n\n1. **Settle the outline first.** Read the user's notes first (`list_user_notes`, `read_user_note`): their preferences, brand, audience and past decks decide much of what follows (tone, language, theme, how much text, what to avoid), so you ask less and get it right the first time. Then the slides, one idea each, in a sensible order: a title slide, the story (context, problem, solution, evidence, plan, ...), a closing or next-steps slide. Decide the deck's tone and how much text a slide carries, and for each slide its template (the slide templates skill) and what it needs beyond text (a chart, a table, a picture, icons). Pick the templates for the deck as a whole, not one slide at a time: a deck whose slides all look alike (the same template and layout slide after slide) is the most common way a generated deck disappoints, and the user expects variety without asking for it. Two neighboring slides on the same template are fine when their content calls for it; what to avoid is many slides that look identical: a run of three or more on the same template, or a template on more than about a third of the deck. When a template would repeat that much, give one of the slides the alternative the templates skill lists for that content or restructure it; when it repeats at all, plan a different layout for the two so they do not come out identical (see \"Varied across the deck\" in the slide design skill). Plan the pictures the same way: which slides get one, what each shows, and each its own. Ask only when the request leaves out something you cannot decide well yourself (the audience, the number of slides, must-have content) and for the two things that are the user's call: where the deck's pictures come from (their own images, the workspace's Team Assets, the web, stock photos or AI; see the editing skill's images section), and, when the workspace has shared themes (step 2), which Brand Kit (the user's word for a theme) to use, naming the team's default one as the default and, where the workspace's brand guardrails allow only shared themes, saying so; unless their notes or the request already say. Ask everything in one message, before creating the deck, and decide the rest yourself and tell the user what you assumed. When the user does not say how many slides, make as many as the content needs: typically 6–12, one idea per slide, no filler.\n2. **Pick the theme.** To the user a theme is a **Brand Kit** (the app's name for it; \"theme\" is the tools' internal name for the same thing), so that is the word to use with them. First `list_shared_themes` for the workspace: these are the team's own Shared Brand Kits (the tool answers with an error where the user may not use shared themes). When there are shared themes, the user decides: ask them, in the outline message of step 1, naming the shared themes, the default one first and as the default (\"your team's default Brand Kit, X, unless you prefer another\"), unless their notes or the request already say. Whether a built-in look is an alternative depends on the workspace's brand guardrails (`list_workspaces`, `permissions.customThemes.use`): where custom themes are not allowed, built-in themes are out and the deck has to use one of the shared themes, so say so in the same question (\"your workspace's brand guardrails keep decks on the team's Brand Kits\") and do not offer a built-in look; otherwise offer it. A shared theme is the usual choice of a team that has them; a deck on it follows the theme when the team updates it. For a built-in look (the user's choice, or a workspace without shared themes), `list_themes` lists the built-in themes (palette, fonts, style); choose the one the user's notes name, else what the user asked for (\"something dark and modern\") or one that fits the subject and audience; Classic is the safe default. Either kind comes with its raw theme model (`list_shared_themes`, or `list_themes` with the id), which lets you render a slide with it (`render_slide` with `theme`) when you want to see it before deciding.\n3. **Create the presentation as a deck of placeholders.** `create_presentation` takes a name that says what the deck is about, the workspace id from `list_workspaces` (ask which one when the user has several and the request does not say), the theme (`sharedThemeId` for a shared theme, `themeId` for a built-in one) and `slides`: one placeholder model per slide of the outline, in deck order. A placeholder is `{ \"template_id\": \"ai-generation\", \"states\": [{}], \"metadata\": { \"isGenerating\": true, \"slidePrompt\": \"<one line: what this slide will say>\" } }` plus the version fields of any new slide model (`Slide.md` in the elements reference); it has no content to render or check. In the editor every placeholder shows \"Generating slide...\" until you replace it. The tool returns the presentation id, `slideIds` in deck order (the n-th id is the n-th slide of your outline) and the editor url: keep the ids, they are the slides you are about to fill.\n4. **Open the deck for the user.** Right after creating it, call `open_presentation`: in a client that renders MCP Apps the app appears in the chat with a button that opens the editor fullscreen, showing the whole deck as placeholders that turn into finished slides as you save them. In the same message give the editor link (`editorUrl`, from `create_presentation` or from `open_presentation`'s result) and recommend it: the editor open in its own browser tab next to the chat is the better way to watch the deck being built (it updates live as you save, and the conversation stays visible, which it does not while the in-chat editor is fullscreen); the button in the chat is the alternative. The link is also all a client that does not render apps shows, and the fallback if `open_presentation` fails. Say that the deck is being built and will be ready in a few minutes.\n5. **Fill the placeholders** with `update_slide`, in deck order, each slide built, rendered and checked as in the slide editing workflow. The first is the title slide: a `title` template slide, kept simple (the presentation title and, when the request gives them, a subtitle and the presenter or date; no pictures or extras unless the user asked; `PresentationTitle.md` in the elements reference, a `title` example). For every slide, `update_slide` on its id from step 3 with the full model: `template_id`, `states`, `layout`, the version fields, and `metadata` with `isGenerating: false` (it replaces the placeholder's metadata; a slide left with `isGenerating: true` keeps showing as generating in the slide navigator and gets no thumbnail). There is no need to read a placeholder first (`get_slide`): it has nothing to keep. Render with the presentation's theme (`render_slide` with `presentationId`). Never `create_slide` for a slide of the outline: its placeholder already exists. Keep each slide consistent with the ones before it in style (the same title style, wording, number formats, icon style and level of detail, no two slides saying the same thing) and different from them in structure: build it on the template and layout the outline gave it, and when it ends up on the same template as the slide before it, make it look different before saving (the other tray side or none, the other header position; the alternative template when it would be the third in a row). Give slides visuals where the design guidelines call for them, from the source the user chose in step 1, and get every slide its own picture: one `generate_image_asset` call (or one of the user's files) per slide that gets one, for that slide's subject. An asset that is already on a slide of the deck does not go on another; a logo is the one exception.\n6. **Finish.** No placeholder may be left: a slide that did not come out well is saved in its best working version, and a placeholder you end up not needing is moved to the trash (`update_presentation` with a `slideRefs` without it, see \"Removing and restoring slides\" in the editing skill). Tell the user what the deck contains (one line per slide is plenty) and what you assumed, and give the links again (editor and player, `get_presentation_links`); the open editor already shows the finished deck, so do not open it a second time. Leave notes as the editing skill asks: what you learned about the app in the shared knowledge base, what you learned about the user (the deck's subject and audience, where their pictures come from, choices they confirmed or corrected) in their notes.\n\n## Rules\n\n- The user gets to see the deck (the editor link, recommended for its own tab, and the editor in the chat where the client renders apps) right after it is created, as placeholders that fill in one by one, not at the end.\n- The presentation is created with a placeholder (`template_id` `ai-generation`, `metadata.isGenerating: true`) for every slide of the outline, and each one is replaced in place with `update_slide` on its id, with `isGenerating` cleared; no placeholder is left behind and none is duplicated with `create_slide`. The first slide is a simple `title` slide, the only title slide of the deck.\n- Every slide is rendered and checked before it is saved (the placeholders are the one exception: they carry no content); a slide that does not come out well after the attempts the editing skill allows is saved in its best working version and mentioned to the user, not silently dropped.\n- The deck is varied without the user asking for it: no run of three or more slides on the same template, no template on more than about a third of the deck, no two neighboring slides with the same template and the same layout, and every picture on one slide only. This is planned in the outline and checked on every slide before it is saved.\n- Build the slides the user asked for and nothing else; when the content is too thin for the number of slides asked, say so and make fewer rather than padding. Settle the count in the outline, before the placeholders are created; a placeholder that turns out unnecessary is removed from the deck, not left as it is.\n"
}