Generate a slide deck in 90 seconds with ONE html file

It always starts with: Hey… we need to produce a presentation for ... . Thirty minutes before the ... starts 😂

What happens next is a mix of chaos driven development and creative writting under fire: you open PowerPoint, paste the same slide layout you’ve used for three years, manually copy numbers from Jira, Grafana or any other DS and wonder why the heck it looks like crap. In ususal cycle - those decks are THE MOST HATED part and unless you are deeply commited to brand communications you treat it as a necessary evil…

To break that hostage cycle I figured out - why we won’t use Copilot Chat, paste a prompt, wait 90 seconds and get professional deck out of the blue?

Why HTML and not Markdown

The standard Reveal.js setup uses a Markdown file for content and a separate HTML file for config. Two files to maintain, a build step to run, and agents tend to hallucinate the bridge between them.

A single self-contained HTML file solves all three. The browser renders it directly - open slides/index.html, no server, no build. Git versions it like any other text file. And an agent reading the file sees both the structure and the content in one context window.

PowerPoint is binary, agents can’t read it. Markdown-to-Reveal.js is two files, agents lose track. One HTML file with all styles, all slide structure, and all content is the only format that is renderable, versionable, and agent-readable at the same time.

How the template is built

The template is a Reveal.js presentation with a custom dark design system - design tokens in CSS custom properties, no hardcoded colours. Every visual component (stat tiles, tables, timelines, progress bars, Mermaid diagrams, Excalidraw embeds) lives in its own clearly labelled CSS block which is fully AI readable.

The HTML structure uses <!-- COMPONENT: NAME --> markers throughout:

<!-- COMPONENT: STAT-GRID (4-col) -->
<div class="stat-grid four">
  <div class="stat-card">
    <div class="big-num green">99.8%</div>
    <div class="big-label">uptime last 90 days</div>
  </div>
  ...
</div>
<!-- END COMPONENT: STAT-GRID (4-col) -->

These aren’t comments for humans. They’re a machine-readable table of contents. The prompt references the same names - Stat tiles → numbers, KPIs - so the agent can locate the right component, copy it, and fill in real data without hallucinating structure.

The prompt embedded as the last slide

The prompt isn’t in a README somewhere. It’s the last slide in the deck:

<!-- SLIDE: GENERATE THIS DECK WITH COPILOT -->
<section>
  <h2>Generate a deck like this with Copilot</h2>
  <div class="prompt-block">
# Analyze this repository and generate a presentation.
# Do NOT invent data - read the codebase, docs, and git history.

Task:
1. Read README.md, architecture docs, and `git log --oneline -30`
2. Identify: purpose, capabilities, status, KPIs, contacts
3. Map content to components:
     Flow steps  → how-it-works sequences
     Stat tiles  → numbers, metrics, KPIs
     Timeline    → roadmap, sprint status
     Tables      → comparisons, risk registers
     Alert boxes → blockers, highlights
4. Generate slides/index.html - replace ALL placeholder content
5. Keep to 8–12 slides. One message per slide. No filler.

Template: https://github.com/your-org/slides-template
  </div>
</section>

This is the design decision that makes the whole thing work. When Copilot opens the file it’s about to edit, the instructions for how to edit it are right there - in the same context, in the same file. No context switching, no “check the README for component names.” The artifact is self-describing.

The multi-root workspace trick

Open your target repo and the template repo side-by-side as a VS Code multi-root workspace. Copilot can read both at once - it sees the actual codebase it’s generating slides for, and the template it’s generating from, in a single context.

File → Add Folder to Workspace → [select your project]

This is what makes the “read the codebase, don’t invent data” instruction actually work. Without the project in context, Copilot guesses. With it, it reads git log, the README, architecture docs, and fills in real numbers.

What the agent produces

The prompt maps content types to components explicitly. This is the part most people skip, and it’s why most “generate a presentation” prompts produce generic garbage.

Instead of “make me slides about this project,” the prompt says:

• Stat tiles → numbers, metrics, KPIs
• Timeline → roadmap, sprint status, migration phases
• Tables → comparisons, decision matrices, risk registers
• Alert boxes → current blockers, highlights, status

Copilot locates each component by its HTML marker, copies the structure, and substitutes real data from the codebase. The result is a deck that uses the same visual language as the template - not a freestyle reimagining of what slides should look like.

My personal recommendation is also to use humanizer skill, it helps llms to sound more natural and avoid these hated ai’isms that if you work with AI daily you see and trully hate. By tweaking the humanizer with your own writing, you can give it your personal character so it will sound actually more like you.

The numbers

• 90-120 seconds on Opus 4.7 for a 10-slide deck from a real codebase
• Zero build step - open the HTML file directly in a browser
• One file to maintain - the entire deck, design system included
• Works with any project - the prompt reads git log and README, not project-specific config

The template ships with 15+ components as working examples: stat grids, tables, progress bars, horizontal bar charts, tier bars, timelines, icon tiles, Mermaid diagrams (git graph, flowchart, sequence, ER, Gantt, pie), Excalidraw/draw.io SVG embeds, Excalifont “back of the envelope” style of writing / styling, code blocks, pull quotes, speaker notes, and incremental reveal fragments.

If you need more advanced charting or any other features - you can always add some js charting library via CDN and instruct copilot how to use it.

Everything is in one file. Copilot can find any of it.

The pattern, generalised

The slide template is one instance of a broader pattern: embed the agent’s instructions directly in the artifact the agent edits.

The agent doesn’t need a separate system prompt, a README, or a wiki page. The file explains itself. When the agent opens it, the context is already there.

This works for slide decks. It works for PR description templates, runbook stubs, ADR files, sprint review docs. Instructions in a separate file that you hope the agent reads are fragile. Instructions in the file itself are not.