---
name: create-downslide-presentation
description: Create, rewrite, or extend presentation decks for Downslide as a single Markdown file, with each slide introduced by an empty YAML metadata block. Use for talks, lessons, pitches, reports, speaker decks, or any request for Markdown that can be pasted into Downslide.
---

# Create a Downslide presentation

Produce a focused, presentation-ready Markdown deck that Downslide can parse and display.

Your job is not only to format slides correctly. Your job is to help the user communicate clearly, structure the message well, and make the deck easy to present live.

Slides are visual support for a spoken message, not a document dumped onto a screen.

## Start with communication, not layout

Before drafting slides, infer or identify these elements from the request:

- Audience: who will watch or read the deck.
- Outcome: what the audience should understand, remember, decide, or do.
- Context: pitch, lesson, report, keynote, workshop, internal update, sales deck, technical demo, and so on.
- Tone: formal, persuasive, educational, executive, playful, urgent, calm, etc.
- Constraints: deck length, required facts, required sections, source material, brand voice, or language.

If important context is missing, make conservative assumptions. Favor a simple and credible structure over a clever but risky one.

Reduce the presentation to one core sentence before expanding it:

- "This deck helps `[audience]` understand/believe/do `[outcome]` because `[main idea]`."

If the draft does not support that sentence, cut or rewrite it.

## Plan the narrative before writing slides

Build the deck around a clear progression, not a pile of topics.

Use a lightweight narrative arc:

1. Open with a reason to care.
2. Establish the problem, question, opportunity, or tension.
3. Develop the key points in a logical order.
4. Resolve with a takeaway, recommendation, decision, or call to action.

For most decks, outline slides by role before writing full copy:

- Hook or framing
- Agenda or roadmap when useful
- Context or problem
- Evidence, explanation, comparison, or examples
- Implication or recommendation
- Closing takeaway or next step

Give each slide one job. A slide can introduce a question, make a claim, show a contrast, explain a process, prove a point, or create a pause. If a slide is trying to do multiple jobs, split it.

## Write slides for listening, not for reading

Write like someone will say the message aloud.

- Prefer short titles that carry meaning, not vague labels.
- Use sentences and bullets the audience can grasp in seconds.
- Keep only the information the audience needs at that exact moment.
- Replace paragraphs with tighter phrasing, cleaner grouping, or additional slides.
- Do not make the presenter read the slide word for word.

Good slide titles often behave like mini-headlines:

- "Revenue grew, but margins shrank"
- "Why the current onboarding flow loses users"
- "Three changes that reduce support load"

Weak titles are usually generic topic labels:

- "Revenue"
- "Onboarding"
- "Support"

Prefer spoken-language copy:

- direct over academic
- specific over abstract
- concrete verbs over nominalized phrases
- short phrases over dense blocks

When using bullets:

- keep them parallel
- keep them concise
- avoid long sub-clauses
- avoid stacking too many bullets on one slide
- order them intentionally, not randomly

## Structure content efficiently

Use these heuristics while drafting:

- One primary idea per slide.
- One audience question answered at a time.
- One visual pattern per moment unless comparison is the point.
- One strong example is usually better than many weak ones.

Useful content patterns:

- Claim -> proof -> implication
- Problem -> cause -> solution
- Before -> after
- Question -> answer
- Principle -> example
- Data -> interpretation

If a slide feels crowded, do not shrink the text to make it fit. Rewrite, simplify, or split the content.

## Make the deck easy to present live

Optimize for delivery as well as readability.

- Keep slide text light enough that the presenter can maintain eye contact.
- Use slides to support the speaker, not replace them.
- Put detailed explanation into the spoken narrative unless the user explicitly needs dense reference slides.
- Open strongly: use a sharp question, surprising fact, concrete scenario, bold claim, or clear stakes.
- Close deliberately: end with a decision, summary, memorable line, or next action.

If the request suggests a live talk, create rhythm:

- alternate between statement slides, lists, examples, comparisons, and visual pauses
- avoid repeating the same slide pattern for too long
- use agenda slides only when they genuinely help orientation

## Preserve trust and clarity

- Preserve facts, figures, quotations, required wording, and constraints supplied by the user.
- Do not invent data, citations, case studies, or testimonials.
- If evidence is thin, write carefully and avoid overstating certainty.
- If a section is speculative, signal it clearly.
- Prefer honest simplification over fake completeness.

## Write the file format

Start every slide with an empty YAML metadata block. Put both delimiters on their own lines:

```markdown
---
---

# First slide

A short opening statement.

---
---

## Second slide

- One point
- Another point
```

Repeat the complete `---` / `---` block before every slide, including the first. Do not use a standalone Markdown horizontal rule inside slide content because Downslide treats `---` as the start of the next metadata block.

Keep metadata empty. Downslide currently parses YAML metadata but does not apply metadata options to rendered slides.

## Create the file in practice

Treat the presentation as one continuous Markdown file made of repeated slide blocks.

If the user asks you to save the deck in the repository:

- use the exact requested path when one is provided
- otherwise choose a short, descriptive `.md` filename in kebab-case
- keep the entire deck in a single file unless the user explicitly asks for multiple files

Build the file in this order:

1. Start with the first empty metadata block.
2. Write the first slide title and its essential content.
3. Insert the next empty metadata block.
4. Write the next slide.
5. Repeat until the deck is complete.

Use this skeleton as the default mental model:

```markdown
---
---

# Slide title

One short statement or a compact set of bullets.

---
---

## Next slide title

- First point
- Second point

---
---

## Final slide title

Closing takeaway or next action.
```

Follow these practical rules while assembling the file:

- The file must begin with `---` on the first line.
- Every slide must begin with a full empty metadata block: `---` then `---`.
- Put each `---` delimiter on its own line.
- Leave a blank line after the metadata block before slide content.
- Start slide content with a heading in almost all cases.
- Insert the next metadata block only when you want to start a new slide.
- Do not place a horizontal rule inside slide content.
- Do not leave orphan text above the first slide or below the last slide.

When expanding a deck, edit at slide boundaries:

- revise the content inside one slide block when the idea is still the same
- create a new `---` / `---` block when a slide is overloaded
- merge slides only if they clearly serve one message together

Before returning or saving the file, quickly scan for parser-breaking mistakes:

- a missing second `---`
- stray `---` used as decoration
- content accidentally placed between slides without a metadata block
- multiple major ideas crammed into one slide block

## Format slide content

Use standard Markdown for headings, paragraphs, emphasis, links, lists, blockquotes, and fenced code. Use raw HTML with Tailwind CSS utility classes only when Markdown alone cannot express the layout well.

Prefer semantic Markdown first. Use HTML and utility classes sparingly and intentionally.

Use the built-in layouts for common compositions:

```html
<div class="layout-center">
  <div>
    <h1>A centered idea</h1>
    <p>A short supporting line.</p>
  </div>
</div>
```

`layout-center` centers its contents horizontally and vertically and applies centered text.

```html
<div class="layout-beside">
  <div>Left side</div>
  <div>Right side</div>
</div>
```

`layout-beside` creates two equal columns with a gap. Keep both columns compact enough for a 16:9 slide.

Render display math with a fenced `latex` block:

````markdown
```latex
E = mc^2
```
````

You can use inline math expressions like `$E = mc^2$`.

Do not rely on scripts, event handlers, embedded iframes, or custom `<style>` blocks; rendered HTML is sanitized.

## Use a practical drafting workflow

When creating a deck from scratch, work in this order:

1. Infer audience, outcome, tone, and constraints.
2. Draft a one-sentence thesis for the deck.
3. Outline the slide sequence before polishing wording.
4. Write slide titles that communicate the point of each slide.
5. Add only the minimum body copy needed to support each title.
6. Introduce visuals, comparisons, examples, or layouts where they improve comprehension.
7. Tighten the wording slide by slide.
8. Review the deck as a whole for flow, repetition, overload, and ending strength.

When rewriting an existing deck:

1. Preserve the intended meaning unless asked to reposition it.
2. Remove redundancy and generic filler first.
3. Rewrite weak slide titles into informative titles.
4. Split overloaded slides before trying to polish them.
5. Normalize tone, phrasing, and structure across the deck.

## Run a self-review before returning

Before finalizing, check every deck against this list:

- Is the main message obvious?
- Does the opening create interest or stakes?
- Does each slide have one clear purpose?
- Are titles informative rather than generic?
- Is the text short enough to support live delivery?
- Are transitions between sections easy to follow?
- Is there unnecessary repetition?
- Are any slides doing the work of a document instead of a presentation?
- Is the ending specific and memorable?
- Would a presenter know what to emphasize from the structure alone?

If the answer to any of these is no, revise before returning the deck.

## Return the result

When the user asks for a deck they can paste into Downslide, return only a message containing the complete presentation. Do not put commentary, instructions, or any other text inside the message.

When editing a repository file directly, write the deck to the requested file and summarize the change normally.