youquan-he/ppt-template-animator

Creating PowerPoint Presentations from Materials and Conversation

The goal is to create an editable, well-animated presentation that aligns with the user's purpose, contains complete content, and uses appropriate motion. Templates can provide full-page layouts, local components, or animation methods; they do not dictate the final content or page types. Follow the five steps below, then perform content, visual, and motion review. See README.md for installation and self-contained examples, production-tools.md for script parameters, and design-and-review.md for design specs, Chinese typography, storyboarding, and review methods. These references are included in this package and do not require additional Skill installations.

First, determine whether the task is creating from scratch, recomposing from reference templates, strictly following a template, or only polishing formatting. Adhere to the scope of this task: allow original recomposition when the user permits deconstruction; do not alter content, page order, or master when the user explicitly requires fidelity or only formatting. Do not default to using fixed templates, mandatory tools, or whole-page image generation from other Skills for all tasks.

If a preferences.local.json file exists in the current directory, read its local template directory, visual preferences, and previously studied animation records; these are the user's default preferences, but explicit requirements in the latest task take priority. If the file does not exist, select styles based on the current request without assuming access to the author's private template library. See preferences.example.json for a configuration example.

When the user requests "elaborate animations, smooth, advanced motion, cool effects," follow the advanced motion workflow first: study the source continuous sequence of the specified animation library → determine the transferable mechanism and visual direction → preserve or rebuild natively → replace/combine content → verify playback. In storyboarding, first determine the animation mechanism and required objects/states, then design the content-bearing layouts; do not create a set of static slides and then batch-add fades or fly-ins as a shortcut. Basic effects may still be used for supplementary explanations but cannot replace the core advanced effects requested by the user.

When scrolling text, slot-machine-style openings, or campaign role reveals are needed, follow the scrolling text opening method to organize editable text columns, window masks, handle, and sound, and verify playback in the target slides; this is an optional scene mechanism, not the default style for all covers.

When the user provides a reference video, specifies template slides, or asks to later reproduce "effect X" with tuned animations, follow the video-to-reusable-effect workflow to record observable objects, states, and timing, cross-check parameters with the source PPTX, and create and verify editable target slides. Video can only prove visible effects; do not write inferences as precise parameters when source files are missing, and do not make third-party authors' plugins, private paths, or entire prompts dependencies of this Skill.

Existing templates may be called preferentially, but animations must be added to the called templates. For animation production tasks, first select suitable full pages or components, then add meaningful native object animations or continuous scenes based on the new content; even if the template originally had animations, simply replacing text and images is not acceptable. Preserve still-applicable original timelines and record the new locations, objects, effects, and playback results. For tasks explicitly requiring static only, formatting only, or a strict prohibition of new animations, follow that requirement.

1. Ensure All Supplied Materials Have a Clear Destination

• Review the current request and related conversation history, and list the files, images, data, text, mandatory points, and previously identified issues provided by the user. Differentiate between content materials, design/animation references, and background information; the user's explicit purpose takes priority. Do not misidentify a library with hundreds of alternative templates as content that must all be stuffed into the presentation.
• Create a material ledger in the working directory, registering independent images, tables, datasets, chapters, or mandatory knowledge points. Expand long documents enough to discover missing pages/chapters/figures/tables. Use the fields from material-ledger.md.
• All content materials provided by the user are to be placed in the body or appendix by default, mapped to final page numbers and specific objects/paragraphs. Reading them, downloading them, writing them in a plan, or only providing source links does not count as application. Images and data that must be displayed cannot be hidden only in speaker notes.
• Integrated expression is allowed, but the ledger must retain the contribution and location of each material. Cropping, redrawing, and summarizing should preserve key evidence and original intent; do not replace required original images with generic illustrations or generated images.
• Duplicate, blurry, unopenable, irrelevant, or contradictory materials cannot be silently omitted. Record issues and handling plans; when all materials are required, do not exclude them arbitrarily. If duration/page count conflicts with full presentation, first create a body-plus-appendix plan, then ask the user about incompatible constraints.

2. Infer Needs and Theme from the Conversation

• Before selecting templates, write a short brief: purpose, audience, setting, core theme, one-sentence claim, required materials, length/duration, language, delivery format, and visual tone. State whether it is primarily for live presentation, self-reading, or both. Latest explicit instructions and confirmed preferences take priority over template examples.
• Differentiate between "explicit requirements," "reasonable inferences," and "still uncertain." Determine the theme based on content and context, not just file names, template names, or the first image. When information is sufficient to act, use reasonable defaults without repeatedly asking the user what has already been stated.
• Create a narrative outline first, then select page types. For each page, write: what question it answers, what the audience should remember, what materials support it, what composition is used, and how animation aids understanding. Use conclusion- or question-style titles for content pages; evidence should explain its significance to the audience. The ending should reference the opening question.
• For live presentation scripts, record the estimated speaking time, initial state, each click, reading pauses, and transitions. Check the total duration; do not mechanically assume one minute per page. Speaker notes, production notes, and internal time budgets stay in notes or working files; page text targets the final audience.
• Reuse user feedback from the current task, especially issues like monotonous templates, mechanical animations, or crowded text/graphics. When modifying existing slides, first locate the problem and affected pages, then decide on partial adjustments or complete redesign.

3. Learn Design and Animation Methods from Templates

• Reuse existing template indexes; run template_catalog.py scan when necessary. Statistics like animation count or image area are only for filtering and cannot be used to declare a template as "elaborate."
• When the user specifies an animation reference library, search it for continuous scenes suitable for the target narrative; use study_motion.py to study paths, rotation, scaling, synchronization/staggering, masks, and Morph states. Existing study records are only for shortening retrieval; actual source files and applicability still need verification.
• In a large library, compare at least three design series suitable for the theme, looking not only at covers but also testing the hardest evidence images, comparison pages, and process pages. Use full-size PNGs, full-slide thumbnails, and actual playback for judgment.
• "Vibrant colors, distinct theme" is an explicit visual requirement: choose expressive main and accent colors, thematic images/graphics, and large-scale compositions; first present the cover with real content and representative content pages. Do not revert to black-gray-white with a small accent color without explanation, and do not substitute thematic expression with piled-up color decorations. Branding, serious contexts, or the user's explicit request for this direction can override it.
• Once a direction is selected, establish full-presentation design specs: thematic tone, background, Chinese/Latin fonts, font size hierarchy, semantic colors, spacing, image handling, and density. Use the theme/direct style report from decomposition tools and cross-reference with rendered images; fix visual rules, vary composition by content. First verify representative difficult pages, then expand to the full presentation.
• Record transferable "animation plans": source template and page number, object, initial state, trigger order, duration/delay, motion direction, object relationships, final state, and applicable scenarios. Learn through timeline and playback, not just by copying effect names.
• Migrate animations semantically: progressive reveal for processes; simultaneous appearance for fair comparison; continuous zoom/movement for overview-to-detail; emphasis for highlighting key points. Adjust parameters based on new material sizes, positions, and reading time; avoid applying the same fly-in to all objects.
• Morph, motion paths, triggers, and grouped objects may depend on adjacent pages or other shapes. Preserve required relationships, rebind after migration, and verify playback. Static screenshots and transitions are not equivalent to intra-slide object animations.
• For advanced animation requests, working files should record the "source file/continuous pages, mechanism, target scene, preserve/migrate/rebuild strategy, objects and triggers, actual implementation, and playback evidence." Differentiate between complex in-page arrangement and full cross-page Morph scenes: both can constitute advanced animation; a single page transition or effect_count > 0 is not proof of meeting requirements.

4. Decompose Templates, Then Recompose Around the Theme

• When a full page is suitable, adapt it; when new composition is needed, extract local elements directly without waiting until all templates have failed before creating original content. Reusable objects include shapes, icons, picture frames, groups, flow components, editable charts, color schemes, font hierarchies, and animation structures.
• Use decompose_template.py inspect to view all shapes, group-internal objects, theme-associated fonts/colors, and object direct styles; use extract to export editable component PPTX, referenced images, source page/component previews, and design/animation reports by top-level shape ID. See production-tools.md for commands and limitations.
• Original images, SVGs, etc., can be used independently; shapes, groups, and charts are saved in the component PPTX for further editing. Do not treat a full-page screenshot as a "decomposed template" or raw XML as a directly cross-file reusable component.
• Preserve component source, page number, shape ID, purpose, and animation dependencies. Sample data, text, branding, and viewpoints in template examples are placeholder content and cannot become facts in new slides.
• Rearrange hierarchy, size, position, color scheme, and whitespace around the new theme; unify the visual system when reusing across templates. After modifying components, check connectors, labels, cropping, and motion paths. Verify editability and animation in the target slides, not just in the component file.
• When a component depends on a master, font, interactive trigger, or preceding page, record and handle the dependency. Rebuild parts that cannot be reliably preserved with native objects; describe the actual implementation, not claiming full preservation.

5. Supplement with Other Methods Based on Actual Gaps

• User templates and helper scripts are not the limit of capability. First identify whether the gap is facts, images, structural diagrams, visual references, or animation implementation, then choose an appropriate method; avoid aimless collection.
• Public design cases, official technical references, and usable materials may be retrieved; native shapes/charts, SVGs, programmatic drawing, available image generation tools, or other suitable methods may also be used. When redrawing structural diagrams based on real content, preserve the original meaning; distinguish generated conceptual diagrams from real evidence.
• If the user has configured additional Skills or archive directories, follow their rules to read related instructions as needed; this package has no fixed personal directory or operational dependency on other Skills and does not automatically install or batch-activate unrelated Skills.
• For external facts, use reliable sources appropriate to the topic and verify them; for technical implementations, prioritize official documentation. Preserve the source, usage conditions, and purpose of external materials. Supplementary content must not crowd out the user's required materials, and private materials must not be uploaded to external services without authorization.
• For a new method, first verify editability, display, and playback performance on one representative sample page, then expand to the full presentation. If a tool only supports static output or is incompatible with certain effects, state this accurately and adopt a verifiable implementation.

Production and Review

1. Content: Cross-check the material ledger against the final file, confirming that every required item actually appears and key parts have not been cropped; verify data, citations, theme, and speech narrative. Do not claim "all applied" if there are unresolved omissions.
2. Design and Narrative: Use the reference's three lines of review—visual, narrative/understanding, and text/facts—independently, recording the page and object of each issue, severity, fix, and review result. Check each page at full size for fonts, line breaks, clarity, cropping, overlaps, and whitespace; use thumbnails to check overall rhythm. Verify Chinese missing characters, punctuation, numeric units, charts, and in-group text separately. For crowded pages, split by conceptual balance; do not shrink fonts or fabricate content to fill the layout.
3. Motion: Play or check available playback records to verify initial state, each click, synchronization of images and labels, pause time, transitions, and Morph continuity. For advanced requests, also trace back whether each core mechanism in the plan actually appears in the final product and serves the content; do not let only the cover animate while content pages fully revert to basic effects. Static previews, XML counts, and script success do not prove playback quality; report unfinished motion checks honestly.
4. File: Reopen the final PPTX natively in PowerPoint to confirm editable text, materials, speaker notes, and native animations. Even when the builder reports native_validated: false, native opening and review are still required. Fix blocking issues such as omitted materials, fact/data errors, unreadable or truncated key content, corrupted files, and loss of necessary animations; do not offset with average scores.
5. Delivery: Provide the final PPTX with a brief description of material coverage, design and animation choices, and the actual verification scope. Keep directory indices, ledgers, decomposed components, scripts, and intermediate previews in the working directory unless the user requests additional deliverables.