Imported from borghei/claude-skills (markdown-html/md-slides/SKILL.md). Install upstream with npx skills add borghei/claude-skills --skill md-slides. Copyright stays with the author (MIT + Commons Clause).

Markdown Slide Decks

Turn a markdown file into a slide deck that is one HTML file: six layouts, speaker notes, keyboard and remote navigation, light/dark theming, and handout printing. The density linter is the part that matters most — it catches the slides an audience cannot absorb before you are standing in front of them.

When to use this skill

• Building a deck from markdown you want to keep in version control
• Presenting from a laptop without a presentation app or a cloud account
• Cutting an overloaded deck where every slide is a wall of text
• Timing a talk against a fixed slot before rehearsing it
• Converting a document into a deck as a starting point, then editing down
• Producing a handout that includes speaker notes alongside each slide

Inputs the skill expects

• A markdown deck source, slides separated by ---
• The talk length and format — presented live, or circulated to be read
• Layout intent per slide: title, section divider, bullets, two-column, quote, image
• Speaker notes after a ??? marker on each content slide
• Images as relative paths, or as data URIs for a genuinely single-file deck
• The presentation environment: room lighting and display size

Clarify First

Before building, confirm these inputs. If any is unknown or vague, ASK — do not assume:

• Presented live or circulated to read — why it changes the output: it selects the density profile, and the two budgets differ by roughly 2x; the wrong one produces a deck that fails at the job it actually has
• Talk length and slot — why it changes the output: it sets the slide count and drives the runsheet; a 60-slide deck for a 15-minute slot is an unfinished edit, not a pacing choice
• Whether images must be embedded — why it changes the output: relative paths mean the deck is a folder, not a file, and it breaks when emailed
• Room lighting, if presenting — why it changes the output: dark themes wash out under ambient light; this decides the default theme and the contrast floor

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.

Workflows

Workflow 1 — Build a deck and check its density

1. Lint first. Building an overloaded deck and reading it on screen is a slower way to learn the same thing.
2. Fix what the linter flags — usually by moving sentences into speaker notes.
3. Build. The theme and navigation script are inlined automatically.

python3 markdown-html/md-slides/scripts/slide_density_linter.py \
  --input markdown-html/md-slides/assets/sample_deck.md --profile present

python3 markdown-html/md-slides/scripts/md_to_slides.py \
  --input markdown-html/md-slides/assets/sample_deck.md \
  --out build/deck.html --format text

Workflow 2 — Time a talk against its slot

1. Generate the runsheet at your actual speaking rate, not the default.
2. Read the * markers — those slides have no notes, so their duration is guessed from on-slide content and is the least reliable number in the sheet.
3. If the total is over, cut slides. Speaking faster does not create time.

python3 markdown-html/md-slides/scripts/notes_runsheet.py \
  --input markdown-html/md-slides/assets/sample_deck.md \
  --wpm 130 --target-minutes 15 --format text

python3 markdown-html/md-slides/scripts/notes_runsheet.py \
  --input markdown-html/md-slides/assets/sample_deck.md \
  --format markdown > build/runsheet.md

Workflow 3 — Convert a document into a deck

1. Split on every ## heading to get a first pass with the document's own structure.
2. Lint immediately. The result will fail — a document section carries far more than a slide's budget. That failure list is the edit plan.
3. Rewrite headings as claims, demote sentences to notes, then rebuild.

python3 markdown-html/md-slides/scripts/md_to_slides.py \
  --input markdown-html/md-slides/assets/sample_deck.md --split-on h2 --out build/draft.html

python3 markdown-html/md-slides/scripts/slide_density_linter.py \
  --input markdown-html/md-slides/assets/sample_deck.md --profile present --format json

Decision frameworks

Density budget

Every threshold is a proxy for one rule: a slide must be readable in under 5 seconds, or it competes with the presenter. An audience cannot read and listen simultaneously — when a slide carries prose, the room reads it faster than you can say it and then disengages.

title, section, quote, and image layouts are exempt from the body rules.

Layout selection

Deck length by slot

The runsheet adds a 4-second transition allowance per slide — real, and routinely forgotten. Thirty slides carry two minutes of dead air before anyone speaks.

Where content goes when a slide is too dense

Contrast at projection

[PROVEN] Present light in a bright room, dark in a dark one. The T key toggles theme so this is decided in the room, not an hour before.

Anti-Patterns

The document in slide clothing

Mistake: Full paragraphs on every slide, because the deck must also work as a leave-behind for people who were not there. Why it happens: It is one artifact instead of two, and the request to "make sure it stands alone" is reasonable on its face. Instead: Pick one job. A presented deck uses the present budget with the sentences in speaker notes; a circulated deck uses --profile read. Trying to serve both produces something too dense to present and too fragmentary to read. If it will mostly be read, write a document and build a thin deck that points at it.

Bullets as sentences

Mistake: Writing each bullet as a complete sentence, so the slide reads correctly on its own. Why it happens: Fragments feel unfinished while drafting, and complete sentences feel more rigorous. Instead: A bullet is a label the presenter expands, not a sentence the audience reads. Past roughly 12 words it is prose and the room stops listening. Move the sentence into the speaker notes, where it is genuinely useful — that is what notes are for, and it is why the linter flags a dense slide with empty notes.

Topic headings

Mistake: Heading a slide with its subject — "Options", "Results", "Storage costs". Why it happens: It matches how the deck was outlined, and outlines are built from topics. Instead: Write the heading as the sentence you want remembered: "Cold data is paying hot prices", "Latency held; spend fell 31%". Someone who reads only the headings should still receive the argument. This single change improves a deck more than any layout decision.

Speaking faster to fit the slot

Mistake: Discovering the deck runs long and planning to talk quickly rather than cutting slides. Why it happens: Cutting means giving up content you already built and believe in. Instead: Cut. Speaking faster converts an over-long talk into an over-long talk nobody follows, and it eliminates the pauses that let a point land. The runsheet says "cut content, do not speak faster" for this reason.

Skipping the full-screen proof

Mistake: Authoring in a windowed browser and presenting full screen without checking. Why it happens: The deck looks finished on the laptop, and full screen feels like the same thing but bigger. Instead: Open it full screen on the actual display and walk every slide with the actual remote. Type scales with viewport width, so every size decision changes — tables and code blocks are set smaller than body text and are the first things to become unreadable from the back row. Presenter remotes send PageUp/PageDown, which is also worth confirming before you are on stage.

Files

All scripts share one exit-code contract: 0 clean, 2 gate failed (findings at or above the threshold), 1 the tool itself errored. A CI job can therefore tell a real defect from a broken invocation.

Three CLI tools, one module. slide_render.py is a library, not a fourth command — it holds the parser and renderer that md_to_slides.py imports. A single-file converter came to 324 lines, over the 300-line ceiling, and the only ways to fit were deleting docstrings or dropping features. Splitting CLI from parser is the remedy the tool-design standard prescribes for an oversized script, and same-directory imports keep the package self-contained: nothing here imports from another skill, and md-document carries its own separate copy of the equivalent renderer rather than sharing this one.