Presentation Narrative

Presentation Narrative

Child of presentation-builder. This skill is responsible for selecting the right narrative flow, generating a structured slide outline with action titles and visual tags, and presenting it for approval before any visual work begins.

Scope: Narrative flow selection, slide outline generation, audience adaptation, content structuring, and per-slide speaker notes (mandated by Hard Rule 8). Does NOT handle visual design, styling, or final assembly — those are handled by siblings.

Siblings:

• presentation-datavis — charts, tables, data visualization, data-driven slides
• presentation-diagrams — architecture diagrams, flowcharts, system visuals
• presentation-styling — templates, branding, colour palettes, layout conventions
• presentation-renderer — final assembly, PPTX/HTML export, format conversion

Triggers

Invoke this skill when the user:

• Says "build a presentation", "create a deck", "put together slides"
• Provides a topic combined with a narrative or outline request
• Mentions a consulting presentation, pitch deck, status update, architecture review, retrospective, or training presentation
• Is routed here by presentation-builder after intake

When NOT to Use

1. Flow Selection Logic

Based on audience + purpose, auto-select from the 23 flows defined in narrative-flows.md. The selection matrix:

The user can always override automatic selection by naming a specific flow.

2. Content Generation from Context

Gather content using the following priority order:

1. Project context — Read PROJECT.md, COMPONENT.md files if available in the current working directory or specified project path.
2. Problem statement — If the user provides a problem statement, brief, or objective, use it as the narrative spine.
3. User-provided documents/data — Read any files, links, or data the user supplies (reports, metrics, specs).
4. Standalone mode — If no project context exists, rely on LLM knowledge combined with user input to generate content.

For each slide, generate:

• Title — action title (the takeaway, NOT the topic)
• Key message — one sentence summarizing the slide's point
• Bullet points — 3-5 supporting points
• Speaker notes — what to say when presenting this slide
• Visual tag — one of [DIAGRAM], [CHART], [IMAGE], [TABLE], or text if no visual is needed. Include a brief description after the tag (e.g., [CHART: revenue growth Q1-Q4]).

3. Audience Adaptation

Reference audience-profiles.md for detailed tone, depth, and slide count norms. Summary:

4. Outline Output Format

Always produce the outline in this exact structure:

## Slide Outline: [Presentation Title]
**Flow:** [framework name]
**Audience:** [type]
**Estimated slides:** [count]
**Estimated time:** [minutes]

### Slide 1: [Title Slide]
- Title: [Presentation title]
- Subtitle: [Date, presenter, team]
- Visual: [Logo placement]

### Slide 2: [Action Title — the takeaway]
- Key message: [one sentence]
- Supporting points: [bullets]
- Visual: [CHART: description] or [DIAGRAM: description] or text
- Speaker notes: [what to say]

### Slide 3: [Action Title — the takeaway]
- Key message: [one sentence]
- Supporting points: [bullets]
- Visual: [TABLE: description] or [IMAGE: description] or text
- Speaker notes: [what to say]

... (continue for all slides)

### Appendix slides (if applicable)
- Appendix A: [Title] — [purpose]
- Appendix B: [Title] — [purpose]

5. Hard Rules

1. Always read user profile/capability map from parent before generating content. The parent provides audience, context, and constraints.
2. Always present outline for approval BEFORE generating visuals. Never skip the approval gate.
3. Action titles are MANDATORY. The title IS the takeaway, not the topic. Bad: "Q3 Revenue". Good: "Q3 Revenue Exceeded Target by 12%".
4. One idea per slide. If a slide has two distinct points, split it.
5. Tag visual needs explicitly: [DIAGRAM], [CHART], [IMAGE], [TABLE] — these tags drive parallel dispatch: [CHART]/[TABLE] to presentation-datavis, [DIAGRAM] to presentation-diagrams.
6. Use "professional" language for banking/executive audiences and "accessible" language for mixed audiences.
7. Never exceed audience-appropriate slide count without explicit user approval. If content demands more slides, ask first.
8. Speaker notes are required for every content slide (title and divider slides excluded).

6. Structured Interaction

Follow this sequence every time:

Step 1: Confirm Goal and Audience

• If routed from parent, use the intake data provided.
• If invoked directly, ask: What is the presentation about? Who is the audience? What is the desired outcome?

Step 2: Select Narrative Flow

• Auto-select using the flow selection matrix (Section 1).
• Present the selected flow with a one-line rationale.
• If the user names a specific flow, use it without question.

Step 3: Gather Content

• Check for project context (PROJECT.md, COMPONENT.md).
• Read any user-provided files or data.
• If standalone, synthesize from LLM knowledge + user input.
• Ask clarifying questions only if critical information is missing.

Step 4: Generate Slide Outline

• Produce the full outline in the format defined in Section 4.
• Apply audience adaptation rules from Section 3.
• Tag every visual need for downstream dispatch.

Step 5: Present for Approval

• Show the complete outline to the user.
• Ask: "Does this outline capture what you need? Any slides to add, remove, or restructure?"
• Iterate until the user approves.

Step 6: Return to Parent

• Pass the approved outline back to presentation-builder for parallel dispatch to presentation-datavis, presentation-diagrams, and presentation-styling, with final assembly by presentation-renderer.
• If invoked standalone (no parent), offer to expand the speaker notes in detail or hand off to sibling skills.

Anti-Patterns

See also

• business-writing — the words themselves, and the same lead-with-the-outcome rule applied to slide headlines (state the finding, not the topic), plus every non-deck surface the same message has to survive: the covering email, the one-pager, the follow-up message.