Slide System Studio

Slide design workbench

Build the slide system first.

Choose the job, proof route, template grammar and delivery mode. The preview updates with each decision so the deck is not just a theme pasted on top.

Purpose + proof + style
Proposal
Make the next decision obvious.

A deck should show the audience what to believe, why it is true and what to do next.

01 Purpose What must the deck do? 02 Proof What makes it credible? 03 Style What should it feel like? 04 Delivery What should the agent build?

Builder

Compose the deck brief.

Pick the job, proof route, style and handoff. The canvas updates while the export contract stays ready.

Purpose

Pick what the deck has to accomplish before choosing how it looks.

Live deck preview
Proposal
Make the next decision obvious.

A deck should show the audience what to believe, why it is true and what to do next.

Step 1 of 4 Choose one layer option.
4 options

Optional library

Pick a visual recipe.

Choose a template structure, inspect how it handles common slide jobs, then remix the colors before publishing.

Selected template

Loading template options from the vendored open template pack.

Template preview Loading
Title Proof Appendix
Fine-tune in Frame Lab
Page 1

Frame lab

Tune the frame pack before generation.

Browse many frame systems, remix palette and density, preview real slide jobs, then download a pack the agent can use.

Slide Frame Lab
1. Intake 2. Frames 3. Tune 4. Download
Cobalt Grid Template + palette + slide job
01 / 04
Frame System

A good deck is a system, not a skin.

The frame pack preserves template grammar, palette roles, slide jobs and QA rules so the next agent does not guess.

Output

Leave with something an agent can use.

Copy the version your agent or repo workflow needs. The summary shows exactly what will be generated.

How to use it

  • 1. Start with sources. Collect the brief, links, screenshots, charts, assets and claims before generation.
  • 2. Use the prompt or JSON. Paste the prompt into Codex or save the JSON as `work/design-contract.json`.
  • 3. Generate a small slice. Build title, proof, comparison and appendix slides before making the full deck.
  • 4. Run browser QA. Check desktop, short laptop and mobile before publishing.

Method

What the workbench protects.

The product keeps taste, evidence and delivery separate. References can inspire the system, but the exported deck should still be original.

  • Source mode. Start from a topic, pasted notes or imported files, but convert them into claims, assets and open questions before layout.
  • Theme layers. Treat color, type, shape, stroke, shadow, logo and image style as editable tokens, not as one frozen theme.
  • Template mixing. Layout recipes can mix. A template is grammar, not a prison.
  • Delivery quality. Presenter notes, audience view, offline prep, overview mode and mobile behavior belong in the definition of a good deck.
  • Calm task flow. Pick the path, run the next step, review the artifact, then expand. Do not generate a full deck before the first slice works.
Copied