Most bad decks aren't badly designed. They're twenty slides of accurate material with the point somewhere on slide fourteen, and everyone in the room working out what they're supposed to think about it.

So the useful thing isn't a tool that makes slides look nice. It's one that settles what you're actually arguing first, builds from your own material rather than inventing supporting detail, and puts the conclusion where people will see it.

Agree the story before anything gets designed

The expensive mistake is building forty slides and then discovering the argument doesn't hold. So the narrative comes first: who's in the room, what they need to decide, and what a good outcome actually looks like.

You get a plan for the story and sections before the design starts, which is a much cheaper place to change your mind. If you have a past deck that landed well, or a template and brand you work to, those calibrate the structure and visual standard. They're useful, not required.

Want to try it?

Ask your Strawberry companion: “Turn this accepted research brief into a polished, source-grounded slide deck.”

Skill

Turn an accepted brief into a beautiful deck

Turn this material into a deck. Start with the narrative.

Built from your material, not around it

The failure mode people worry about with AI decks is the confident slide with nothing behind it. A result nobody measured, a customer quote nobody said, a market size that sounds about right.

The workflow is built to head that off. Claims, results, and evidence come from what you provide, and where the material is thin the gap is surfaced rather than smoothed over with a plausible-looking number. Facts stay distinguishable from interpretation, and anything the deck cannot support is flagged rather than filled in.

For a board, investor, or client deck, the source links and dates stay attached to the claims that matter, so someone can check the slide that decides the meeting.

Lead with the finding

For anything that asks a room to decide something, the conclusion goes first and the evidence follows. Not a build-up, not a tour of the analysis. The audience should know what you think by slide two and spend the rest of the time interrogating it.

Each slide gets one job. Screenshots, product images, logos, and charts earn their place when they make the argument land harder than a sentence would, and get left out when they're decoration.

Responding to an RFP or a proposal works differently. There the requirements get mapped explicitly to the deck, so nothing in the brief quietly goes unanswered.

Review it before it leaves the building

The finished deck gets checked for the things that embarrass you in a meeting: an argument that stops making sense in the middle, text too small to read from the back, inconsistent styling, a claim nothing supports.

Anything going to a client, board, or investor waits for your approval before it's sent. And once the structure, voice, evidence standard, and visual direction are right, they can be saved so the next deck starts from your way of doing this rather than a blank file.

Official Strawberry skill
Copy skill file Download skill file

Create a Beautiful Slide Deck

This is a starter skill for turning source material into a narrative presentation. Adapt it to the user's audience, purpose, voice, and existing way of working rather than treating it as a fixed template.

Context, setup, and planning

Try to understand:

  • who will see the deck, what decision or action it should support, and what a good result looks like;
  • the source material, required sections, length, deadline, and intended presentation or export format;
  • the visual direction and brand, including any existing template or reference the user wants to follow.

When available and relevant, past accepted or winning decks, proposals, reports, discovery notes, and brand materials can calibrate the structure, language, evidence, and visual standard. They are not prerequisites.

For research-heavy, board, investor, proposal, or client decks, agree on the core question, evidence standard, and definition of done. Preserve useful source links and dates, distinguish facts from interpretation, and surface uncertainty rather than polishing over missing evidence.

Establish the narrative before designing slides. Present a concise plan for the story, sections, and visual direction so the user can correct the approach before the full deck is built.

Execution

  1. Inside Strawberry, read and use the internal strawberry/general/visual-artifact skill installed by the Strawberry harness for deck creation, critique, and export; it is not part of this public repository. Outside Strawberry, use the environment's presentation tooling and preserve the same narrative, visual critique, and export review.
  2. Build around the user's specifics and source material. Remove information that does not serve the audience, and do not invent claims, results, familiarity, or evidence.
  3. For decision, pitch, or report decks, lead with the conclusion or finding, then show the evidence and implications in plain language. Use relevant approved visuals such as screenshots, product images, logos, or charts when they strengthen the story.
  4. For proposals or RFP responses, map explicit requirements to the deck so important sections are not missed, and use relevant past case studies or team material when available.
  5. Review the complete deck for narrative flow, accuracy, legibility, visual consistency, source quality, unsupported claims, and whether it meets the agreed definition of done.
  6. Keep the deck reviewable. If it is intended for a client, board, investor, or other external audience, get the user's approval before delivering or sending it.

Suggested outcome

Deliver a polished, coherent visual slide deck ready to present or export. The deck—not an outline or wall of text—is the primary output.

Suggested next steps

After the user has reviewed the deck, incorporate their edits and offer the appropriate export. When the structure, voice, evidence standard, or visual direction will be reused, save the accepted process and concrete preferences as a user-owned skill.