English · Русский

present — a skill for Claude Code

An agent skill that builds a bespoke HTML presentation (a deck) from a context folder, a talk transcript, or a single topic.

It is not a template filler: Claude reads your material, picks the art direction itself and designs the deck around that specific content — different talks come out as visually different decks (structure, palette, typography, background, character of motion).

The output is a self-contained HTML file: it opens offline in a browser, with no CDN and no network references.

There are two modes, and the user picks one when the skill starts: quick — a single deck as a single
file, nothing else lands on disk; full — a talk with slide text, a design brief, a presentation folder
and a manifest.

How I make talks: Context · Design · Voice

The skill is only one step of a pipeline. The pipeline matters more, so let's start there.

The core idea: three files instead of one. It all used to live in a single PowerPoint — text, design and speech together; pull one thread and everything unravels. Here it is three separate jobs with three artefacts. And there is exactly one rule: first get slides.md by any means, and only then deal with design.

1. Context → slides.md

The first step is called "context", not "words", on purpose: it does not matter where the material came from — what matters is that slides.md comes out the other end. Two main entry points, both spoken out loud:

• Talk the idea through. Open party mode in BMAD on an empty folder and dictate your idea as a free-form monologue: what I want to say, what has to be in there, what to pay attention to. It works the idea over and asks concrete questions — it turns into a session. Out comes slides.md: which slides there will be and what I say on each. No design.
• Straight to the recorder. If the talk is already in your head — hit record and say the whole thing as it comes. Transcribe it (OpenSuperWhisper locally, model large-v3 — fast and accurate on an M-chip, punctuation and English loanwords included) and hand the transcript to BMAD: "here is the whole talk, break it into slides".
• Existing material. Context can be anything: articles on the topic, an entire repository (then the numbers on your slides come from a real git log), internal docs, someone else's presentation. You drop it into BMAD exactly the same way: "here is the material, lay it out as slides".

The difference between the first two: in the first case the talk is invented together with the model, in the second the model lays out a talk it already has in full. All paths converge on the same point.

A piece of advice bigger than this pipeline: talk to the model with your voice. Not just for talks — for any task. You say everything you have on the problem, dump your thoughts as they come, and it extracts the substance. When you speak, the flow is freer: you don't edit yourself mid-sentence, you don't hunt for the phrasing.

2. Design → design.md + the deck

We are in the AI era — you don't need PowerPoint, generate HTML: models write it well and fast, and it gives you animation, motion and interactivity.

• A reference. You don't have to do the layout yourself — you have to find a style. For example styles.refero.design: you look at how it actually appears, and every style ships with a ready design.md — copy it into your folder. Design done. design.md is by now practically a standard, like README.md: a file describing how everything should look (fonts, colours, shapes, spacing). You can go the other way too: write it by hand or put it together with BMAD.
• The build. /present <folder> — the skill needs exactly two files, slides.md and design.md. It will ask a question or two if it has to, and build the deck. That is the baseline, and a baseline is usually not what you want — but it cost you little time and it is already in your hands.
• The revision loop. You look at the deck and fix it with words: what you don't like, what to change where, where to add motion. You can keep polishing forever.
• Claude Design (optional, but strongly recommended). After the first build, drop the deck and your design.md into Claude Design — it will review it and propose its own solution, and that solution will work. A chat plus a working canvas like a Figma panel: you pin notes straight onto the layout. Included in the Claude subscription (Pro / Max / Team / Enterprise), nothing extra to pay. The step is optional — the pipeline works without it.

design.md here is the main file, not decoration: the same material under three different briefs gives three completely different decks.

3. Voice → the loop back into slides.md

The deck is ready — and this is where most people stop, while the most valuable part is still ahead.

• A run-through on the recorder. Start the deck, start recording (on the computer itself) and walk your slides out loud, in your own words, as if the room were already seated. Spot a mistake — say it out loud right there, it all gets recorded. You immediately learn two things: how long the talk actually runs and where you flounder — where you started mumbling, the slide is bad, not you.
• Transcription. OpenSuperWhisper locally → raw text with all the filler and every "uhh". Free, and nothing leaves your machine.
• The model as an editor. Back into BMAD: read this, cut what needs cutting, tell me where I'm wrong. And the key trick — give it the time budget: "I have twenty minutes, here are the per-slide timings, squeeze it". It trims exactly what you won't miss. What comes out is your words, just tidied up — not something the model made up on its own.
• Back into slides.md and rebuild. Now the deck holds what you actually say — the slides followed the live speech, not the other way round.

That arrow back is the whole reason for splitting into three files: every lap the talk gets shorter and sharper, and nothing has to be rebuilt from scratch.

Two loops

The small loop turns as many times as you run the talk out loud.

Pipeline tools

What the finished deck can do

• Navigate with ← →, the mouse wheel or a swipe; the position lives in the #hash — F5 doesn't lose your slide.
• P — the presenter window: notes, next slide, timer, and slide switching from there too. Ideally two monitors: one you share, one in front of you. Share the deck to the screen, not this window.
• Notes are edited right in that window: double-click the text → fix it → apply. Mumbled during rehearsal — rephrase it on the spot, while the thought is fresh.
• B — black screen, F — fullscreen.
• S — export to PDF: the kernel freezes every slide in its final frame (counters counted up, animations played out), the page is 16:9 with no margins, one slide per page, text stays text. Blurred shadows are deliberately printed flat — Chrome writes them as a raster mask that Preview paints as a grey rectangle over your content — and the deck looks the same as ever on screen. When someone asks you to "send the slides" — you have something to send.
• ?check in the address bar — highlights slides whose content is taller than the screen.
• Slides you can poke at. HTML does things PDF cannot, and the skill uses that sparingly: it goes
  through the slides, looks for places where the audience would understand more if they switched something
  themselves, and offers options — the user decides. The engine yields to widgets: a click on a button or a
  caption doesn't flip the slide, typing in an input doesn't trigger hotkeys, a scrollable area scrolls on
  its own. One or two such slides per deck is the norm, and each one reads fine even if nobody clicks it.
• Live notes in a <slug>-notes.js file next to the deck: edit them in the presenter window or in an external editor — they are picked up on the fly, no rebuild. A copy is embedded in the HTML as a fallback, so the deck can still be sent as a single file.

The deck runs as a local file, and a browser cannot write to disk from one — so note edits live as a draft in the browser (they survive F5) and reach the disk via the "⤓ notes.js" button: download it, drop it next to the deck over the old one. The file wins over the draft; unsaved edits are not lost — the presenter offers to bring them back.

Install

The skill is installed by copying it into a skills directory — globally (available in every project) or locally in one project.

Globally:

git clone https://github.com/StasPotapov/present.git ~/.claude/skills/present

Or into a specific project:

git clone https://github.com/StasPotapov/present.git .claude/skills/present

To check that Claude Code sees the skill: /present in the command list.

Usage

/present <context folder | file | topic | reference URL>

The first thing Claude asks about is the mode. Quick — for when you just need to show an idea in
pictures: no slides.md, no brief, no interview, no plan to approve; exactly one <slug>.html lands on
disk, drafts stay in the session's temp folder. Full — everything described below. A quick deck is
not wasted if you later grow it into a full talk: hand the finished HTML back to the skill and say what
to add — the deck is its own context (text in the slides, speech in data-notes, art direction in its
own styles).

For the full mode, the input that works best is a context folder:

my-talk/
├── slides.md     # slide text + speaker notes
├── design.md     # design brief (art direction)
└── *.png/jpg     # media to embed

The two input files are a hard requirement for the build:

• slides.md — what gets said: a breakdown into slides (---, ## Slide N or headings), pairs of "slide point → speaker note".
• design.md — how it looks: the design brief. An export from styles.refero.design (palette tokens, type scale, components, Do/Don't, a ready :root) is applied precisely.

Whatever is missing, Claude collects in a short interview (or helps you find a ready brief) and saves as a file, and only then shows you the deck plan. If both files already exist, the interview is skipped.

It also works without a folder: raw talk text, a transcript, bullet points, a single topic, a path to a repository (then the numbers on your evidence slides come from a real git log), a reference URL to extract design DNA from.

The skill does not invent content — numbers and facts come from your material or are confirmed with a question.

What you get

Quick mode — one file and nothing else:

wherever you asked/
└── <slug>.html      engine, styles, slides, notes and base64 media — all inside

Full mode. Your working folder stays yours: material, raw sources and build inputs stay where they are. Everything the deck needs in order to be presented goes into a separate deck/ subfolder — you can zip that one folder and carry it to any laptop without picking files by hand.

talk/
├── slides.md                    input: slide text
├── design.md                    input: design brief
├── transcript.md · *.jpg        raw material — untouched
├── src/ · build.py              build sources (if the deck was built by script)
├── DECK.md                      manifest: slide map, decisions with their "why", how to edit
└── deck/                        ← the self-contained presentation folder
    ├── <slug>-<date>.html       the deck itself
    ├── <slug>-<date>-notes.js   live notes (source of truth after the first generation)
    └── deck-assets/             only if the media didn't fit into base64

DECK.md exists so that the next session doesn't have to read a monolithic HTML file end to end: it holds the slide map and the decisions with their rationale. If the deck was built by script, you edit the sources in src/ and rebuild — never the finished HTML.

Example

example/ holds a real deck built by this skill and run through the whole pipeline above — the talk "Context. Design. Voice.", 16 slides. Its inputs (slides.md, design.md), the DECK.md manifest and the build script with its sources are all there, so you can see both the folder layout and the "script" build mode. The talk itself is in Russian — it is there as a sample of format and layout, not as text to reuse.

git clone https://github.com/StasPotapov/present.git
open present/example/deck/kontekst-dizayn-golos-2026-07-28.html

How the skill is put together

Validator

python3 assets/validate.py <deck>.html

It checks kernel integrity (the KERNEL v6 marker, base and print styles, chrome, presenter, note editing, PDF export), leftover {{…}}, network references and local links to missing files, JS syntax (node --check on every script block and on notes.js), stray script blocks and the order of the interactive block relative to the kernel, interactivity on an engine older than v6, a click bound by attribute to a non-interactive tag, section sync between notes.js and the slides, and the presence of slides.md / design.md / DECK.md.

A quick-mode deck is recognised by the validator on its own — a single file with no companion set — and it doesn't ask for the set.

Requirements

• Claude Code.
• For the validator — python3 (stdlib) and node (for --check; without it the syntax check is simply skipped).
• PDF export is verified in Chrome; from Safari it is worth checking the result by eye.
• Optional: poppler (brew install poppler) — Claude uses pdfinfo/pdfimages/pdfseparate to check the exported PDF. Without it that check degrades to file size plus a qlmanage render of the first page.
• The Claude in Chrome extension — this is what Claude uses to check the deck before handing it over:
  it runs the layout audit (overflow, broken images, tiny type, clipped and overlapping text) and looks at
  the frames itself. The check is mandatory in both modes; without the extension Claude says so plainly and
  asks you to page through the deck with ?check yourself.
• Optional: the defuddle skill — used to read a reference URL. Without it, WebFetch is used.

No npm install / pip install: the skill uses preinstalled tools only. Fonts are system stacks, or one embedded base64 open-source font (with your consent — the only network action allowed during a build).

Language

The skill itself is written in Russian and talks to you in Russian. SKILL.md and every asset are in Russian, and so is the dialogue during a build; the deck it produces is in whatever language your material is. This README is the translated part — the Russian original is README.ru.md.

Use it. But using this skill is not the point: write your own. Once you build something like it yourself and realise you can make anything you want for yourself — that is when you see what these models are actually for.