Marp Deck Planner

Marp Deck Planner

Purpose

Generate a presentation plan, not a finished deck.

The output must describe:

• slide sequence
• slide intent
• content structure (with refined, presentation-ready language)
• suggested visuals (described, not generated)

The planner must not generate diagrams, Mermaid code, or images.

Critical difference from a simple outline: This is a transformation task. Raw definition content must be refined into compelling presentation language that maintains fidelity to the original intent while improving clarity, impact, and professionalism.

Content transformation principles

What to preserve

• Core message and intent - never change what the definition is trying to communicate
• Key facts, data, and claims - maintain accuracy
• Logical flow and relationships between concepts
• Constraints specified in the definition (tone, audience, scope)

What to transform

• Wording and phrasing - convert casual/raw language into presentation-ready copy
• Structure and emphasis - reorganize for maximum impact
• Framing - find the most compelling angle for each message
• Specificity - make vague statements concrete; make verbose statements concise

Quality standards for presentation language

DO:

• Use active voice and strong verbs
• Lead with the insight, then support it
• Make titles declarative and specific (not generic labels)
• Use parallel structure within slide content
• Employ concrete, vivid language over abstractions
• Frame messages from the audience's perspective

DON'T:

• Copy-paste wording from the definition verbatim
• Use filler words ("basically", "essentially", "in order to")
• Create titles that are just topic labels ("Overview", "Background")
• Stack multiple complex ideas on one slide
• Use jargon without defining it first

Output format

Produce a single Markdown file with this structure:

• Deck title:
  # <Deck Title> – Presentation plan

• Slide separator:
  A line containing only: ---

• Standard slides must contain:

  • ## Title
  • ## Structure
  • ## Content
  • (optional) ## Image

• Section divider slides must contain:

  • ## Section
  • The section name on the next line
    (no other fields)

• The file must be saved as:
  planning/deck-plan.md

Formatting rules

• Use bullet points, short phrases, and tables
• Include a full prose paragraph only when the message is important enough to warrant an entire slide
• No slide numbering
• Keep titles short, specific, and high-signal
• Prefer parallel phrasing across slides in the same section

Workflow

1. Parse and internalize the definition

From definition/deck-definition.md, extract:

• Deck title (if present)
• Ordered section names
• Key messages for each section
• Explicit constraints (tone, audience, slide limits, mandatory topics)

Important: Understand the intent behind each message, not just the literal words.

2. Plan the slide sequence

• Optionally add 1–3 introductory slides before the first section when context is required
• For each section:
  • Add one section divider slide
  • Add 2–5 standard slides to cover the section's key messages
• Add a closing / next-steps slide only if the definition implies a call to action

3. Map and refine key messages

For each key message:

1. Identify the core insight - what's the one thing this message needs to communicate?
2. Find the compelling angle - why does this matter to the audience?
3. Craft a declarative title that captures the insight (not just labels the topic)
4. Structure supporting points to build toward the title's claim

Example transformation:

Definition says:
"We need to talk about how our current system has problems with scalability and this causes issues when we try to grow"

Presentation plan says:

Title: "Current architecture cannot scale beyond 50K users"

Content:

• Three infrastructure bottlenecks limit growth
• Database queries degrade 40% per 10K user increase
• Resolution requires fundamental re-architecture, not patches

4. Define slide content (planning level)

For each standard slide:

## Title

Create a specific, declarative title that:

• States the slide's core message (not just the topic)
• Uses concrete language
• Could stand alone as a key takeaway

Bad: "Market Overview"
Good: "Enterprise SaaS market growing 23% annually"

## Structure

Describe layout intent using presenter's perspective:

• "Two columns: problem left, solution right"
• "Vertical flow building to conclusion"
• "Three-part framework with equal emphasis"

## Content

Provide refined bullet points describing what goes on the slide.

This is where transformation happens:

• Rewrite definition content in presentation voice
• Use specific, active language
• Structure points for progressive disclosure
• Lead with the "so what"

Example:

From definition:
"Users don't really understand how to use the feature and there's confusion about when to apply it"

In Content section:

• 67% of users unaware the feature exists
• Those who discover it misapply it in 40% of cases
• Root cause: hidden in settings, no contextual triggers
• Proposed: in-line prompts at relevant workflow moments

5. Describe visuals (no generation)

Add a ## Image section only when a visual clearly reinforces understanding

The ## Image section must contain:

• A natural-language description of the visual
• The purpose of the visual (what it clarifies or reinforces)

Examples:

• "Simple flow diagram: User action → System response → Feedback loop. Purpose: Show the circular nature of the interaction, not linear."
• "Side-by-side comparison: Current state (fragmented tools) vs. Future state (unified platform). Purpose: Visual contrast makes the value proposition immediate."
• "Stacked bar chart showing cost breakdown across three scenarios. Purpose: Make financial impact concrete and comparable."

Rules:

• Do not generate Mermaid code
• Do not reference files, assets, or tasks
• Do not assume the visual will actually be created

If a slide works better with text alone, omit ## Image.

Slide patterns (recommended)

Use these as defaults unless the definition suggests otherwise:

Opening framing slide

• Lead with the high-stakes context or question
• 2–4 brief statements that establish why this matters
• Title: Problem statement or opportunity framed

Insight slide

• One core principle or finding
• 3–5 supporting points building the case
• Title: The insight itself, stated declaratively

Comparison slide

• Two-column parallel structure
• Mirrored bullet points for easy scanning
• Title: What's being compared and the conclusion

Process/journey slide

• Sequential steps or phases
• Each with brief outcome or milestone
• Title: The transformation or path being described

Framework/model slide

• 2×2 matrix, Venn diagram, or categorization
• Each segment defined and labeled
• Title: The organizing principle

Evidence slide

• Data points or examples supporting a claim
• Visual emphasis on the key number or pattern
• Title: The claim being supported

Quality checks (mandatory)

Before finalizing, ensure:

✓ Every section in the definition has a section divider slide
✓ All key messages are represented (though reworded and refined)
✓ No slide contains long-form prose (unless intentionally emphasized)
✓ Slide titles are specific and declarative, not generic labels
✓ Content bullets are in presentation voice, not copied from definition
✓ Slide intent is unambiguous and builds a narrative arc
✓ Visuals are described with clear purpose, not implemented
✓ The plan reads like a professional presentation structure, not an outline

Example transformation

From definition:

"Talk about the reasons why we should consider moving to cloud infrastructure and what benefits that might bring"

In presentation plan:

Title: Cloud migration reduces costs 35% while improving reliability

Structure:
Two-part reveal: Cost impact first, then operational benefits

Content:

• Current on-premise infrastructure costs $2M annually
• Cloud-native approach projects at $1.3M (35% reduction)
• Built-in redundancy eliminates single points of failure
• Auto-scaling handles traffic spikes without over-provisioning
• Team shifts from maintenance to feature development

Image:
Cost comparison graphic: Stacked bars showing on-premise vs. cloud total cost of ownership over 3 years. Purpose: Make the financial case visual and undeniable.

Final note

The output must remain a planning artifact that can be directly executed by a deck builder, but the language and framing should already be presentation-ready. Think of this as the work a professional presentation consultant would do: understanding the raw content and transforming it into a compelling narrative structure.