Kimmy's Skills

Presentation

A presentation is an argument an audience can follow and act on. It can be live, written, or both; the medium changes the craft, not the thinking.

Modes

Thinking

  1. Audience and intent. Who is in the room or on the page, what they believe, what action or decision this should produce, and what success looks like.
  2. One-sentence takeaway. Write the sentence the audience should repeat tomorrow. Everything that does not serve it is cut or moved to appendix.
  3. Choose the form. Live for attention and commitment; written for precision and reuse; hybrid when the decision needs both. Do not project a report or hand over a deck as a substitute for thinking.
  4. Build the argument. Read references/narrative-and-language.md. Use contrast between the world as it is and the world with the idea adopted. For decisions, answer first: SCQA and the pyramid principle. For talks, a three-act arc with two turning points. For technical evidence, assertion–evidence.
  5. Plan the evidence. For each claim, choose the visual or verbal evidence: story, demonstration, photograph, diagram, chart, short table, or quotation. Prefer evidence over bullet lists.
  6. Design the language. Read references/narrative-and-language.md. Spoken and written registers differ: speak in short sentences with repetition and signposts; write with topic sentences, precision, and transitions; slide copy is an assertion, not prose. Use classical rhetoric as a discipline — invent, arrange, style, rehearse, deliver — not as decoration.
  7. Control structure and time. Read references/delivery-and-time.md. For live: opening, body, close, appendix; a time budget; a change of mode every few minutes; a must-cut list; a Q&A buffer. For written: BLUF, a stand-alone summary, numbered findings, and an appendix.
  8. Design the surface. Read references/visual-and-accessibility.md. Use the design system or visual language that fits this topic, setting, audience, and medium; if none exists, use references/minimal-visual-system.md as an adaptable example, not a fixed template. One idea per slide or section; a type scale for the back of the room or the reading distance; honest charts; a grid that survives grayscale.
  9. Produce the deck. Read references/deck-production.md when producing an HTML deck. Build a skeleton and one sample slide before batch writing; keep slide data in the markup; generate the TOC, page numbers, notes, and total time from it; run a batch contact-sheet QA and fix only changed slides plus their neighbors.
  10. Rehearse or read back. For live, run it timed, record it, and cut. For written, read the summary alone and the headings alone; if the argument is not there, rewrite.
  11. Make it accessible. Read references/visual-and-accessibility.md. Alt text, reading order, captions or transcript, color never alone, reduced motion, plain language, and a handout that works without the speaker.
  12. Verify and export. Render every slide or page, check at presentation size and in grayscale, confirm the artifact opens offline, and confirm the source and the artifact agree.

Formats

Read references/format-playbooks.md before you design: sharing session, demo, talkshow or panel, workshop, pitch, readout or report.

References

Non-negotiables

Output

In the user’s language and location: a source outline or Markdown source as the source of truth, the rendered artifact (a self-contained HTML deck for live, a print-ready self-contained HTML document for written, or both for hybrid), and speaker notes, timing, or a reading path. Add a one-page executive brief when the audience needs a stand-alone leave-behind. Keep the source and the artifact from drifting.

Boundary

This skill designs and writes the presentation; it does not deliver the talk, research the claims, or build the product. Research is a separate research task; reviewing a deck or report is a separate review task; building or governing the visual system is a separate design task.