<div align="center"> <p align="center"><img src="examples/site/assets/brand/logo-pure-mark.svg" alt="PPT Design Skill Logo" width="76"></p> <h1 align="center">PPT Design Skill</h1> <p align="center"><strong>原生可编辑 · 视觉设计驱动</strong></p>

一个以设计流程为核心的 PowerPoint skill。PPTX 的实际生成由已发布的 pptx-designer Python 标准库负责；skill 负责需求确认、结构设计、视觉方案、生成编排和最终视觉验收。

English README · 中文使用手册 · 真实案例 · 安装说明

</div>

先选对生成模式

交付级任务，默认选择 Build Mode

如果你的 PPT 要交给客户、管理层、投资人或正式会议使用，优先使用 Build Mode。它允许 LLM 逐页规划结构、锁定视觉方向、精确控制布局，并在 PPTX → PDF → PNG 后进行视觉复核和返工，是三种模式中视觉控制力和交付确定性最高的路径。

模式	最适合	布局控制	速度	推荐度
Build Mode ⭐	客户交付、提案、战略、路演、 editorial、正式汇报	最高：逐页、逐元素控制	中等	首选
FreeStyle Mode	快速探索、方向草稿、内容已经明确的轻量 PPT	中等：由 `generate_ppt()` 自动编排	最快	探索优先
VI Build Mode	已有企业模板、母版或品牌规范的 PPT	受模板约束：提取并保持品牌 DNA	中等	模板优先

如何判断

你关心“最终看起来是否专业”，而不是只要一个草稿：Build Mode；
你想快速验证主题、内容或风格方向：FreeStyle Mode；
你必须沿用企业模板、Logo、字体和版式：VI Build Mode。

FreeStyle 的 generate_ppt(query=...) 和 generate_ppt(content=...) 是同一个模式的两种输入方式，不是两条独立的生成引擎。无论选择哪种模式，正式交付都必须经过 PNG 视觉检查。

<div align="center"> <strong>推荐决策：</strong> 不确定时使用 Build Mode；只有在明确追求速度或必须服从现有模板时，才选择 FreeStyle 或 VI Build Mode。 </div>

Skill 的核心价值

pptx-designer 负责把设计决策生成成可编辑 PPTX；本 Skill 负责保证设计决策和交付过程的质量：

需求确认
  → 领域判断与页面结构
  → 视觉方向建议与用户确认
  → 设计 token / 页面锚点锁定
  → pptx-designer 生成可编辑 PPTX
  → PPTX → PDF → PNG
  → 第一门：整体视觉效果与客户级完成度
  → 第二门：严重缺陷、需求和可编辑性检查
  → 源码/内容返工并重新渲染
  → 用户确认与交付

技术上“运行成功”不等于设计完成。Skill 会直接检查导出的 PNG，判断页面是否有视觉重心、合理密度、清晰层级、完整构图和符合用户需求的设计效果。

核心理念

这不是“一句话生成 PPT”的包装层，而是一套设计交付流程：

用户需求确认
  → PPT 结构设计
  → 视觉方案设计
  → 用户确认方向
  → pptx-designer 生成 PPTX
  → PPTX → PDF → PNG
  → LLM 逐页视觉检查
  → 代码/内容修订
  → 再次渲染检查
  → 用户确认最终效果
  → 交付

PPTX 文件成功生成、Python 没有报错、shape 数量正常，都不能代替 PNG 视觉检查。

生成前，LLM 会把用户需求整理成可追踪的视觉验收合同；生成 PNG 后，逐项对照需求和页面证据，记录 PASS、NEEDS_REVISION 或 BLOCKED。因此 PNG 检查不是泛泛地判断“好不好看”，而是验证结果是否真正满足用户目标。

精选设计案例

这里展示的是可以下载、打开并继续编辑的完整 PowerPoint 案例。它们覆盖技术系统、基础设施研究、科学证据、文化建筑和城市策略，用来说明本技能如何把内容结构、视觉方向和原生可编辑对象结合成完整的演示设计。

案例	设计定位	视觉语言与设计重点
AI Agent Operating System	技术系统蓝图	深色网格、分层架构、荧光色标记、流程与治理
AI Infrastructure Economics	编辑型产业研究	纸张质感、物理约束隐喻、数据层级、战略叙事
Single-Cell CAR T Atlas	论文型科学叙事	图证结构、研究设计、证据边界与可编辑机制图
Louvre Abu Dhabi	建筑文化叙事	真实摄影、可编辑几何、气候逻辑与博物馆城市空间
Vertical City Retrofit	城市更新策略	建筑剖面、系统图、情景数据、治理与决策框架
COUTURE COLOR — Objects of Desire	高定美妆编辑叙事	全屏妆效肖像、同一模特的上妆动作、可编辑产品结构与材质叙事

这些案例不是为了证明代码能够运行，而是为了展示从设计判断到最终页面完成度的完整结果。更多页面和下载入口请查看在线案例画廊和 examples/README.md。

点击任意预览即可进入在线查看器，浏览完整页面并下载 PPTX、PDF：

Install

Clone the repository first, then run the installer from the repository root. The installer automatically installs the published pptx-designer Python package and copies the skill bundle to the selected coding assistant:

# Clone the skill repository
git clone https://github.com/sunchaokun/PPT-Design-Skill.git
cd PPT-Design-Skill

python installer/install.py --platform opencode --force
python skill/scripts/check_runtime.py

请使用 installer/install.py 完成 Skill 安装。仓库根目录的 install.py 仅用于安装 Python 运行包 pptx-designer，不会把 Skill 注册到编码工具中。

Replace opencode with claude, codex, deepseek-harness, or all as needed. Restart the coding assistant after installation.

LibreOffice 为什么是可选依赖？

PPTX 的生成本身只依赖 Python 包 pptx-designer，不要求安装 LibreOffice。但按照 Skill 的质量流程，生成 PPTX 后还需要将它渲染为 PDF 和 PNG，检查文字溢出、图片裁切、构图和页间节奏：

有 Microsoft PowerPoint 时，Windows 优先使用 PowerPoint COM 渲染；
没有 PowerPoint 时，使用 LibreOffice 的 soffice 将 PPTX 转为 PDF；
再使用 Poppler 的 pdftoppm 将 PDF 转为 PNG。

因此，LibreOffice 是无 PowerPoint 环境下的渲染后备方案，不是 PPTX 生成器，也不是所有用户都必须安装的依赖。运行下面的命令可以检查当前环境：

python skill/scripts/check_runtime.py

安装器会检查 PATH、Windows 默认安装目录和注册表中的 LibreOffice，不会因为 soffice.exe 没有加入 PATH 就误报未安装。桌面软件不会被静默安装；如果需要使用 winget 显式安装 LibreOffice 和 Poppler，可以执行：

On Windows, users who explicitly want the installer to use winget may run:

python installer/install.py --platform opencode --force --render-deps

检查真实案例

python skill/scripts/inspect_pptx.py examples/new_examplex/louvre_abudhabi/output/louvre_abudhabi_complete.pptx --pretty
powershell -ExecutionPolicy Bypass -File skill/scripts/render_pptx.ps1 `
  -InFile examples/new_examplex/louvre_abudhabi/output/louvre_abudhabi_complete.pptx `
  -OutDir output/louvre-abudhabi-rendered

对其他维护案例重复执行。导出后，LLM 必须直接查看 PNG，检查构图、层级、文字可读性、图片裁切、页间节奏、用户需求匹配度和可编辑性。发现问题必须修改源代码或内容并重新渲染。

文档入口

解决什么问题

仅检查代码、文件和基础结构，不能保证 PPT 达到设计要求。即使“运行成功”，仍可能存在标题层级弱、页面拥挤、图片裁切错误、图表不可读、页面重复和风格不统一等问题。

本 skill 将视觉结果作为交付对象的一部分：

用户先确认需求和受众；
LLM 先设计页面结构和视觉方向；
pptx-designer 生成可编辑 PPTX；
通过确认过的 PPTX -> PDF -> PNG 路径导出页面；
LLM 直接查看 PNG，逐页判断是否达到设计要求；
发现问题后回到 Python 源码或内容进行修订；
重新导出并检查，最终交给用户确认。

设计能力

本 skill 采用成熟的 Designer Mindset，而不是把设计退化成选择一个 style 参数：

能力	作用
Audience-first	根据受众、场景和行动目标决定页面表达方式
Narrative planning	先设计页面级叙事，再生成代码
Domain paradigms	科研、论文、技术、医疗、政府和商业使用不同范式
Design system	锁定颜色、字体、间距、网格、图片和组件语言
Density control	控制页面信息量，避免用小字号塞满页面
Structural variation	页面结构随沟通目标变化，而不是重复同一种卡片
Native editability	文本、形状、图表和支持的 SVG 保持可编辑
PNG visual review	直接检查真实导出图像，而不是只检查源码

模式详细说明

模式	适用场景	核心实现
Build Mode	交付级空白画布精确设计	Python + `pptx_designer.tools.*`
FreeStyle Mode	快速探索或目标驱动生成	`generate_ppt(query=...)` / `generate_ppt(content=...)`
VI Build Mode	企业模板和品牌合规	`extract_design_context()` + 原子 Build + `VIBuildDelivery`

FreeStyle

FreeStyle 使用 pptx-designer.generate_ppt() 完成库内的目标驱动生成：

from pptx_designer import generate_ppt
from pptx_designer.renderer.theme import ThemeComposer

theme = ThemeComposer().compose(style="dark-tech", seed=17)
result = generate_ppt(
    "AI startup investor pitch",
    theme=theme,
    output="output/pitch.pptx",
)

当页面目标和文案已经明确时，使用结构化 content：

result = generate_ppt(
    content={
        "title": "Q4 Revenue Review",
        "pages": [
            {"goal": "hook", "title": "Q4 2026", "subtitle": "Record quarter"},
            {"goal": "problem", "title": "The pressure is visible", "bullets": [
                "Enterprise demand is growing",
                "Delivery capacity is the constraint",
            ]},
            {"goal": "data", "title": "Key metrics", "bullets": [
                "Revenue: $12.8M",
                "Retention: 89%",
            ]},
        ],
    },
    theme=theme,
    output="output/review.pptx",
)

query 和 content 都属于 FreeStyle，不是两个不同的渲染引擎。content 只是让 LLM 更明确地控制页面目标和文案；需要精确坐标时应使用 Build Mode。 theme 必须是 ThemeComposer.compose() 返回的完整 resolved theme；传入后不要再同时传入 style、palette、fonts、decoration、layout、mood 或 style_seed。

VI Build Mode

当用户提供 template.pptx、企业母版或明确要求品牌合规时使用 VI Build：

使用 extract_design_context() 提取确定性的视觉证据；
人工确认框架页、可写文本槽位、固定视觉层和视觉 grammar；
用 content_model、原子组件、精确几何和 relation_bindings 设计内容页；
用 VITemplateAdapter.compile_atomic() 编译内容页，并用 VIBuildDelivery 交付；
通过 PPTX -> PDF -> PNG 检查原有页面和新增页面的一致性。

将品牌、主题或页面上下文叠加到模板证据时，使用 merge_vi_design_context()，不要使用通用的 merge_design_context()。

VI Build 不能承诺对所有 PowerPoint master、SmartArt、动画和 OOXML 行为进行像素级复刻，详细边界见 template-brand.md。

Build Mode

Build Mode 是交付级路径。LLM 生成普通 Python 文件，布局、文案、颜色和数据都可以在 Git 中审查、修改和重复构建：

from pptx_designer import Presentation
from pptx_designer.renderer.theme import ThemeComposer
from pptx_designer.tools.cards import kpi_card
from pptx_designer.tools.layout import page_header
from pptx_designer.tools.shapes import rect

theme = ThemeComposer().compose(style="professional", seed=17)
prs = Presentation(theme=theme, strict_theme=True)
slide = prs.slides.add_slide(prs.slide_layouts[6])
page_header(slide, "Q4 Revenue Report", "Financial Summary")
kpi_card(slide, 1.0, 2.0, 3.5, 1.5, "$12.8M", "Revenue", "+23%")
rect(slide, 0.5, 6.8, 12.3, 0.08, fill="primary")
prs.save("output/report.pptx")

Build Mode 规则：

所有坐标使用英寸；
使用 pptx_designer 公共 API；
优先使用原生文本、形状、图表和图示；
使用 cover_image() 保持图片比例；
颜色集中在设计 token 或 C 字典中；
不使用旧版 ppt_pro_max 或私有模块；
生成后必须运行、重开、导出和视觉检查。

设计过程中的三个控制量

控制量	低值	中值	高值
Variance	统一网格和组件	两到三种页面策略	章节页和多种结构
Motion	静态或淡入	章节转换和重点强调	仅在演讲场景适合时使用更强动效
Density	大留白、少元素	叙事和数据混合	仪表盘、表格和高密度信息

这些控制量影响页面结构和信息节奏，不是简单的颜色开关。科研、学术和医疗场景通常需要降低装饰和动效，即使主题本身是科技方向。

重要禁止行为

没有需求和页面结构就直接生成完整交付 PPT；
只换颜色、字体就把多个方案称为结构不同；
每页重复同一种卡片或项目符号布局；
用小字号容纳未经编辑的过量内容；
编造精确指标、客户案例、引用或证据；
拉伸图片或使用与内容无关的图片；
把整页内容烘焙为截图，替代可编辑对象；
将商业融资模板套用到科研、论文、医疗内容；
只确认 Python 和 PPTX 文件成功，不查看 PNG；
PNG 发现问题后不重新生成、不重新检查。

运行和渲染

如需重新安装或升级 Python 运行时，可以直接运行安装器；它会自动处理 pptx-designer：

python installer/install.py --platform all --force
python skill/scripts/check_runtime.py

安装 skill 到编码工具：

python installer/install.py --platform claude --force
python installer/install.py --platform codex --force
python installer/install.py --platform opencode --force
python installer/install.py --platform deepseek-harness --force

导出 PPTX、PDF 和 PNG：

powershell -ExecutionPolicy Bypass -File skill/scripts/render_pptx.ps1 `
  -InFile examples/new_examplex/louvre_abudhabi/output/louvre_abudhabi_complete.pptx `
  -OutDir output/louvre-abudhabi-rendered

渲染器优先使用 Microsoft PowerPoint COM；无 PowerPoint 时使用 LibreOffice 生成 PDF，再使用 Poppler 的 pdftoppm 生成 PNG。桌面渲染器属于系统依赖，可以显式执行：

python installer/install.py --render-deps

交付清单

正式交付通常包含：

.pptx 文件；
可重复构建的 Python 源码或结构化 content；
.pdf 预览文件；
每页 PNG 或联系表；
基础结构检查结果；
PNG 视觉检查结果；
用户最终确认记录。

目录结构

PPT-Design-Skill/
├── skill/
│   ├── SKILL.md
│   ├── agents/openai.yaml
│   ├── references/
│   └── scripts/
├── docs/assets/cases/
│   ├── contact-sheet.png
│   └── representative slide previews
├── examples/new_examplex/
│   └── six maintained case-study packages
├── installer/
├── docs/
├── install.py
└── skill.json

ppt-design-skill

name: ppt-design-skill description: Design, generate, review, and revise editable PowerPoint presentations through a rigorous brief-to-PNG workflow using the public pptx-designer Python library. metadata: short-description: Design and visually review editable PowerPoint decks category: design tags: [ppt, powerpoint, presentation, deck, slides, design, python, editable]

PPT Design Skill

Name: PPT Design Skill
Author: sunchaokun

This skill is a presentation design director and delivery workflow. The pptx-designer Python package is the rendering engine; this skill decides what should be designed, how it should be structured, how it should look, and whether the rendered result actually satisfies the user's need.

The design framework below keeps the mature design judgment, content rules, domain paradigms, and quality standards that make the workflow reliable. The implementation engine is the public pptx-designer Python library.

Designer mindset

Act as a senior presentation designer. Make decisions from the audience and the communication goal, not from the list of available Python functions.

Audience first: decide what the audience must understand, remember, feel, or do before choosing a layout.
Restraint over decoration: one clear accent system is better than random effects; every element must earn its place.
Systematic thinking: a deck is one visual system, not independent pages. Lock margins, spacing rhythm, typography, color roles, corner treatment, image treatment, and component language.
Intentional variation: vary page architecture and density when the story changes, not merely to make pages look different.
Explain decisions: be able to state why a page uses a figure, chart, comparison, diagram, image, or sparse statement for this audience.

Stop before writing code

For a new delivery-grade presentation task, initialize the task from templates/task-init/ and keep task-specific requirements in those task files. Run init_presentation_task.py from the loaded Skill's scripts/ directory (use its absolute path if the working directory is the project): python <skill-root>/scripts/init_presentation_task.py --project <project-root> --name <lowercase-task-slug>. It creates an isolated <project-root>/ppt_tasks/<task-slug>/ and refuses to overwrite it. Do not begin implementation while a required research or direction decision remains unresolved.

For a delivery-grade deck, do not write the build script until these decisions are explicit:

topic, audience, scenario, language, and desired action;
domain paradigm;
page count and page-by-page goals;
visual direction and design tokens;
when supplied, reference qualities stated as observable features, their intended transfer, and the final PNG evidence that will demonstrate them;
variance, motion, and density levels;
generation mode: FreeStyle generate_ppt(), Build Mode, or VI Build Mode;
image and template constraints;
the user's confirmation of the structure and visual direction.

The only acceptable shortcut is an explicitly requested quick exploratory draft.

Non-negotiable outcome

A PPTX file that merely runs successfully is not complete. A task is complete only after the deck has been rendered through the confirmed PPTX -> PDF -> PNG path, the LLM has inspected the PNG output, material visual issues have been revised, and the user has confirmed the final direction or result.

Workflow

Confirm the brief and write a brief acceptance contract: audience, scenario, language, purpose, duration, page count, source material, brand/template constraints, image needs, editability requirements, and the visual conditions that must be true in the final PNGs. Classify each condition as MUST, SHOULD, or NICE_TO_HAVE.
Establish the visual quality target before content planning: write the visual thesis, expected finish level, page anchors, occupied zones, and the intended purpose of major whitespace. When reference material is supplied, convert its observable qualities into transfer decisions and PNG evidence; do not reduce it to vague style labels or mechanically copy its content. Run a thumbnail preflight; a page without a focal point or a complete visual composition is not ready for content or code.
Detect the domain and set the design read: page goal, core takeaway, content type, and relationship to surrounding pages. The domain must refine the visual target, not reduce it to a generic template.
Coach the user through the visual direction: infer the design read, present two or three genuinely different directions when needed, explain the tradeoffs in plain language, and recommend one.
Lock the selected direction in a versioned Theme Lock: mood, visual thesis, palette intent, typography intent, grid, spacing, density, image treatment, chart language, page archetypes, and forbidden patterns. A Theme Lock is a project design record, not a pptx-designer API object. Resolve it once with ThemeComposer.compose(...), save the resulting complete resolved theme, and pass that object to the generation API.
Present the structure and visual direction for confirmation before building a delivery-grade deck, unless the user explicitly requests a one-shot draft.
Generate a reproducible Python build script or structured content using documented public pptx_designer APIs. Record the Theme Lock version, resolved-theme source, seed, package version, and module path with the generation result.
Run the generation path and perform basic structural checks.
Export the PPTX to PDF and PNG using skill/scripts/render_pptx.ps1.
Inspect the rendered PNGs directly using two gates. Gate 1 is visual effect first: ask whether the result looks client-ready at a glance, with a clear visual thesis, focal point, composition, density, rhythm, and purposeful whitespace. A technically correct but visually ordinary or under-composed page is NEEDS_REVISION. Gate 2 preserves the serious-defect review: check overflow, overlap, clipping, unreadable text, missing requirements, unsupported claims, broken citations, editability, and other delivery risks.
Check every page against the brief acceptance contract; use a contact sheet only as an overview, never as the sole review for a delivery deck.
Record requirement-by-requirement evidence: PASS, NEEDS_REVISION, or BLOCKED. Do not replace this comparison with a generic aesthetic opinion.
If the PNG review finds a material issue or a failed MUST condition, identify the source-code/content cause, revise, regenerate, and inspect again. Return to the failed decision level: revise the visual direction, composition, or asset strategy for a directional failure; use local edits only for a local defect. A deck is not complete while a MUST condition is unresolved.
Present the reviewed PNGs or contact sheet and the acceptance result for user confirmation, then deliver the PPTX, source script, PDF, and PNG preview directory.

Design read: variance, motion, density

Set three 1-10 dials before choosing layouts:

Variance controls structural variation. Low variance uses a consistent grid and component family; medium variance mixes two or three strategies; high variance permits section dividers and distinct page architectures.
Motion controls animation ambition. Low motion uses no animation or fade; medium motion reserves transitions for section changes and emphasis; high motion is only appropriate when the delivery context supports it.
Density controls information load. Low density uses generous whitespace and one or two major elements; medium density mixes narrative and data; high density uses dashboards, tables, and carefully organized grids.

These dials change composition, not just colors. They must remain compatible with the audience and domain.

Three-mode architecture

The skill has three generation modes. Do not collapse VI Build into a generic template option:

Mode	Use case	Content/layout control	Quality target
Build Mode	Delivery-grade blank-canvas deck	Python source with exact element placement	Highest composition control
FreeStyle Mode	Fast exploration or goal-driven content	`generate_ppt(query=...)` or `generate_ppt(content=...)`	Fast, coherent draft
VI Build Mode	Existing enterprise template and brand compliance	Template + extracted design DNA + controlled new pages	Preserve brand framework

Build Mode

Default for investor, board, client, sales, strategy, editorial, and other delivery-grade work when no supplied template must be preserved. The LLM writes a reproducible Python script using Presentation() and public pptx_designer.tools.* APIs.

Pass the complete resolved theme with Presentation(theme=resolved_theme, strict_theme=True) for ordinary themed Build Mode. Partial contexts are only for VI/template work and must be visibly diagnosed; do not pass a Theme Lock directly as a theme.

FreeStyle Mode

The library completes the deck through generate_ppt(). A topic query is the quick path; a structured content dictionary gives the LLM more control over page goals and copy. They are two input forms of the same FreeStyle mode, not separate rendering engines. FreeStyle does not provide pixel-level placement control and does not replace the PNG review gate.

When a direction is locked, call generate_ppt(theme=resolved_theme, ...). Do not also pass style, palette atoms, or style_seed: FreeStyle treats a supplied resolved theme as authoritative and reports those discovery arguments as ignored.

VI Build Mode

Use when the user supplies template.pptx, a corporate master, or a brand compliance requirement. The workflow is:

inspect the template and call extract_design_dna();
preserve the template's framework pages, logo treatment, margins, fonts, colors, and recurring decorations;
translate the extracted DNA into explicit brand tokens;
combine template context, resolved theme, and page constraints through merge_vi_design_context(template_context, resolved_theme, page_context); template-locked fields must remain unchanged and conflicts must be reviewed;
add new content pages using the template as the base and public pptx_designer helpers;
render every page to PNG and verify that the new pages belong to the same visual system.

Do not promise exact reproduction of unsupported PowerPoint master, SmartArt, animation, or OOXML behavior. Read references/template-brand.md before handling a template.

Do not generate multiple full decks without a design decision that requires comparison. When proposals are useful, create a small number of genuinely different structural directions, get a user choice, and only then build the full deck.

Design guardrails

Detect the presentation domain before selecting a visual language.
Design for the audience and page goal, not for generic decoration.
Treat a deck as one visual system: lock palette, typography, spacing, margins, component language, and image treatment across pages.
Prefer restraint, hierarchy, whitespace, and meaningful visual variation.
Put visual quality before technical completeness: every page needs a focal point, a deliberate composition, and a complete takeaway. Whitespace must be purposeful, not a symptom of underplanned content.
Use concrete claims and real data; label hypothetical numbers.
Use native editable text, shapes, charts, and diagrams whenever possible.
Use cover-fit image helpers; never stretch images.
Keep important information out of decorative effects and rasterized images.
Do not report success based only on Python execution, file existence, or shape counts.

Forbidden behavior

The following behaviors are prohibited unless the user explicitly requests a quick exploratory draft and accepts the limitations:

generating a delivery-grade deck without first establishing a page plan;
using a generic hook/problem/features/CTA arc for scientific, academic, clinical, or other domains where it is inappropriate;
treating palette or font changes as structurally different proposals;
repeating the same card grid or bullet-list layout on most pages;
shrinking body text to fit excessive content instead of editing or splitting the content;
inventing precise metrics, citations, customer claims, or evidence;
changing theme, typography, or color semantics mid-deck without a stated narrative reason;
stretching images, using irrelevant stock imagery, or relying on full-page screenshots for important editable content;
using raw slide.shapes.add_shape(), add_textbox(), or add_picture() as the default Build Mode implementation when a documented pptx_designer helper exists;
importing the old ppt_pro_max package or undocumented/private helpers;
claiming visual quality based only on source-code inspection or a successful .pptx save;
skipping PNG inspection after a material revision.

These hard anti-patterns remain prohibited: flat stacks of default rectangles, random gradients, stretched images, tiny CJK body text, unreadable charts, repeated card grids, fake precision, filler marketing language, and a deck where every page has the same density and structure.

Content-to-layout rules

Up to five concise bullets may use one column; six or more usually need two columns, cards, a table, or a diagram.
Ten or more items must not remain a dense bullet list; convert them into a meaningful visual structure.
Technical topics should use architecture, process, specification, or code views when those communicate better than feature cards.
Education and training decks should include an exercise or practice step when the learning objective requires it.
Scientific data pages should use figure-plus-caption structure and citations; KPI cards and marketing hero patterns are normally inappropriate.
Section changes should receive a visual transition when it improves rhythm; decoration alone is not a reason to add a section page.
Keep hook subtitles short and CTA copy action-oriented; do not overload hero pages with body paragraphs.

Additional content rules:

The first feature may carry the primary emphasis, but later features must remain visually subordinate rather than competing equally.
Use a section divider when the topic changes materially and the pause helps the audience reset.
Use code or architecture views for technical credibility, exercises for learning objectives, and figure captions/citations for research claims.
Do not use KPI cards, business hero pages, or feature-card language as the default for scientific and academic evidence.
A quote should normally fit within three lines and include name, role, and organization.
Keep one theme locked across the deck; micro-variation is allowed, unrelated mid-deck theme changes are not.

Domain detection

Detect the domain before the visual solution. Typical signals include:

Scientific research: gene, protein, sequencing, CRISPR, assay, omics, pathway, mutation, expression, experiment.
Academic thesis: thesis, dissertation, defense, viva.
Engineering/technical: architecture, infrastructure, deployment, API, microservice, system design.
Medical/clinical: diagnosis, treatment, patient, surgery, clinical.
Government/public sector: policy, regulation, compliance, budget.
Business/product: pitch, investor, sales, launch, KPI, revenue.

When a domain match changes the structure or visual semantics, ask instead of silently defaulting to a business deck.

Public API rule

Use only documented public pptx_designer imports. Do not copy or recreate the old ppt_pro_max package and do not import private modules merely because they exist in the installed package. Read references/public-api.md before writing Build Mode code.

PNG visual review

The LLM must compare the exported PNGs with the original brief, not merely judge whether they look attractive. Before generation, turn the brief into a small acceptance contract. After rendering, assess:

whether every MUST requirement is visibly satisfied;
whether each requested audience, scenario, mood, language, and action is reflected in the pages;
whether the planned page goals and narrative order survived generation;
whether the requested brand, template, image, and editability constraints are respected;
when reference material was supplied, whether its agreed observable qualities are visibly transferred rather than merely echoed through superficial styling;
whether SHOULD and NICE_TO_HAVE conditions are met or explicitly waived;
visual hierarchy and page-level clarity;
readability at presentation scale;
text overflow, overlap, clipping, and awkward spacing;
content density and balance between filled and empty areas;
whether large empty regions have a declared narrative purpose; an underfilled page is NEEDS_REVISION when its whitespace does not create focus, pacing, or hierarchy;
whether each delivery page has a sufficient visual anchor and a complete takeaway; “clean” or “minimal” is not an excuse for missing evidence or weak composition;
chart and diagram legibility;
image crop, relevance, and tonal consistency;
typography, contrast, palette, and visual consistency;
whether the deck matches the requested audience, scenario, and mood;
whether the result looks intentionally designed rather than template-like;
whether important objects remain independently editable in the PPTX.

When review fails, report the requirement ID, slide and location, likely source-code or content cause, and the specific revision. Read references/qa-and-delivery.md for the review record and acceptance language.

Supporting references

workflow.md: full brief-to-confirmation process.
design-direction-coach.md: novice-friendly design recommendations and visual-direction lock.
design-principles.md: detailed design thinking and content rules.
domain-paradigms.md: domain-specific structures, visual languages, and anti-patterns.
public-api.md: curated public API contract.
content-schema.md: structured content mode.
template-brand.md: VI Build and template compliance workflow.
qa-and-delivery.md: structural checks, PPTX-PDF-PNG rendering, PNG review, and delivery gate.
install-and-runtime.md: Python and rendering dependencies.

PPT Design Skill

Skill Details

先选对生成模式

交付级任务，默认选择 Build Mode

如何判断

Skill 的核心价值

核心理念

精选设计案例

Install

LibreOffice 为什么是可选依赖？

检查真实案例

文档入口

解决什么问题

设计能力

模式详细说明

FreeStyle

VI Build Mode

Build Mode

设计过程中的三个控制量

重要禁止行为

运行和渲染

交付清单

目录结构

ppt-design-skill

PPT Design Skill

Designer mindset

Stop before writing code

Non-negotiable outcome

Workflow

Design read: variance, motion, density

Three-mode architecture

Build Mode

FreeStyle Mode

VI Build Mode

Design guardrails

Forbidden behavior

Content-to-layout rules

Domain detection

Public API rule

PNG visual review

Supporting references

Related Skills