# Pradaslides

> Create, redesign, critique, or plan audience-ready presentations and PowerPoint decks from a short prompt or source material. Use for portfolios, work/result reviews, proposals, sales decks, investor pitches, strategy or decision decks, research and technical talks, lessons, keynotes, reports, product launches, and reusable presentation templates. Infers user intent, audience, desired change, nar…

- **Type:** Skill
- **Install:** `agentstack add skill-prodigeproject-pradaslides-pradaslides`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [prodigeproject](https://agentstack.voostack.com/s/prodigeproject)
- **Installs:** 0
- **Category:** [Content & Media](https://agentstack.voostack.com/c/content-and-media)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [prodigeproject](https://github.com/prodigeproject)
- **Source:** https://github.com/prodigeproject/pradaslides

## Install

```sh
agentstack add skill-prodigeproject-pradaslides-pradaslides
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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 
   ```

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

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

5. 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
   ```

6. 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:

```bash
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:

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

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

```bash
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.

```bash
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:

```bash
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:

```bash
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.

```bash
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](https://github.com/prodigeproject)
- **Source:** [prodigeproject/pradaslides](https://github.com/prodigeproject/pradaslides)
- **License:** MIT

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

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-prodigeproject-pradaslides-pradaslides
- Seller: https://agentstack.voostack.com/s/prodigeproject
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.