sample-spec-driven-presentation-maker: Spec-Driven Presentation Maker: When PowerPoint Becomes a Compiler Target
A deep look at AWS’s JSON-first slide engine, its CSS Grid-like layout system, and the round-trip pipeline that turns decks into structured data and back again.
- SDPM treats the slide spec as the source of truth, so PowerPoint becomes compiled output instead of the place where the work starts.
- Its layout engine borrows the mental model of CSS Grid, which makes slide positioning feel deterministic instead of artisanal.
- The builder and converter are designed as a reversible pipeline, so decks can be generated, inspected, and normalized back into JSON.
- The 4-layer architecture turns a sample into a platform shape, from local engine to cloud MCP to full stack collaboration.
Most slide tools start with a canvas. AWS’s Spec-Driven Presentation Maker starts with a contract. You define the slide in JSON, the engine resolves layout and theme, and PowerPoint is the compiled artifact at the end.
That sounds subtle until you think about how most decks are made. Manual editing hides structure inside coordinates. Prompt-first tools hide structure inside vibes. SDPM makes structure explicit, then gives the machine the boring part.
Slide decks, but compiled
The repo’s core move is simple: stop treating a deck as a sequence of hand-placed objects. Treat it like a build target with inputs, transforms, and outputs. The authoring surface is a spec, not a slide canvas.
Spec-driven presentation applies the concept of Spec-Driven Development from software engineering to presentation creation.
That framing matters because it changes where the intelligence lives. Instead of asking an AI to freestyle composition, SDPM asks it to produce a structured deck description that the system can reliably render.
The spec is the product
The spec is not a throwaway intermediary. It is the durable version of the deck. That is why the repo also includes a minimalizer that strips defaults, which keeps the JSON compact enough for LLM workflows and easier to diff, inspect, and reuse.
This is the kind of detail that separates a demo from a system. A spec that bloats into noise is hard to edit and hard to trust. A spec that stays lean can become part of a real workflow.
The layout engine is the real trick
The most interesting code is the layout layer. The repo’s `compute_grid` logic borrows the web’s mental model, with `fr` units, `px` units, and gaps, then maps that into PowerPoint’s coordinate system. That gives authors a way to say what should expand, what should stay fixed, and how space should be shared.
Under the hood, the engine translates a virtual 1920 by 1080 canvas into EMUs, the unit PowerPoint uses internally. That means the system can be deterministic without forcing the user to think in PowerPoint’s native geometry.
How the builder assembles a deck
The builder layer uses mixins to keep slide element handling modular. Textboxes, shapes, images, and charts can each live in their own lane while still feeding one PowerPoint file generator. That is an important separation of concerns in a file format that is famously awkward to manipulate directly.
# Conceptual shape of the builder layer
builder = PPTXBuilder(template_path)
slide = builder.add_slide()
slide.add_textbox(spec["title"])
slide.add_shape(spec["callout"])
slide.add_image(spec["hero_image"])
slide.save("deck.pptx")The point is not that this is pretty. The point is that it scales better than hand-coded XML fragments or a pile of one-off slide scripts. It is a disciplined abstraction over a messy output format.
| Workflow | Source of truth | Layout control | Reproducibility | LLM friendliness | Round-trip editing | Branding support |
|---|---|---|---|---|---|---|
| Manual PowerPoint editing | The slide itself | High, but manual | Low | Poor | No | Depends on the operator |
| Prompt-only slide generation | The prompt | Inconsistent | Low | Medium | Weak | Unreliable |
| SDPM spec-driven workflow | The JSON spec | High and deterministic | High | High | Yes | Strong through template/theme parsing |
Why round-trip matters
The reverse path is the underrated part. `pptx_to_json` extracts theme data and structural content back out of the deck, then the minimalizer removes default noise. That turns the system into a loop instead of a one-way export button.
For teams, that is a big deal. Once the deck can be normalized back into JSON, it becomes auditable, reusable, and much easier to regenerate under changing requirements.
A quote that captures the user-facing promise
The project’s own framing is direct: it applies spec-driven development to presentations. That is the whole bet, and the rest of the architecture exists to make that bet operational.
Four layers, one idea
The repo is not just a library. It is staged as a progression. The local engine handles generation, the local MCP layer exposes it to agentic workflows, the cloud MCP layer adds hosted infrastructure, and the full stack layer wraps it in a team-facing product surface.
| Layer | What it is | Why it exists |
|---|---|---|
| Engine | Python presentation compiler | Local, deterministic deck generation |
| Local MCP | Tool exposure for agents | Lets LLMs invoke the engine in a controlled workflow |
| Cloud MCP | Hosted service with storage and auth | Adds sharing, sandboxing, and remote execution |
| Full stack | Agent, API, and web UI | Turns the sample into a collaborative platform shape |
That progression is the real architectural signal. AWS did not ship a single script and call it done. It shipped a path from utility to platform.
What this says about AI presentation tools
The broad lesson is not that AI should replace slide design. It is that AI works better when the structure is explicit. For presentations, the winning pattern may be the same one that made software engineering durable: specify first, generate second, inspect and round-trip third.
That makes SDPM more interesting than a slide generator. It is a reminder that structured work gets better when the machine is asked to respect the structure instead of improvise around it.
