Deck prompt in four gates
Turns a deck request into a stand-alone prompt for an AI slide generator, with approval before writing.
When to use it: Whenever you build slides with Claude Design or another AI slide generator and want fewer rebuilds.
Save it as deck-prompt/SKILL.md
--- name: deck-prompt description: Use when preparing, writing or revising a prompt that an AI slide generator (such as Claude Design) will turn into a deck, or when the user shares a delivered deck to learn from. --- # Writing a deck prompt for a slide generator This skill is the workflow. It is not the rulebook. Keep your rules (voice, slide types, things the generator renders differently from what you asked) in files in the workspace and read them fresh every time, because those files are also what gets pasted into the generator. A rule written here instead of there would apply to the assistant and not to the generator, which is how the two drift apart. A new deck goes through four gates in order: design system, questions, outline approval, final prompt. Do not skip ahead. Writing a full prompt on a misread task costs a rebuild in the generator. One round of questions costs a minute. **Exception.** A small revision to an existing prompt (wording, one slide, a carried-over edit) skips gates 2 and 3. A revision that changes the structure, the format or the angle goes through all four. --- ## Gate 1. Establish the design system Nothing else starts until you know which design system or template the deck uses. If the session folder, the project instructions or the user's message does not settle it, ask. Then read, fresh every time: - The rule files for that design system: [your voice and slide-copy rules file], [your slide types file], [your "what the generator renders differently" file]. - The project instructions and the status file, if there is one. - The session's `outline.md` if one exists. It is the source of the content. The prompt is a rendering of it. - The previous deck's `delivered.md` and prompt file in the same series. `delivered.md` says what actually happened last time. **Carry over any edits the user made by hand in the generator** after the last build (footer, speaker role, about slide, QR code). Build them in up front instead of making the user repeat them. ## Gate 2. Ask before outlining Ask only what the files do not already answer, in one round, at most four questions, recommended option first. Typical gaps: - **Format.** Talk, talk with live demos, or hands-on blocks. Laptops and tools open or closed. This decides the whole shape of the deck. - **Angle and boundaries.** What the deck is about and what it must not become (for example, not centred on one tool, not a tool tour). - **Continuity.** What the audience heard last time and what the previous deck promised. - **Title.** The user's own, or one you propose. - **Real material.** Sourced figures, quotes, screenshots or images the user will supply. Without them the deck has no big-number, chart, quote or image slides. Do not ask about logistics that do not change the deck, such as the start time. If the user says "no input, go", take the most reasonable reading, state it in one line at the top of the outline and continue. ## Gate 3. High-level outline for approval In the chat, not in a file. Short enough to read in a minute: - Title and subtitle. - Thesis in one sentence. - The parts, as they will read on the agenda and the section slides. - The slide list, one line each: number, slide type, headline. - Assumptions and anything unverified, one line each. Then stop and wait for approval. Apply changes to the outline, not to a prompt that does not exist yet. ## Gate 4. The final prompt After approval, write `outline.md` and `deck-prompt.md` in the session folder. **The shape of `deck-prompt.md`.** Two parts, split by a `# PASTE FROM HERE` line. - **Above it, authoring notes that are never pasted.** Version and date. Deviations from a standing rule and why, flagged loudly. Facts that specific slides depend on, with the date they were verified and the slide numbers. Anything to verify before the build. Which slides are deliberately long-form. Anything about the room: onsite or online, projector or laptops, what the audience already knows. - **Below it, the pasted prompt,** inside one code block. It must stand alone in a fresh generator conversation with no other context: the design system's copy and voice block, any series parameters, the constraints, the slide-by-slide specification, then a pre-export checklist. **Headline pass.** Go back through every headline once and read each one aloud as if standing in front of the room. Rewrite anything you would not actually say to a person. The failure to hunt for is the slogan fragment: no verb, commas chopping it into rhythm beats, a colon setting up a payoff. **Density check.** A concept, comparison or key-takeaway slide with no prose line is under-written. A demo, exercise or section-divider slide with one is over-written and competes with what is on the screen. **Mechanical checks before handing over.** No two slides of the same type adjacent. The slide count matches the spec. No empty slot left for the generator to invent. [Add your own, for example: no em or en dashes.] **Delivery.** As a file, with its path. Not as a long block pasted into the chat. --- ## Where a new rule goes When the user corrects something, or a delivered deck teaches something, write it into the workspace rather than into this skill. - A rule about wording, voice or how much a slide says goes in the voice rules file. Add it to the existing rule it belongs to rather than creating a new one. Date the change and name whose call it was. - If the rule has to reach the generator, it also goes into the block that gets pasted. A rule that is not in the block does not reach the generator. - Something the generator renders differently from what was asked goes in the rendered-conventions file for that design system. - Something true only of one series or one audience goes in that series' folder. - If a rule was worded badly, fix the rule. Do not add a "common mistakes" entry for it. Update this skill only when the *process* changes, not when a rule does. ## After delivery Every delivered deck leaves a `delivered.md` written the same day: what was shown, what changed live, what to change next time. Prompt the user for it rather than waiting to be asked. Export the delivered deck as a PDF into the series' `delivered/` folder. Diff it against its `deck-prompt.md` and add anything new to the rendered-conventions file.