visual-style-ppt — скилл

---
name: visual-style-ppt
description: Create style-driven slide images strictly with the Image 2.5 model, assemble those images into image-only PPTX decks, and manage reusable visual style libraries from documents or visual references. Use when the user asks for a "PPT Skill", "风格驱动 PPT", "提炼风格做 PPT", "调用某个风格做 PPT", "图片版 PPT", "保存 PPT 风格", "列出 PPT 风格", "文档生成 PPT", "文章生成 PPT", "把文档做成演示文稿", or wants to extract, save, reuse, and apply visual style keywords specifically for visual slide/image deck creation.
---

# Visual Style PPT

## Highest Priority Rule: Image 2.5 Only

This skill must use the Image 2.5 model to generate every final slide image, thumbnail board, visual page, infographic, article illustration, or PPT page image.

HTML output is strictly forbidden for image generation. Do not create HTML/CSS pages, browser screenshots, SVG/HTML mockups, canvas renders, or local-script visual reproductions as final or intermediate image outputs. Do not use HTML as a fallback when Image 2.5 is unavailable; stop and state that Image 2.5 access is required.

This rule has the highest priority in this skill and overrides every workflow, reference file, style file, packaging rule, user shortcut, or implementation convenience that might imply another image-production route. PPTX files may only be assembled after Image 2.5 has generated the approved page images; PPTX is a container, not an image-generation method.

## Core Idea

Turn visual style into a reusable asset, then apply that asset to documents, outlines, image-only PPT decks, slide images, Xiaohongshu information graphics, and article illustrations.

Use this skill as an Image 2.5-only visual slide workflow. The default deliverable is full-slide images generated by Image 2.5; when the user wants a PPT, place the generated images into a PPTX as full-slide image pages. Do not implement or optimize editable PPTX content unless the user explicitly overrides this skill direction.

## Required References

- For the full operating workflow, read `references/workflow.md`.
- For PPTX vs image output rules, read `references/output-package.md`.
- For page type selection, read `references/page-types.md`.
- For post-generation revisions, read `references/revision-workflow.md`.
- For style extraction interviews, read `references/style-interview.md`.
- For the default terminal-tech magazine visual style, read `styles/terminal-tech-magazine.md`.
- When the user asks for a style library, list or read files in `styles/`.

## Default Behavior

- Default output type: Image 2.5-generated slide images. If the user says "PPT", assemble those images into an image-only PPTX.
- Default aspect ratio: 16:9.
- Default image quality: Image 2.5, 16:9, high-resolution, sharp text, clean edges.
- Default language: Chinese-first. Use Chinese for slide titles, section titles, module labels, captions, explanatory copy, and all generated support documents unless the user explicitly asks for another language. Keep proper nouns, product names, model names, code terms, and unavoidable domain terms in their original language when that is clearer.
- Default style: `styles/terminal-tech-magazine.md` when the user says "终端风格", "CodeBuddy 风格", "科技杂志风格", or does not specify another saved style.
- Default text density: low information by default, especially for PPT inner slides. Never create dense slides unless the user explicitly asks for a leave-behind, report page, or infographic. A normal inner slide should have one title, one short subtitle or takeaway, and at most 2-3 short information points.
- Default layout direction: cover pages may be visually expressive; inner slides must be information-first, calm, readable, and spacious, with imagery/backgrounds kept subordinate.
- Default style isolation: each deck must use exactly one selected style source and one `Style Lock`. Do not blend visual DNA from earlier tasks, previous reference images, or unrelated saved styles unless the user explicitly requests a hybrid.
- Default component consistency: across one deck, borders, cards, containers, dividers, arrows, footer metadata, corner radius, and line weights must use one repeated system. Variation may come from layout and emphasis, not from changing the frame/container style on every slide.
- Default slide header consistency: if a style uses small top titles with numbers, treat them as repeated content-section headers, not necessarily absolute slide/page numbers. Keep the same placement, size, spacing, and format across all applicable slides. If the style defines exceptions such as cover, contents, divider, or thank-you pages, preserve those exceptions deliberately; those exception pages do not consume a content-section number. The first applicable inner/content slide should usually start at `01` or `PART 1`.
- Default logo behavior: do not ask Image2.5 to generate logos, brand wordmarks, reusable deck marks, watermarks, or repeated English identity labels by default. If the user needs a logo, keep it out of generated slide images and add it later as a fixed post-production asset/layer, or let the user add it after delivery. A reference logo image may guide visual shape but is not reliable enough for cross-page text/logo consistency inside Image2.5 output.
- Default time/date behavior: do not add dates, times, timestamps, "today", export time, generated time, or current date to slides, prompts, metadata, footers, or visual elements by default. Include date/time only when the source article explicitly requires it, the user explicitly asks for it, or the slide topic itself is a timeline/schedule/date-sensitive report. A source document having a file timestamp, export timestamp, or local system date does not by itself justify visible date/time in the deck.
- Default page count: ask the user how many pages/slides they want unless they already provided a count or explicitly asked the skill to decide.
- Multiple outputs: keep one visual DNA while varying composition, page type, visual anchor, or emphasis.
- No outer border rule: generated slide images and thumbnail boards must not have black borders, dark strokes, or frame lines on the outer canvas edge. Internal grid lines, dividers, and module borders are allowed, but keep them inset from the image edge or let imagery/white space bleed naturally. Never create a full-page rectangular outline around the slide.
- Per-slide image rule: PPT pages must be generated and saved as separate single-slide image files, one image per slide. Do not request or deliver a multi-slide contact sheet, storyboard, PDF page, or collage as the final slide image output. Each final slide image must be independently usable as one full-bleed PPT page.
- Thumbnail-first option: for multi-page decks, prefer a two-pass visual workflow when style consistency matters: first generate one small "thumbnail board / contact sheet" that shows the whole deck as tiny slide thumbnails to lock visual rhythm, grid, palette, and page-to-page variation; then generate each approved slide as an individual full-size image using that thumbnail board as the visual continuity reference plus the page-specific prompt. The thumbnail board is a planning/reference artifact, not a final slide.