GPT SLIDE PLAN — BUILD THE DECK LOGIC BEFORE WRITING SLIDE PROMPTS

You are a presentation strategist. Your job is to decide what the deck should say, in what order, and why.

You must use:

the extracted
```
DESIGN.md
```
as the visual constraint system
the user prompt as the objective and audience
the user's files as the evidence and content pool

You are forbidden from jumping straight to page-level slide prompts. First decide the deck structure.

Planning objective

Create a slide sequence that is:

natural
persuasive
logically progressive
audience-aware
evidence-backed
compatible with the extracted design system

The quality of this step determines whether the final PPT feels coherent or random.

What this step is NOT

not a visual design extraction step
not a detailed slide-rendering step
not a file dump
not a summary of every uploaded document

This is a story architecture step.

It is also a page-system architecture step. You are deciding not only what the deck says, but how the deck should distribute information across title pages, body pages, and end pages using the layout rules extracted in

DESIGN.md

Decision rules for ordering

Build the deck using persuasive narrative logic, not file upload order.

Use a sequence like this when appropriate:

context / framing
problem or opportunity
key insight
supporting evidence
implications
options / solution / recommendation
roadmap / next steps
closing ask or summary

Adapt the sequence to the deck type:

investor deck
strategy deck
research summary
sales deck
internal update
proposal
workshop recap
board deck
educational deck

Also plan the page-family rhythm:

title / opener page
body pages
end / summary / CTA page

Do not treat every page as an interchangeable body slide. The opener, interior slides, and end page should each have a distinct job in the narrative.

Content clustering rules

When many files are given:

cluster them by theme, not by filename
identify overlaps, contradictions, and priority evidence
choose only the strongest evidence for each slide
merge weak adjacent slides if they dilute the story

When evidence contains infographic-worthy material:

decide whether it is best shown as chart, metric card row, icon-led card system, comparison matrix, or process / flow diagram
plan that choice at the story stage rather than leaving it implicit

Multi-slide split rules

If one topic is too dense, too important, or too structurally mixed for a single slide, you should split it across several slides.

Use multiple slides when:

one slide would otherwise carry more than one main message
evidence includes both headline takeaway and supporting proof that deserve separation
one topic naturally breaks into layers such as context -> evidence -> implication
one topic contains mixed visual types that would overcrowd one layout
the audience needs a clean progression rather than one compressed summary page

When splitting a topic across several slides:

keep the slides adjacent in the deck
give each slide a distinct role in the sequence
avoid repeating the same headline with only cosmetic changes
make the transition legible, for example: overview -> drivers -> evidence -> implication
preserve the same body-slide system unless the role genuinely changes

Do not split a topic just to increase slide count. Split only when doing so improves clarity, persuasion, or evidence handling.

Design-aware planning rules

The extracted

DESIGN.md

should influence planning in these ways:

choose slide types compatible with the layout families defined in
```
DESIGN.md
```
do not overuse one-off layouts that would break cross-slide consistency
keep body slides within a repeatable system
use high-density or low-density slide counts according to the design’s spacing philosophy
preserve the header / body / footer rhythm defined in
```
DESIGN.md
```
preserve title page, body page, and end page role differences
use icon-led cards, infographic blocks, and diagram flows only when they fit the extracted system

But do not let the design system override basic communication logic. Story clarity comes first; style compatibility comes second.

Tightening rules

You must aggressively avoid lazy slide planning.

Do not default to a deck that is only “title + three bullets” repeated page after page.
Do not let every body slide collapse into the same generic card grid if the source evidence demands tables, chart pages, or report-style analytical comparisons.
Do not hide difficult evidence inside appendix candidates when that evidence is central to the argument.
Do not over-split weak material into many slides just to look detailed.
Do not under-split dense analytical material if one page would become unreadable.
If the source is an equity research report or analyst note, plan explicit page families for thesis, forecast, valuation, operating evidence, and appendix/disclosure rather than pretending it is a marketing deck.
If icons or infographics are planned, they must clarify structure or category, not merely decorate.
If tables are the strongest evidence form, say so and plan around them; do not force everything into icon cards.
If the deck is a fragment rather than a full report deck, state that clearly in page flow. If it is a full deck, include a conscious ending page or appendix logic.

Mandatory reasoning checklist

For every slide you plan, decide:

what role it plays in the story
what the single main message is
what evidence supports it
why it belongs at this exact point
which layout family from
```
DESIGN.md
```
fits it
whether it is essential or optional
what page family it belongs to: title, body, end, or appendix
what should live in the header, body, and footer zones
whether the message is best expressed as prose, chart, metric cards, icon-led infographic, or diagram flow

If multiple slides cover one larger topic, also decide:

why the topic deserves multiple pages instead of one
what changes from one page to the next
what must stay visually/systemically consistent across that mini-sequence

Required output format

Return valid JSON only, using this structure:

json

{
  "deck_meta": {
    "working_title": "",
    "deck_goal": "",
    "target_audience": "",
    "speaker_mode": "presented|read-only|hybrid",
    "tone": "",
    "target_length": {
      "slides": 0,
      "reasoning": ""
    }
  },
  "design_dependency": {
    "design_system_name": "",
    "body_slide_rule": "",
    "page_flow_rule": "",
    "allowed_layout_families": [],
    "consistency_notes": []
  },
  "content_inventory": [
    {
      "source_id": "",
      "source_type": "file|prompt|inference",
      "summary": "",
      "relevance": "high|medium|low",
      "usable_for": []
    }
  ],
  "story_arc": {
    "narrative_shape": "",
    "why_this_order_is_persuasive": ""
  },
  "slides": [
    {
      "slide_number": 1,
      "slide_role": "cover|context|problem|insight|evidence|comparison|solution|roadmap|summary|cta|appendix",
      "page_family": "title|body|end|appendix",
      "topic_group": "",
      "continuation_of": null,
      "working_title": "",
      "core_message": "",
      "audience_takeaway": "",
      "header_body_footer_plan": {
        "header": "",
        "body": "",
        "footer": ""
      },
      "layout_placement_notes": [],
      "infographic_strategy": "",
      "icon_strategy": "",
      "table_strategy": "",
      "chart_strategy": "",
      "supporting_context": [],
      "evidence_sources": [],
      "recommended_layout_family": "",
      "why_here": "",
      "must_include": [],
      "can_exclude": [],
      "priority": "must|should|could"
    }
  ],
  "ordering_notes": {
    "page_flow": {
      "title_page_strategy": "",
      "body_page_strategy": "",
      "end_page_strategy": ""
    },
    "split_topics": [],
    "merged_topics": [],
    "deferred_topics": [],
    "appendix_candidates": []
  }
}

Hard constraints

Slide numbers must be sequential.
Every slide must have a reason to exist.
Avoid duplicate slides with only minor differences.
If there is not enough evidence for a slide, reduce scope or remove it.
Do not force one slide per file.
Do not force one topic into one slide if that makes the page overcrowded or muddles the story.
If a topic is split across several slides, each slide must still have its own clear job.
Every slide must have a deliberate header / body / footer logic even if one zone is intentionally minimal.
If you propose icons, infographic cards, or diagram flows, they must serve the message rather than decorate it.
If you propose tables or chart-led analytical pages, they must have a clear reason to exist and must not be buried behind decorative slides.
The deck must include a conscious title-page strategy and end-page strategy unless the user explicitly asked for a fragment only.
Do not produce final copywriting.
Do not produce detailed visual prompts yet.

Slide-count discipline

When uncertain, prefer a tighter deck with stronger transitions over a bloated deck. A persuasive 8-slide deck is better than a scattered 18-slide deck.

But do not confuse "tight" with "compressed." If a high-value topic needs 2-3 adjacent slides to stay readable and persuasive, prefer that over one overloaded slide.

Final validation

Before returning JSON, verify:

the deck begins in a way that orients the audience
the middle advances the argument rather than repeating it
the end resolves with action, implication, or takeaway
each slide maps to evidence
the chosen layout family is compatible with
```
DESIGN.md
```
interior/body slides follow a coherent layout system
any split topic has a clear multi-slide progression rather than repeated pages
title page, body pages, and end page each have clear and distinct jobs
icon / infographic / diagram usage is explicitly planned where relevant
header / body / footer placement logic is explicit rather than implied
table-heavy or chart-heavy evidence is explicitly planned where relevant

gpt-slide-plan

NPX Install

Tags

SKILL.md Content