agentleFS
Williamunpalatable7706Williamunpalatable7706/ai-life-skills-toolkit/skills/core/build-effective-powerpoint-decks/SKILL.md

build-effective-powerpoint-decks

Skill0 starsChanged 2 months agoMITView on GitHub

Create, improve, or review PowerPoint decks a real audience can follow, with one clear job per slide, readable text, meaningful visuals, restrained design, and deliberate pacing. Use for slide-deck requests that must inform, persuade, teach, or support a speaker, including self-contained leave-behind decks.

The file

Show its rules and text

We split this skill into the rules it gives an agent

20 rules. About 0 are common, 20 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈20

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Create an editable deck that helps a specific audience follow and remember the message.

    line 8
  2. Distinctive:

    When authoring or editing an actual deck, also follow the presentation-file skill if this assistant has one.

    line 10
  3. Distinctive:

    Use available context and safe, reversible defaults before asking for input.

    line 16
  4. Distinctive:

    Before planning, determine from the request and supplied material:

    line 23
  5. Distinctive:

    must-use facts, brand/template constraints, and source material.

    line 29
  6. Distinctive:

    Ask only for consequential missing information.

    line 31
  7. Distinctive:

    Write a plain-text story outline before choosing visuals or polishing slides.

    line 35
  8. Distinctive:

    Put the top-level takeaway on the slide as a short, memorable phrase.

    line 37
  9. Distinctive:

    Create a slide map with, at minimum: slide purpose, audience takeaway, visible copy, supporting evidence, visual role, speaker-note detail, …

    line 41
  10. Distinctive:

    Prefer phrases, labels, and keywords over full sentences for ordinary live slides.

    line 45
  11. Distinctive:

    Do not apply "minimal text" blindly.

    line 46
  12. Distinctive:

    Keep the speaker's words complementary to the slide.

    line 48
  13. Distinctive:

    When points must unfold in sequence, reveal or separate them in the same order the speaker discusses them.

    line 49
  14. Distinctive:

    Use visuals only when they echo, clarify, or amplify the point.

    line 54
  15. Distinctive:

    Use sharp, appropriately cropped images and legible charts.

    line 55
  16. Distinctive:

    Keep layouts simple, aligned, and easy to scan.

    line 56
  17. Distinctive:

    Use one neutral family plus one accent color by default, or at most two accents when the content needs them.

    line 57
  18. Distinctive:

    Use one or two typefaces with a clear hierarchy.

    line 58
  19. Distinctive:

    Use animation sparingly and only to control explanation, show change, or direct attention.

    line 59
  20. Distinctive:

    Read references/lesson-principles-and-review.md when planning a new deck, substantially rewriting one, or conducting a presentation-quality …

    line 78

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Build Effective PowerPoint Decks

Create an editable deck that helps a specific audience follow and remember the message. Treat the presentation as an experience rather than a report pasted into slides.

When authoring or editing an actual deck, also follow the presentation-file skill if this assistant has one. That skill handles file mechanics, templates, rendering, and technical checks; this one handles content, pacing, and design.

Keep momentum

Use available context and safe, reversible defaults before asking for input. Bundle non-blocking questions and continue useful work. Interrupt only when a missing choice would change the result, privacy, cost, authority, safety, or something hard to undo. Never repeat an answered question.

Establish the communication job

Before planning, determine from the request and supplied material:

  • audience and any key stakeholder;
  • purpose, desired audience response, and decision or takeaway;
  • live, virtual, self-paced, or leave-behind use;
  • speaking time or review context;
  • must-use facts, brand/template constraints, and source material.

Ask only for consequential missing information. Do not make the user specify ordinary design choices that can be inferred responsibly.

Build content before decoration

  1. Write a plain-text story outline before choosing visuals or polishing slides.
  2. Give each slide one major job: answer one audience question, advance one claim, or mark one transition.
  3. Put the top-level takeaway on the slide as a short, memorable phrase. Keep supporting explanation in the speaker notes, a purposeful visual, or a clearly structured appendix.
  4. Turn source documents into a narrative; never copy and paste report prose into slides.
  5. For live delivery, use roughly 30–60 seconds per ordinary slide as a pacing diagnostic. Split a slide when its explanation contains multiple stages or major ideas. Longer display time is acceptable for intentional discussion, demos, or reference views.

Create a slide map with, at minimum: slide purpose, audience takeaway, visible copy, supporting evidence, visual role, speaker-note detail, and expected pacing.

Write for comprehension

  • Prefer phrases, labels, and keywords over full sentences for ordinary live slides.
  • Do not apply "minimal text" blindly. Include enough visible structure for the actual audience, especially when listeners may need language, accessibility, or remote-viewing support.
  • Make text readable from the back of the room and verify it in the rendered deck. Shorten copy before shrinking type.
  • Keep the speaker's words complementary to the slide; do not make the presenter read the visible copy verbatim.
  • When points must unfold in sequence, reveal or separate them in the same order the speaker discusses them. Do not expose a dense wall of future points that the audience can read ahead of the talk.
  • For leave-behind decks, add self-contained context deliberately, but retain a clear hierarchy and avoid report-shaped pages.

Design in service of content

  • Use visuals only when they echo, clarify, or amplify the point. Remove decorative or irrelevant images and confused visual metaphors.
  • Use sharp, appropriately cropped images and legible charts. Give every chart a written takeaway.
  • Keep layouts simple, aligned, and easy to scan. Avoid compensating for design insecurity with extra photos, colors, fonts, icons, or effects.
  • Use one neutral family plus one accent color by default, or at most two accents when the content needs them. Give repeated colors a consistent meaning throughout the deck.
  • Use one or two typefaces with a clear hierarchy.
  • Use animation sparingly and only to control explanation, show change, or direct attention. Prefer simple reveals, underlines, or chart builds over spinning, twirling, exploding, or novelty transitions.
  • Bring the presenter's voice, authority, energy, and personality into the language and examples in proportions that fit the audience.

The reference file summarizes two public presentation-design videos. Generalize their teaching principles; do not copy their literal colors, layouts, or branding. Honor the user's template or visual direction.

Produce and verify

For a substantial new deck:

  1. Inspect all source material and any template or reference deck.
  2. Draft the outline and slide map.
  3. Establish a small visual system: grid, margins, typography, color semantics, image treatment, and transition rules.
  4. Build and render representative slides spanning the major layout types; correct the pattern before scaling it to the whole deck.
  5. Complete the deck, keeping content editable and source claims traceable in speaker notes.
  6. Render every slide. Inspect individual slides at full size and the deck as a contact sheet for pacing and repetition.
  7. Revise weak takeaways, tiny or excessive text, long-stay slides, irrelevant visuals, unclear color meaning, repetitive layouts, clipping, overflow, and unintended overlaps.

Read references/lesson-principles-and-review.md when planning a new deck, substantially rewriting one, or conducting a presentation-quality review. Use its audience adaptations and rubric; do not load it for a trivial wording or formatting edit.

Completion standard

Deliver only after the deck:

  • is clearly for the stated audience and purpose;
  • has a coherent beginning, progression, and ending;
  • gives each ordinary slide one comprehensible job;
  • supports rather than scripts the speaker, or is intentionally adapted as a leave-behind;
  • uses readable text and content-driven visuals;
  • applies color and motion consistently and sparingly;
  • has passed full-slide visual inspection and technical checks.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.