PPT Designer

Purpose

Transform a rough topic, source material, or existing deck into a clear, editable presentation with a real story, varied slide rhythm, and visually checked layouts. Treat "智能做 PPT" as the core job: infer structure, choose slide patterns, write concise copy, design the visual system, and verify the result before delivery.

Default to Chinese output when the user writes in Chinese. Preserve the user's requested language, audience, and tone.

Workflow

1. Clarify only the blocking unknowns: topic, audience, slide count, format, deadline, required style, source files, and whether a PPTX file is needed.
2. Extract the story before designing. Identify the audience's decision, the central message, and the evidence that supports it.
3. Write a claim spine: every content slide gets a conclusion-style title, proof object, and short support note.
4. Lock the design system before building slides: size, colors, typography, layout families, chart grammar, icons/images, footer, and page markers.
5. Plan the contact sheet. Avoid repeated title-plus-card-grid layouts. Use at least 4 layout families for decks with 8+ slides.
6. Build slides as editable objects whenever possible. Use charts, diagrams, tables, timelines, images, and callouts as proof objects, not decoration.
7. Render or inspect the deck before delivery. Fix overlap, clipped text, weak contrast, inconsistent alignment, and repeated layouts.
8. Deliver the PPTX plus a short summary of slide count, design direction, and any missing inputs or assumptions.

Slide Strategy

Prefer this structure for a new deck:

• Cover: thesis, audience signal, strong visual or metric cue.
• Context: why this topic matters now.
• Problem or opportunity: make the tension concrete.
• Evidence: data, comparison, workflow, research, or case proof.
• Proposal or solution: what should be done.
• Plan: roadmap, timeline, responsibilities, or operating model.
• Impact: expected outcomes and success metrics.
• Close: decision, call to action, or memorable summary.

For academic or defense decks, use: title, background, problem, method, system/design, experiment/results, innovation, conclusion, Q&A.

For business decks, use: thesis, market/context, customer pain, solution, differentiation, traction/data, business model, roadmap, ask.

Design Rules

• Use claim titles, not topic labels.
• Make one dominant proof object per slide.
• Keep slide text short enough to present aloud; move dense detail to appendix.
• Use direct labels on charts instead of legends when possible.
• Make diagrams explain relationships, not merely list boxes.
• Use restrained color with one accent color for decisions, risk, or emphasis.
• Do not use decorative cards, badges, gradients, or icons unless they clarify structure.
• Keep all repeated elements consistent: headers, page markers, chart labels, footers, margins, and source notes.
• Verify mobile/projector readability: title 28pt+, body 16pt+, chart labels 10pt+ unless the deck is appendix-heavy.

Inputs To Request

Ask for missing inputs only when they affect the deck:

• topic or existing material
• audience and presentation scenario
• target slide count
• language
• visual style or reference deck
• required data, images, logos, or citations
• output format: PPTX, PDF, images, or outline only

If the user provides little detail, make a reasonable first draft and state assumptions.

Quality Gate

Before final delivery, check:

• Every slide has a clear role in the story.
• No three consecutive slides use the same macro layout.
• Text does not overlap, clip, or crowd boxes.
• Colors have enough contrast on projector-sized screens.
• Charts and diagrams prove the slide title.
• Image crops are intentional and not blurry.
• The final file exists, opens, and has the expected slide count.

Reference

Read references/deck-patterns.md when choosing deck structure or layout families for a specific scenario.