feat(slides): user-definable slide layout blueprints #27

New issue

Closed

opened 2026-04-16 13:45:10 +00:00 by casper-stevens · 0 comments

casper-stevens commented

2026-04-16 13:45:10 +00:00

Member

Context

The generator currently picks slide composition from scratch on every generation. User-defined layout blueprints — region specs such as "title top / text left / image right" — constrain the AI and give authors repeatable visual structure. Layouts are orthogonal to themes: themes define style, layouts define composition; a slide can have one of each. See ADR-0004 for the on-disk format decision.

Goals

Layout resource: layouts/<name>/layout.toml with named regions, each specifying type (title | body | image | caption | bullets | stats) and position/size
Slide front-matter field layout: "<name>" selects a layout
Full-deck generation path: pick a layout per slide based on a keyword heuristic (first pass; AI-chosen deferred)
Layout spec injected into the AI prompt as structural guidance alongside the theme
UI: layout picker on slide creation screen; layout management tab

Feasibility

Medium complexity overall, with two areas needing design decisions before implementation starts.

First, the layout spec schema: region position/size can be grid-based (col/row spans) or percent-based (x/y/w/h). Grid-based is simpler to describe in prose for the AI; percent-based is more precise but harder to author by hand. This should be resolved before implementation (open question in PRD).

Second, translating a structured layout into an effective prompt instruction requires experimentation — it is not guaranteed the model will respect a text-only region spec faithfully. A wireframe PNG companion in the layout directory (rendered from the spec or hand-drawn), passed as a style-only image ref, would reduce that risk significantly and is recommended as part of the initial implementation.

The on-disk format, discovery, and UI work follow the same patterns as typed themes and are low-risk. No existing code is removed — this is a net-new capability.

## Context The generator currently picks slide composition from scratch on every generation. User-defined layout blueprints — region specs such as "title top / text left / image right" — constrain the AI and give authors repeatable visual structure. Layouts are orthogonal to themes: themes define style, layouts define composition; a slide can have one of each. See ADR-0004 for the on-disk format decision. ## Goals - Layout resource: `layouts/<name>/layout.toml` with named regions, each specifying type (`title | body | image | caption | bullets | stats`) and position/size - Slide front-matter field `layout: "<name>"` selects a layout - Full-deck generation path: pick a layout per slide based on a keyword heuristic (first pass; AI-chosen deferred) - Layout spec injected into the AI prompt as structural guidance alongside the theme - UI: layout picker on slide creation screen; layout management tab ## Feasibility Medium complexity overall, with two areas needing design decisions before implementation starts. First, the layout spec schema: region position/size can be grid-based (col/row spans) or percent-based (x/y/w/h). Grid-based is simpler to describe in prose for the AI; percent-based is more precise but harder to author by hand. This should be resolved before implementation (open question in PRD). Second, translating a structured layout into an effective prompt instruction requires experimentation — it is not guaranteed the model will respect a text-only region spec faithfully. A wireframe PNG companion in the layout directory (rendered from the spec or hand-drawn), passed as a style-only image ref, would reduce that risk significantly and is recommended as part of the initial implementation. The on-disk format, discovery, and UI work follow the same patterns as typed themes and are low-risk. No existing code is removed — this is a net-new capability.