skills-marketplace/plugins/common/skills/prepare-presentation/SKILL.md

---

name: prepare-presentation description: Use this skill whenever a user asks to prepare, build, put together, or create a presentation, pitch deck, slide deck, or board of slides from scratch or from raw material. Trigger on requests like "help me build a presentation about X", "I need a deck for the board meeting", "can you put together slides on Y", "make me a presentation", "turn this into a deck", or mentions of Miro boards, Google Slides, PowerPoint decks, or slide decks in a planning context — even if the user hasn't gathered their source material yet or named a tool. This skill runs BEFORE any slide-building tool: it gathers source material (links, text, documents, a folder, or an interview), clarifies purpose/audience/focus, and agrees a plan with the user before anything gets built. Do not use it when the user already has finished, ready-to-build content and just wants a file produced (e.g. "turn this outline into a pptx") — in that case go straight to the matching build skill (pptx, docx, etc).

Prepare presentation skill

Purpose

Turn scattered source material and a business goal into a presentation. The failure mode this skill exists to prevent is jumping straight to slide-building before anyone has agreed what the presentation needs to say, to whom, and why. Source gathering and planning come first; the tool-specific build happens last, and mostly by handing off to other skills rather than reinventing them.

How this fits with other skills

This skill does not do its own document extraction or slide rendering — it orchestrates:

• interview skill's technique (funnel questions, paraphrase-confirm, embrace silence) — reused inline in Step 1 when the source is an interview, and in Step 2 for requirements gathering.
• pdf / docx / xlsx skills — for extracting source content when the material arrives as a document.
• pptx skill — for actually building a PowerPoint file, and as the fallback build target for any tool that can import .pptx (Google Slides, Keynote).

Read those skills' own instructions when you reach the step that needs them rather than re-deriving the approach here.

Workflow

Step 1 — Establish the source material

Ask: "Where should the content for this presentation come from?" Offer this is not an exhaustive list — links, pasted text, one or more documents, a local folder of material, or an interview where you ask the user questions to extract what they know. Sources can be combined (e.g. a couple of links plus a short interview to fill gaps).

Handle each kind as it arrives:

• Links — fetch and read them, extract the facts relevant to a presentation, and keep track of which claim came from which link so it can be cited later if needed.
• Pasted text — use it directly as source material.
• Documents (PDF, Word, Excel, an existing deck) — use the matching skill (pdf, docx, xlsx, pptx) to extract text or data rather than trying to parse the file yourself.
• A local folder — list what's in it first. If it's small, read the relevant files directly. If it's large enough that reading everything would blow the context budget, delegate the read-through to the Explore agent and have it report back what's relevant.
• An interview — conduct it the way the interview skill does: one question at a time, funnel from broad to specific, paraphrase back what you heard before moving on, embrace a short pause after each answer rather than rushing to the next question, and close with "is there anything else you'd want covered that I haven't asked about?" before calling it done.

Once all source material is in, summarise back to the user in a few sentences what you now have, so they can correct or add before you move on.

Step 2 — Clarify purpose, audience, and focus

Ask these one at a time, waiting for each answer, funnel-style (broad first, narrowing down):

1. Purpose — what should this presentation achieve? Inform, persuade, secure a decision or budget approval, train, report progress?
2. Audience — who is it for? Their role, seniority, and how familiar they already are with the topic changes both the content and the level of detail.
3. Focus — should it emphasise one specific angle or aspect of the source material, or cover it broadly?
4. Explicit callouts — is there anything that must appear, be emphasised, or be stated outright — a number, a risk, a decision being asked for, a required closing slide?

Paraphrase the four answers back as a one-line brief before moving on, e.g. "So this is a persuasion deck for the board, focused on cost savings, and it needs to call out the Q3 budget risk explicitly — is that right?" Don't proceed to planning until the user confirms.

Step 3 — Draft the plan and iterate on it with the user

Do not skip to building slides. Draft an outline first: a numbered list of sections/slides, each with a working title and a one-to-two sentence key message. Size the outline to the purpose and audience from Step 2 rather than a fixed number — a board deck typically wants to stay tight (roughly 8-12 slides), a training deck can run much longer.

Present the outline and ask directly: "Does this structure work, or should we reorder, add, cut, or re-emphasise anything?" Treat this as a genuine back-and-forth — actually revise the outline based on what the user says, don't just restate it and assume approval. Only move to Step 4 once the user affirms explicitly ("looks good", "approved", "yes, build it").

If the plan gets rejected across two or three rounds without converging, stop iterating on details and ask an open question about what isn't working yet, rather than continuing to guess.

Step 4 — Choose the tool and build

Ask which tool to build it in: "PowerPoint, Google Slides, and Miro are common choices, but tell me if you'd rather use something else." Treat the list as illustrative, not exhaustive.

Ask about a template too. Once the tool is chosen, ask: "Do you have a template you'd like this to follow — an existing presentation or file whose look and structure I should model this on, or a written spec (brand colours, fonts, section layout, a house style guide)?" Make clear the template doesn't need to be the same kind of artefact as the output — a Miro board can follow the style of a PDF brand guide, a PowerPoint deck can follow the structure of a previous Google Slides deck, a plain text description of "dark background, one big stat per slide, section dividers between chapters" counts too. If the user supplies a file, read it with the matching skill (pptx for an existing deck, pdf/docx for a style guide) to pull out what's reusable — colours, fonts, layout patterns, section structure — rather than its literal content, unless the user says the content itself should carry over.

Pass whatever template guidance you gathered into the build step below, alongside the accepted outline.

MCP must be connected in the current session for a tool's connector to be usable — this is a hard requirement, not a preference. Check the actual list of connected/available tools in this session directly (do not assume based on what worked in a previous session, and don't take the user's word that it's "usually connected"). If the connector for the requested destination isn't connected right now, treat it as unavailable for this run and use the fallback below — don't stall waiting for it. Tell the user plainly that the fallback is being used because MCP isn't connected this session, and that they can authorize it via their MCP/connector settings if they want direct creation next time.

• PowerPoint (.pptx) — hand the accepted outline, plus any design/emphasis notes from Step 2 and any template gathered above, to the pptx skill and let it build the file. If a template file was supplied, that's exactly the "edit from a template" workflow the pptx skill already documents — use it rather than building from scratch.
• Google Slides — if no Google Slides connector is available, build the deck as a .pptx via the pptx skill instead, carrying the template guidance the same way: Google Slides imports .pptx natively (File > Import slides, or opening the file directly from Drive). Say plainly that this is a workaround, not a native export.
• Miro — if no Miro connector is available, produce a structured board plan instead of a file: one frame per section, one sticky note per key point, in the reading order from the accepted outline, styled after whatever template guidance was given, written out as a markdown or CSV list the user can bulk-import or build from manually. Say plainly that direct board creation isn't wired up currently.
• Keynote — build as .pptx via the pptx skill; Keynote opens .pptx files directly.
• Anything else — use whichever existing skill matches the requested output format most closely (e.g. docx for a Word-based handout), or ask the user what file format would actually work for them if nothing matches.

Whatever gets produced, tell the user exactly what was built, where the file is, and any manual step still needed on their end (e.g. "import this into Google Slides via File > Import slides").

Proactive rules

• If the user arrives with a complete, ready-to-build outline and just wants a file produced, skip straight to Step 4 rather than re-running source-gathering and planning they've already done.
• If the gathered source material is thin, say so before drafting the plan rather than padding the outline with filler to hit a slide count.
• Keep the plan itself in the conversation (not a saved file) unless the user asks for it in writing — the deliverable is the built presentation, not the outline document.