Pradaslides

PradaSlides

Turn a minimal request into a presentation with a clear communication job, credible content, deliberate audience journey, coherent visual system, and verified delivery artifact. Match the user's language unless they request another.

Operating stance

• Treat slides as an audience experience, not a decorated document.
• Optimize for the user's intended change: a decision, belief, action, understanding, trust, or remembered impression.
• Infer sensible defaults from the material. Ask a question only when the answer would materially change the argument, artifact type, confidentiality, or irreversible work.
• Keep facts, strategy, design intent, build source, previews, and deliverables in separate owned artifacts.
• Use the best slide-production capability already available in the host agent. Do not require a Codex-specific tool.
• Preserve user files. Work in a new project directory unless the user explicitly requests an in-place edit.

Start here

1. Classify the task: new, redesign, fill-template, enhance-existing, critique, or plan-only.
2. Read [intent-playbooks.md](references/intent-playbooks.md) and select one primary intent plus, when useful, one secondary intent.
3. Create the project contracts from [artifact-contracts.md](references/artifact-contracts.md). For a fresh workspace, run:

``bash python scripts/bootstrap_project.py --output --intent ``

1. Scan the runtime when the host's slide capabilities are not already obvious:

``bash python scripts/capability_scan.py --json ``

1. Read [capability-orchestration.md](references/capability-orchestration.md), declare model/tool/runtime capabilities in capability-profile.json, and resolve a conservative execution route:

``bash python scripts/resolve_capabilities.py --profile /capability-profile.json --brief /brief.json --scan-local --output /execution-plan.json ``

1. Follow the workflow below. Do not start visual slide construction before the brief, source ledger, capability route, design system, topology route, generation decision, and deck plan are coherent.

Workflow

1. Establish the communication contract

Write this sentence before outlining:

> By the end, [audience] should [think/feel/do] because [central takeaway].

Resolve or infer:

• audience, context, stakes, prior belief, objections, and decision authority;
• presentation intent and delivery mode: live, leave-behind, asynchronous, or hybrid;
• desired from → to shift and final audience action;
• available time, slide-count constraint, aspect ratio, language, brand, and output format;
• required evidence, source boundaries, confidentiality, and editability.

Record the result in brief.json. Validate it:

python scripts/validate_brief.py /brief.json

Use assumptions for inferred values. Never disguise an assumption as a user instruction.

2. Route the artifact and runtime

Use the resolved execution plan. Never assume that a multimodal model also has slide authoring or rendering, and never assume a text-only model can semantically inspect media. Treat separately connected vision, image-generation, or video-generation models as delegated capabilities with explicit handoff packets, provenance, acceptance checks, and fallbacks.

Choose one artifact route:

| Request shape | Route | |---|---| | New deck from a goal, topic, or sources | new | | Improve an existing deck with freedom to re-outline | redesign | | Keep native slide shells and replace content | fill-template | | Keep visible slides stable; add notes, transitions, or delivery support | enhance-existing | | Diagnose and recommend without changing files | critique | | Produce strategy, outline, copy, and visual specification only | plan-only |

Then choose a production runtime using [runtime-and-delivery.md](references/runtime-and-delivery.md). Prefer:

1. the host's native presentation tool when it can create and render the required artifact;
2. native editable PPTX generation for ordinary business delivery;
3. fixed-stage HTML or Slidev for interactive, code-heavy, or web-native talks;
4. PDF only when editability is unnecessary;
5. raster-first PPTX only when the user explicitly accepts limited editability and accessibility.

If an existing deck must preserve wording, order, or appearance, treat those as invariants and record them in brief.json.

3. Inspect sources and build the evidence ledger

• Inventory every supplied file before outlining.
• Extract text, tables, charts, images, notes, metadata, and page/slide structure with the appropriate host tools.
• For PDFs or visually meaningful source files, inspect both extracted content and rendered pages.
• For attached photos, videos, logos, screenshots, charts, or illustrations, read [media-intelligence.md](references/media-intelligence.md), generate asset-manifest.json, and visually inspect every asset or representative video keyframe before locking the outline.
• If image/video understanding is unavailable, keep semantic review pending and use a human or delegated reviewer. Metadata alone cannot authorize placement. If generation exists without vision, generated media requires external visual approval before final use.
• Record every claim, metric, quotation, and visual asset in source-ledger.json with source location and status.
• Mark invented demo values as scenario; display that label on-slide when the distinction matters.
• Research only factual gaps that matter to the communication job. Prefer primary and authoritative sources.
• Never fabricate citations, metrics, customer claims, testimonials, market sizes, or implementation results.

Validate the ledger before it becomes slide evidence:

python scripts/validate_source_ledger.py /source-ledger.json

Create a technical asset inventory and review contact sheet when media is present:

python scripts/analyze_assets.py /assets --output /asset-manifest.json --contact-sheet /previews/asset-contact-sheet.png --keyframes-dir /previews/video-keyframes

Enrich the generated manifest with semantic roles, subject, message, focal point, text-safe regions, crop tolerance, rights, sensitivity, and intended slide use. Technical metadata cannot determine meaning by itself.

python scripts/validate_asset_manifest.py /asset-manifest.json --require-reviewed

Read [content-and-narrative.md](references/content-and-narrative.md) before planning evidence-heavy decks.

4. Design the audience journey

Construct the journey around the audience's mental state, not the source document's chapter order. Use only the phases the intent needs:

attention → orientation → tension → insight → proof → resolution → decision → retention

For each phase, specify:

• what the audience currently believes or needs;
• the question the next slide answers;
• the emotional or cognitive load;
• the proof required to advance;
• the transition to the next phase.

Avoid artificial drama. A scientific briefing may emphasize orientation and proof; a portfolio may emphasize identity, selected work, process, outcomes, and fit.

5. Establish the visual system, art direction, and topology registry

Read [design-and-visuals.md](references/design-and-visuals.md), [art-direction-and-pptx-reconstruction.md](references/art-direction-and-pptx-reconstruction.md), and [topology-and-layouts.md](references/topology-and-layouts.md). Edit design-system.json and use layout-manifest.json as the default portable topology registry.

Define:

• one intent-fit visual direction and a relevant supplied-reference quality floor;
• canvas, grid, margins, type scale, palette roles, image treatment, and slide furniture;
• a concrete art_direction: visual thesis, material language, edge language, image roles/treatments/reuse rules, native-versus-raster strategy, and three to eight slide families;
• deck-level rhythm: topology variety, focal-mass changes, tone shifts, repetition anchors, and density;
• reusable topology/layout entries with roles, relationships, slots, media capacity, tone support, guardrails, and target-runtime fidelity.

Validate both contracts:

python scripts/validate_design_system.py /design-system.json
python scripts/validate_layout_manifest.py /layout-manifest.json

Select layout by the relationship the audience must perceive, not by decoration or template name. Use role → relationship → topology → layout → safe slots → style. Require a layout_rationale for any custom-* layout.

6. Build the deck plan and visual-generation plan

Create deck-plan.json. Each content slide must have:

• one job and one claim;
• a takeaway title that communicates the claim;
• evidence and its source IDs;
• a visual role and chosen visual form;
• audience journey phase and transition;
• speaker-note purpose;
• layout family, registered layout_id, topology, tone, focal emphasis, and density/slot budget.
• stable asset_ids and a resolved media_plan when media is used; in strict visual mode, multi-asset slides require one complete asset_treatments entry per asset so logos, heroes, screenshots, and video do not inherit the same crop or fallback.

Exceptions: cover, section divider, deliberate pause, and closing identity slides may use non-claim titles.

Apply these tests:

• So what? The claim matters to this audience.
• Why true? Evidence supports the claim.
• Why now/next? The sequence creates momentum.
• Why this visual? The visual performs a communication task.
• What should remain? The audience can repeat the central takeaway after the deck.

Lint before building:

python scripts/lint_deck_plan.py /deck-plan.json --brief /brief.json --source-ledger /source-ledger.json --asset-manifest /asset-manifest.json --design-system /design-system.json --layout-manifest /layout-manifest.json --strict-visual

If image or video generation is usable, read [generative-visuals.md](references/generative-visuals.md) and resolve visual-generation-plan.json. Capability awareness must activate an opportunity audit; do not leave generation as an unused checkbox.

python scripts/validate_visual_generation_plan.py /visual-generation-plan.json --require-resolved

When generation is available and the user asks for a polished, distinctive, visual, launch-quality, portfolio-quality, or reference-matched deck, default to at least one original candidate unless supplied media already performs every important hero/concept job or generation creates factual/brand risk. Record a concrete reason for skip.

If the user provides references, infer transferable principles rather than cloning the composition. If direction is genuinely ambiguous and the choice is consequential, present up to three distinct visual routes with short rationale; otherwise select one and proceed.

Hard visual rules:

• Group before styling; use proximity, alignment, repetition, and contrast to expose structure.
• Use whitespace as organization, not as unused decoration.
• Use one dominant visual idea per slide.
• Meet the reference-quality floor: recognizable identity, decisive scale contrast, inspectable proof, meaningful topology variation, and coherent tone rhythm.
• Treat a visual cluster as a prior, never a typography answer. Resolve the specific product's positioning, audience, personality, proof density, interaction model, language, and brand assets before choosing families, scale, weight, tracking, case, and type color. Two products in the same category should not inherit the same type system without a written rationale.
• Treat material and edge language as first-class tokens. Define how background, surface, depth, frame, curve, overlap, rule, and shadow behave; do not approximate an art direction with only a palette and rounded cards.
• Pair every text role with its actual rendered surface, not just the deck palette. Normal text needs at least 4.5:1 contrast; muted/support text needs at least 3:1. Do not place a dark-tone text token on a light surface (or the reverse) after a mask, override, or image treatment changes the surface.
• A curve, mask, crop, or illustration must clarify hierarchy, reveal a focal subject, carry evidence, or establish a named brand/material motif. If it merely slices a photograph or occupies whitespace, delete it and use a grid, rule, or deliberate crop instead.
• Treat an image slot as a media opportunity, never a fixed template. Resolve each asset's narrative job, focal subject, crop tolerance, text-safe region, scale, and relationship to copy before selecting full bleed, split crop, editorial window, contact sheet, diptych, detail crop, device stage, panorama, mask, or gallery choreography. Repeat a composition only when repetition is an intentional deck anchor.
• Select frame geometry from the evidence: preserve a full garment in a vertical window, use an edge-to-edge macro plus an establishing view for craft detail, give process work a sequence or wide evidence field, and reserve an arch/circle/organic mask for a subject or brand reason. Do not apply one rounded portrait frame to every supplied photo.
• Let presentable type consume the available composition. At a 1600×900 live slide, treat roughly 20–26px as normal body territory and reserve 14–18px for true furniture/captions. If a sparse layout leaves large unused space, enlarge the claim, body, image evidence, or spacing relationship before adding a decorative object.
• Give each used image an explicit role such as hero, process, context, product, detail, evidence, texture, or cutout. Use a slide-family/rhythm map so page silhouettes vary while type, material, edge, and furniture grammar remain coherent.
• Keep authoring and audit language off the audience-facing canvas. Reference IDs, transfer principles, avoid rules, asset credits, crop labels, topology names, benchmark scores, and QA markers belong in notes or metadata unless the audience genuinely needs them.
• Treat photographs, diagrams, tables, and charts as evidence carriers.
• Avoid generic business imagery, ornamental dashboards, arbitrary blobs, and repetitive card grids.
• Do not let CSS gradients, empty device shells, avatar silhouettes, or abstract SVG objects impersonate photography, product evidence, or a finished hero. When a supplied reference derives its quality from real media, use relevant supplied or rights-compatible sourced media, or record a blocking media gap.
• Do not ask an image model to render core slide copy, charts, or exact labels.
• When editable PPTX is requested, rebuild the visual grammar with native text, rules, shapes, annotations, charts, tables, and page furniture. Rasterize only selected photos, texture, approved complex art, or non-reconstructable visual detail; never use a full generated slide as the default editable deck page.
• Maintain projection-safe type. Default minimums: title 35 pt, subhead 24 pt, body 16 pt; use larger text for live speaking decks.
• Keep slide-edge safety margins and account for renderer differences.

7. Produce content and visuals together

• Write audience-facing copy, not production notes.
• Prefer concise claim titles and concrete language.
• Separate slide copy from speaker notes and leave-behind detail.
• Match density to delivery mode: speaking, hybrid, or reading.
• Use native text, charts, tables, and shapes when editability matters.
• Apply the declared native/raster strategy to every slide. A raster asset may support art direction, but it must not contain the only version of critical copy, chart values, source labels, or accessibility meaning.
• Use generated or searched imagery only when it adds specific explanatory or emotional value.
• Honor an explicit preference for sourced photography over generation. Search rights-compatible libraries, select by subject and crop fitness, download the chosen asset locally, record its source page and license,

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: prodigeproject
• Source: prodigeproject/pradaslides
• License: MIT

Install and usage instructions live in the source repository linked above.