sjtu-ppt-creator

Imported from yuanmute/sjtu-ppt-creator (SKILL.md). Install upstream with npx skills add yuanmute/sjtu-ppt-creator. Copyright stays with the author.

SJTU PPT Creator

Overview

Create polished, editable .pptx decks from SJTU-style template files. Treat each template as a page library: choose one template, select pages inside it, reorder them into a complete deck, and fill or overlay editable content.

The deliverable is a readable, editable PowerPoint file. Do not switch the core output to HTML, PDF, or screenshots.

Workflow

1. Confirm the request has enough information: topic/materials, purpose, audience, page count, and template preference if any. Ask only for missing essentials.
2. If the user provides local materials, use them first. Inventory images, screenshots, videos, and any defense script. Map usable visuals to slides before outlining, and map a supplied defense script into claims, evidence, and transitions. Do not silently omit a suitable supplied asset or replace it with a generated substitute. If important facts or visuals are missing and browsing is allowed, research authoritative sources.
3. Read references/templates.md before choosing pages.
4. If the user specifies a template number or filename, lock that template. Use only pages from that template.
5. If the user does not specify a template, choose exactly one best-fit template from references/templates.md.
6. Read references/ppt-workflow.md and references/guizang-distilled.md for general deck rules.
7. When the user says the result should look like PathGPT, or the task is a project/competition/engineering defense, also read references/pathgpt-style.md.
8. Read references/visual-generation.md, route each needed visual to editable PPT objects, supplied/researched evidence, or $imagegen, and save any generated project assets in the current workspace. Apply the low-saturation palette rules in references/ppt-workflow.md to every new or recolored element.
9. Build a slide outline, map each slide to a source page from the locked template, and apply the grid, alignment, 18 pt minimum, parallel-copy, text-density, and visual-conversion rules in references/ppt-workflow.md. Put normal visuals in images; use background_image only for a deliberate full-slide backdrop. Keep append_template_samples enabled unless the user explicitly opts out.
10. If the user supplies video, preserve the original, select the useful segment, convert it with scripts/video_to_gif.py, inspect the GIF, and place the GIF path in images. Never pass a raw video path to the deck builder.
11. Run scripts/build_deck.py to assemble the .pptx.
12. Reopen or render the generated file and check page count, roles, font sizes, alignment, clipping, isolated one-character lines, overlap, visual hierarchy, background contrast, and single-template compliance.

Layout and Defense Quality

• Prefer a simple grid with aligned edges, equal gaps, consistent box padding, and one dominant reading path. A plain but orderly page is better than a decorative but chaotic one.
• Keep presentation content at 18 pt or larger. Shorten, split, or remap content instead of shrinking text; rewrite lines that would leave one Chinese character or one short word alone.
• Make parallel blocks grammatically parallel and similar in information depth. If the relationship is progressive, show the order with numbers, arrows, or a left-to-right/top-to-bottom sequence.
• Translate abstract prose into the most direct editable visual: process to flow, comparison to columns/table, sequence to timeline, hierarchy to architecture, and results to chart plus a key metric.
• For a defense deck with a supplied script, preserve the script's argument order or document the remapping. Each slide should expose enough claim, evidence, and transition logic that a clear speaking-outline draft can be reconstructed from the deck.
• Avoid large accidental blank regions. Use a relevant dominant figure, structured diagram, or quiet full-slide background_image when it improves composition; never add decorative clutter merely to fill space.

Template Lock Rule

Every output deck must use exactly one source template.

• User specified a template: use only that template.
• User did not specify a template: select one template, then use only that template.
• Do not mix pages across templates, even if another template has a better cover, content page, or closing page.
• If the locked template cannot support the requested deck shape, ask to reduce scope or allow a different single template.

Default Template Sample Appendix

Append editable blank sample pages from the locked template after the finished presentation by default. Treat the user's requested page count as the main presentation count; report the appended sample count and final total separately.

• Default: omit append_template_samples or set it to true.
• Opt out only when the user explicitly requests no sample appendix: set append_template_samples to false.
• By default, append every indexed reusable content page. Do not append cover, agenda, section, or closing pages because those mandatory roles already appear in the finished presentation. Never append pages marked Avoid.
• Preserve template decorations, geometry, editable shapes, and SJTU identity. Clear editable example text and table-cell content in the appended copies so users can continue editing them.
• Use template_sample_roles or template_sample_slides only when the user asks for a narrower appendix.

PathGPT-Like Quality Target

For project-defense decks like the provided PathGPT examples, do not produce a plain bullet deck. Aim for:

• 20-25 pages for a full defense unless the user requests another length.
• Chaptered narrative: background, research content, technical route, results/showcase, outlook, closing.
• Numbered section titles such as 1.2 现存痛点 and 3.1 仿真实验示例.
• Visual evidence on most non-transition pages: screenshots, plots, diagrams, tables, cards, or process flows.
• Scannable labels such as 核心创新, 实现, 关键成果, 项目介绍, 技术路线.
• Editable overlays drawn by the script when the template page has no matching prebuilt graphic.

Use cards in the deck spec for pain points, feature groups, innovations, and future directions. Use flow for architecture, technical route, toolchain, and closed-loop planning pages.

Visual Skill Handoff

Keep exact, editable structures native to PowerPoint: use tables for precise rows and values, charts for quantitative data, and flow or cards for process, causal, decision, or audience-facing reasoning maps.

Use restrained, low-saturation colors throughout the deck. This applies to backgrounds, accents, cards, charts, tables, icons, diagrams, and generated images. Do not turn vivid template swatches into a repeated palette; preserve an official logo or immutable brand mark when its exact color is required, then use muted neighboring colors everywhere else.

Treat relevant user-provided images as required first-party assets. Insert them into the finished .pptx, not merely into working notes. Prefer supplied images over researched or generated substitutes; preserve originals and use project-local working copies when cropping, renaming, or path compatibility requires it. If a supplied image is irrelevant, unreadable, duplicative, or cannot fit within a hard page limit, state the omission and reason instead of dropping it silently.

Invoke $imagegen only when a raster visual materially improves the slide and no suitable user-provided or authoritative visual exists. Good targets include conceptual illustrations, neutral product or scenario images, atmospheric section visuals, and non-specialist explanatory imagery. Do not use generated imagery as factual evidence or for professional scientific, medical, legal, safety-critical, or engineering schematics.

Treat any request for a “chain-of-thought diagram” as a request for a concise audience-facing reasoning map. Never request, reveal, or encode private model chain-of-thought. See references/visual-generation.md for routing, prompt, storage, and insertion rules.

Deck Spec

Pass a JSON file to scripts/build_deck.py. Use 1-based source_slide numbers from the locked template.

{
  "title": "PathGPT 项目答辩",
  "template": "4.深海金芒-许歆瑶.pptx",
  "append_template_samples": true,
  "slides": [
    {
      "source_slide": 1,
      "kind": "cover",
      "title": "PathGPT：大模型驱动 USV 集群路径自适应规划系统",
      "subtitle": "答辩团队：Smart 智脑 | 上海交通大学",
      "date": "2025.08.09"
    },
    {
      "source_slide": 20,
      "kind": "content",
      "title": "1.2 现存痛点",
      "subtitle": "无人艇集群决策系统面临适应性不足、协同鲁棒性弱及自主性受限等问题",
      "cards": [
        {"title": "适应性不足", "body": "静态环境假设难以处理突发变化和未知障碍"},
        {"title": "协同鲁棒性弱", "body": "集中式控制通信成本高，分布式控制缺乏全局视野"},
        {"title": "自主性受限", "body": "固定规则库缺乏学习能力，难以理解任务语义"}
      ]
    },
    {
      "source_slide": 20,
      "kind": "content",
      "title": "2.1 智能体架构",
      "subtitle": "以大模型为推理中枢，连接感知、工具调用、路径评估和策略输出",
      "flow": [
        {"title": "环境感知", "body": "障碍物/海况"},
        {"title": "语义解析", "body": "提示词编码"},
        {"title": "工具调用", "body": "RRT*/APF/DWA"},
        {"title": "路径评估", "body": "安全/能耗"},
        {"title": "策略输出", "body": "航线方案"}
      ]
    }
  ]
}

Use background_image on a slide spec only for one deliberate full-slide backdrop. Use images for ordinary pictures and converted GIFs; raw video extensions are rejected.

Run:

python scripts/build_deck.py --spec deck.json --template-dir "C:\Users\吕昊天\Desktop\ppt_model" --output "output\deck.pptx"

The script copies the locked template, keeps selected source pages, reorders them, fills existing slots, adds editable cards/flows/charts/tables/images when requested, clears unused placeholder text, appends blank editable template samples by default, and saves a new .pptx.

Page Selection Guidance

• Use a cover first and a closing page last when available.
• For 8 pages or fewer, omit the agenda if the topic is simple.
• For 10-15 pages, include cover, agenda, 2-3 sections, content pages, summary, and closing.
• For 20-25 page project defenses, use transition pages to separate major chapters.
• Avoid font/color/icon specification pages unless the user asks for template documentation.
• Prefer varied content pages inside the same locked template instead of repeating one source page.
• Match the source page's native layout before adding new visuals. If a page is a two-, three-, or four-column layout, fill those columns left-to-right/top-to-bottom; do not cover them with one large picture or a newly drawn oversized card group.
• Match card count and detail depth to the native columns. For template 04, source slide 12 expects three detailed cards (two detail rows each) or six concise cards, while source slide 15 expects four cards. If the count does not match, choose another page instead of forcing the content into the layout.
• Use a blank or image-first content page for a large inserted image, screenshot, architecture diagram, or custom visual. For template 04, use source slide 21 for full-slide/large images instead of multi-column pages such as 12 or 15.
• Do not leave large empty areas on normal content pages. Each content slide should have enough text, cards, flow nodes, table rows, chart data, or image evidence to visibly occupy the selected layout.
• Keep boxes, text, pictures, and connectors on a shared grid. Align top/bottom edges for parallel groups, keep equal widths and gaps, and keep text inside boxes with consistent padding.
• Use at least 18 pt for visible presentation content. If 18 pt does not fit, reduce wording, simplify the visual, split the slide, or choose a roomier source page.
• Treat the supplied diagram examples as guidance for clear zoning and directional flow, not as permission to reproduce their dense small type.

Resources

• references/templates.md: SJTU template inventory and page-role index.
• references/ppt-workflow.md: deck outline, page-composition, visual, and acceptance rules.
• references/pathgpt-style.md: finished-deck quality reference distilled from the provided PathGPT examples.
• references/guizang-distilled.md: compatible design, rhythm, image, and self-check rules from guizang-ppt-skill.
• references/visual-generation.md: decision rules for native visuals, evidence images, and $imagegen handoff.
• scripts/build_deck.py: deterministic assembler for locked-template editable .pptx decks.
• scripts/video_to_gif.py: FFmpeg-based converter for turning supplied video clips into animated GIF assets before insertion.