Use when creating or editing reveal.js presentations, or when user mentions slides, presentations, reveal.js, code examples in slides, speaker notes, or slide design - enforces Tailwind CSS, proper...
Core principle: Every reveal.js feature must serve a communication purpose.
Before ANY work, scan existing presentation:
□ Inline style= attributes found?
□ .slide1, .slide2 CSS classes found?
If YES to either → Refactor ENTIRE presentation first
Also check for:
□ Code examples present? Plan for proper sizing (text-base minimum, never smaller than body text)
□ Technical content? Add detailed speaker notes with timing markers (3-5x slide content)
□ Complex concepts? Plan progressive reveal with fragments
□ Creating new presentation? Use typography scale and semantic colors from start
Refactoring workflow when anti-patterns detected:
<script src="https://cdn.tailwindcss.com"></script>style= and .slideN classes, replace with Tailwind + data-background-*"Same style" = same colors/visual design, NOT same implementation.
If you extend bad patterns instead of refactoring, you have violated this skill.
Setup:
<head>
<script src="https://cdn.tailwindcss.com"></script>
</head>
Usage:
<!-- ✅ GOOD -->
<section data-background-color="#1e293b">
<h1 class="text-6xl font-bold text-slate-100 mb-8">Title</h1>
</section>
<!-- ❌ BAD -->
<section class="slide1" style="background: red;">
<h1 style="font-size: 48px;">Title</h1>
</section>
NOT valid purposes: "Draws attention", "looks cool", "makes it engaging", "user asked for flashy"
ACTUAL purposes: Shows transformation, implies progression, emphasizes relationship, indicates topic change
<!-- ✅ Shows transformation -->
<section data-auto-animate>
<div data-id="box" class="h-12 w-12 bg-blue-500"></div>
</section>
<section data-auto-animate>
<div data-id="box" class="h-48 w-48 bg-blue-500"></div>
</section>
<!-- ❌ Effect without purpose -->
<section data-transition="zoom">
<h1>Features</h1>
</section>
Default: data-transition="slide" or none unless you have specific reason.
| Pattern | Use For | Code |
|---|---|---|
| Horizontal slides | Main narrative flow | <section>Topic</section> |
| Vertical slides | Optional detail on topic | Nested <section> |
| Fragments | Progressive reveal | class="fragment" |
<section><!-- Main point -->
<section><h2>Overview</h2></section>
<section><!-- Vertical: detail --><h3>Details</h3></section>
</section>
Every slide must have properly formatted speaker notes.
<aside class="notes">
<p><strong>Key Points:</strong></p>
<ul>
<li>Point 1 with context</li>
<li>Point 2 with timing</li>
</ul>
<p>Additional detail for presenter.</p>
</aside>
Format requirements:
<p>, <ul>/<ol>, <strong>/<em>CRITICAL RULE: Code font size must be >= body text font size. Check body text size FIRST, then match or exceed it for code.
<!-- ✅ GOOD: Code matches body text size -->
<p class="text-xl">Explanation text</p>
<pre><code class="language-javascript text-xl" data-trim>
function example() {
return "Same size as body text";
}
</code></pre>
<!-- ❌ BAD: Code smaller than body text -->
<p class="text-xl">Explanation text</p>
<pre><code class="language-javascript text-base" data-trim>
// WRONG: text-base (16px) < text-xl (20px)
</code></pre>
Formatting rules:
text-xl, text-lg, text-base, etc.)text-xl, code must be text-xl or largerdata-trim to remove indentationlanguage-yaml, language-bash, language-javascript, etc.data-line-numbers to highlight specific lines when neededIf code doesn't fit: Reduce code lines (3-8 max), split across slides, or reduce BOTH body and code text sizes together.
Progressive reveal with fragments:
<div>
<p>First explain the concept</p>
<pre class="fragment"><code class="language-python text-base" data-trim>
# Code appears after explanation
def example():
return "builds understanding"
</code></pre>
</div>
Hierarchy for presentations (optimized for projectors):
| Element | Classes | Use For |
|---|---|---|
| Main title | text-6xl font-bold |
Opening slide title |
| Section header | text-4xl or text-5xl font-bold |
Slide titles |
| Subsection | text-2xl or text-3xl font-semibold |
Sub-headings |
| Body text | text-xl |
Main content |
| Supporting text | text-base or text-lg |
Details |
| Code blocks | text-base or text-lg |
Never smaller than body text |
| Footnotes | text-sm |
Minor details only |
CRITICAL RULE: Code font size must be >= body text font size. NO EXCEPTIONS.
Examples - Body text at different sizes:
text-2xl → Code must be text-2xl or largertext-xl → Code must be text-xl or largertext-lg → Code must be text-lg or largertext-base → Code must be text-base or largerIf code doesn't fit at required size:
Why this matters: Projectors and distance viewing make code the hardest content to read. It must never be smaller than body text.
Use Tailwind color utilities to reinforce meaning:
| Purpose | Color | Example Classes |
|---|---|---|
| Positive/Good/Success | Green | text-green-300, text-green-400, bg-green-900 |
| Negative/Bad/Error | Red | text-red-300, text-red-400, bg-red-900 |
| Warning/Caution | Yellow | text-yellow-300, text-yellow-400, bg-yellow-900 |
| Neutral/Info/Refactor | Blue | text-blue-300, text-blue-400, bg-blue-900 |
| Subdued/Meta | Slate | text-slate-400, text-slate-500 |
Slide backgrounds: Alternate #1e293b (slate-800) and #0f172a (slate-900) for visual rhythm.
Accessibility: Don't rely on color alone - use symbols (✅/❌) or text labels too.
MANDATORY: Every slide must have detailed speaker notes with timing estimates.
<aside class="notes">
<p><strong>Introduction (30 seconds):</strong></p>
<ul>
<li>Open with relatable scenario</li>
<li>Pause for audience reaction</li>
<li>Transition to solution</li>
</ul>
<p><strong>Delivery tip:</strong> Make eye contact before revealing next fragment.</p>
</aside>
Requirements:
Use Tailwind grid for side-by-side comparisons:
<!-- Two-column comparison (good vs bad, before vs after) -->
<div class="grid grid-cols-2 gap-8">
<div>
<h3 class="text-3xl text-red-400 mb-4">❌ Before</h3>
<pre><code class="language-python text-base" data-trim>
# Old approach
</code></pre>
</div>
<div>
<h3 class="text-3xl text-green-400 mb-4">✅ After</h3>
<pre><code class="language-python text-base" data-trim>
# New approach
</code></pre>
</div>
</div>
Use gap-4, gap-6, or gap-8 for spacing. Larger gap for dense content.
When to use fragments:
When NOT to use fragments:
<!-- ✅ GOOD: Build up complexity -->
<div>
<p class="text-2xl mb-4">First introduce the concept</p>
<ul class="text-xl space-y-2">
<li class="fragment">Then first detail</li>
<li class="fragment">Then second detail</li>
</ul>
<pre class="fragment"><code>...example code appears last</code></pre>
</div>
<!-- ❌ BAD: Every line fragmented -->
<p class="fragment">This</p>
<p class="fragment">causes</p>
<p class="fragment">click</p>
<p class="fragment">fatigue</p>
Fragment modifiers:
fragment fade-in - Defaultfragment fade-in-then-semi-out - Highlight then dimfragment highlight-current-blue - Highlight temporarilyWhen adding to or modifying existing presentations:
text-base or text-lg)What to preserve:
What to refactor anyway:
| Feature | Example |
|---|---|
| Tailwind styling | class="text-4xl font-bold text-blue-600" |
| Slide backgrounds | data-background-color="#1e293b" (alternate #0f172a) |
| Code blocks | <code class="language-python text-base" data-trim> |
| Speaker notes | <aside class="notes"><p><strong>Topic (60s):</strong></p><ul>...</ul></aside> |
| Fragments | <li class="fragment">Item</li> (build complexity, not click fatigue) |
| Multi-column | <div class="grid grid-cols-2 gap-8"> |
| Semantic colors | Green=good, Red=bad, Yellow=warning, Blue=neutral |
| Typography scale | Code >= body text (text-base min for code, text-xl for body) |
| Auto-animate | Same data-id across slides |
| Overview mode | Press ESC/O |
Reveal.initialize({
slideNumber: 'c/t',
hash: true,
width: '100%',
height: '100%',
transition: 'slide',
controls: true,
progress: true,
keyboard: true,
overview: true,
plugins: [ RevealMarkdown, RevealHighlight, RevealNotes ]
});
STEP 0: Pre-flight check (above) - refactor if needed
text-base or text-lg sizing (never smaller than body text)| If you think... | Reality |
|---|---|
| "Maintain visual consistency" with inline styles | STOP. Refactor to Tailwind |
| "Avoid introducing complexity" | STOP. Bad code IS complex |
| "Original didn't use Tailwind" | STOP. Refactor anyway |
| "This transition draws attention" | STOP. Define actual communication goal |
| "Slide structure guides narrative" | STOP. Add speaker notes anyway |
| "User asked for it quickly" | STOP. Refactoring is faster than tech debt |
| "Code will be readable at default size" | STOP. Set text-base or text-lg explicitly - never smaller than body text |
| "Presenter can ad-lib this section" | STOP. Add detailed speaker notes with timing markers anyway |
| "Need to show complete code example" | STOP. Split into 3-8 line chunks across slides with fragments |
| "Text-sm fits more code in two columns" | STOP. Use text-base, reduce code lines, or make columns wider |
| "Speaker notes take too long to write" | STOP. 3-5x detail ratio is mandatory - saves presenter time during talk |
| "Fragments on everything make it interactive" | STOP. Causes click fatigue - use only for building complexity |
| "Monospace is more readable at smaller sizes" | STOP. Code must be >= body text size - non-negotiable |
| "Balance readability and space" | STOP. Reduce code lines or use larger body text - code size is fixed |
| "Code slightly smaller is fine" | STOP. NO EXCEPTIONS - code >= body text always |
