name: HXMPPT description: Create, edit, replicate, read, and export presentations. For every PPT task, the default deliverables are BOTH (1) a self-contained PPTD project folder containing the .pptd manifest plus pages/media dependencies and (2) a locally generated .pptx with fade slide transitions. PPTD is the editable YAML DSL; PPTX export runs locally through python-pptx (no Kimi public editor, no browser, no Node.js). Follows a draft-first workflow: one round of questions, generate the full draft in one pass, then a MANDATORY human review gate before any final QA or polish — the human judges the direction first, so a wrong direction is caught cheaply. Use for any presentation, PowerPoint, PPT/PPTX, slide deck, PPTD, infographic, or poster task unless the user explicitly requests another format. Deliver with normal local file/folder links using absolute paths.

⛔ THE #1 RULE: show the draft, then STOP

The whole workflow is draft → human gate → polish. Everything below serves this loop. Read these five lines before anything else:

Ask requirements in ONE round (with defaults), then generate the entire draft in ONE pass — all pages in parallel, no self-iteration.
Render the overview image + a draft .pptx and present them to the human.
END YOUR TURN right there. Do not continue, do not self-QA, do not polish, do not re-export in the same turn. The next action belongs to the human:
- "continue / 可以" → one final QA pass (bugs only) → export final → deliver;
- concrete feedback → edit ONLY the pages they mention → show again;
- "wrong direction / 换风格" → regenerate from scratch.
The QA checklist (step5) runs ONLY after human approval. If you catch yourself running QA, fixing pages, or "polishing" a draft the human has not seen — STOP. That draft's only job was to be judged, and a draft the human never sees is 100% wasted work.
Skipping rule 3/4 is the single most common failure of this skill. A short, imperfect draft that the human sees in minutes is worth far more than a "perfect" deck that took hours of hidden self-QA.

Definition

HXMPPT is a presentation creation and export skill built around Moonshot AI's PPTD format. It defines a YAML-format intermediate DSL (.pptd) that abstracts OOXML and keeps each page self-contained.

The default output is not PPTD-only. Unless the user explicitly opts out, always produce both:

the complete editable PPTD project directory (.pptd + pages/ + media/ and other referenced dependencies);
the matching locally generated .pptx, with a fade slide transition applied to every slide by default.

PPTX export runs locally with python-pptx — no Node.js, no browser, no network access to Kimi's public editor. Visual QA images are rendered locally with Pillow from the same PPTD source.

Why local-only now? The previous exporter drove Kimi's public browser-side OOXML writer through a localhost SDK bridge. Moonshot AI shut that reverse-engineered path down and cleared the upstream repository. The current exporter is a self-contained Python renderer that follows the PPTD spec directly. Font embedding and element animations are not supported by the local writer; exotic chart types render as static images — see "Limitations" at the bottom of this file.

Existing PPTX files may be converted into PPTD for editing with scripts/import_pptx.py (best effort: text/shapes/pictures/tables/connectors are imported; charts, groups, animations and notes are skipped with warnings — see "Limitations"). After editing, both outputs are delivered again.

The pptd format

The .pptd format is a simplified abstraction layer over OOXML that follows basic YAML syntax. This abstraction preserves the core content of OOXML (theme, page layout, element positions and definitions, etc.) while removing complex nesting logic such as Masters; every page is self-contained — what you see is what you get. Read reference/pptd.md for the complete definition of this DSL.

PPT production workflow

step0. Check local prerequisites

Default delivery includes PPTX export and visual QA previews, which need a small local Python toolchain. Before generating, verify:

python3 (3.9 or newer): run python3 --version (on Windows, python may be the correct command). If python3 is missing and the user has not explicitly chosen PPTD-only output, stop immediately, tell the user to install Python from https://www.python.org, and do not continue; if PPTD-only was agreed, deliver the PPTD project and report the blocker (same fallback as step6).
Node.js and agent-browser are NOT required — the local converter is pure Python. Complex chart types (candlestick / waterfall / heatmap / treemap / sunburst / sankey and mixed-type combos) additionally use matplotlib when present; it is auto-installed on first use.
Soft deps are auto-installed by scripts/export_pptx.py and scripts/export_images.py via pip when missing: PyYAML, python-pptx, Pillow, and (on demand) matplotlib. Installation targets the active virtualenv when one exists and pip install --user otherwise. Set HXMPPT_NO_INSTALL=1 to disable auto-install in air-gapped/CI environments — the exporter then reports exactly which package is missing.
Script paths below are relative to the directory containing this SKILL.md (the skill root). When invoking a command, resolve it to the absolute path of the installed skill, e.g. <skill-dir>/scripts/export_pptx.py. install.sh in the skill root installs the skill into the standard Claude/WorkBuddy locations.

step1. Read the context thoroughly

Read all files uploaded by the user, the provided URLs, and the pptd format guide reference/pptd.md to fully understand the user's requirements.

step2. Quick requirements (one round of questions, then go)

Understand the user's requirements based on the context:

Determine the purpose of the request

Create a PPT: create a new presentation (from scratch, or from an existing pptx template)
Edit a PPT: edit the user's uploaded PPT (local modifications, single-page beautification, etc.)
Replicate a PPT: replicate a presentation from a non-pptx format (images, PDF, etc.) into pptd format

Determine the design direction (self-directed / design system / template / style transfer — see step3)
Determine the input type (topic only / full document / outline). When the input is a full document or outline and expansion was not forbidden, prefer expanding with relevant material.
Determine the page count (user request wins; outline → match it; topic only → recommend and confirm).

Speed rules (mandatory)

Ask at most ONE batch of questions. Combine topic / input / page count / style / audience into a single ask, and give a default answer to every question so the user can reply with one word or nothing.
If the user does not answer, state your assumptions in one line (e.g. "按商务咨询风、约 15 页处理") and proceed. The human review gate (step4) is where wrong assumptions get caught — cheaply.
Only interrupt for genuinely blocking problems (inaccessible files/URLs, contradictory hard constraints). Do not burn rounds on taste questions before the draft exists — a draft communicates taste far better than questions.

step3. Generate the first draft (one pass — speed over polish)

Before generating, first read reference/pptd.md to understand the pptd format definition and constraints.

Draft-first rules (mandatory)

Generate the entire deck in a single pass. Design the storyline and page plan up front, then write every .page file in parallel batches. Do not write a page, re-read it, and rewrite it on your own.
The first draft's only job is to let the human judge the direction — storyline, structure, density and style. "Good enough to judge" is the bar. Pixel-perfection before the human has seen the deck is a bug, not a virtue.
No self-QA loops before the human gate. Run exactly one sanity check: the exporter parses and runs without warnings that indicate broken pages. Do not run the visual QA checklist, do not self-repair, do not re-generate pages pre-emptively.
Keep the draft cheap. A rejected direction should cost minutes, not hours — the user may switch model, style or instructions based on the draft.
After writing the draft, go straight to step4 (human review gate). Do not skip it, even for "simple" decks.

Replicating a PPT

Analyze the images to estimate element positions, fonts and sizes, etc., and replicate 1:1 as closely as possible.
For parts that are difficult to make out, use methods such as grid lines and close-up views to improve understanding.
Replicate simple content in the image with elements; icons may be approximated with icons provided by Font Awesome. For content that cannot be approximated with icons or shapes, such as photos and avatars, use tools such as bash or python to crop and split the original image, then add the resulting image elements to the presentation

Editing a PPT

Convert the user's uploaded pptx file to .pptd format with scripts/import_pptx.py (best-effort import; review the reported "skipped" warnings — charts/groups/notes are not imported)
Review the converted pages (structure and key visual details). Read a few key pages individually afterwards.
Locate the pages to edit, and be careful not to affect parts outside the intended scope.

Conversion from pptx to pptd is not perfectly lossless. If the user later reports format errors, garbled content, etc., compare against the original pptx and repair the pptd with reference to the comparison

Generating a PPT

When generating a PPT, adopt different production approaches for different user [design directions]

Self-directed design

Read the design guide reference/slides_categories.md, and read the scenario document corresponding to the user's query
Produce the presentation based on the above

Generating content in other formats

When the user explicitly asks for an infographic, poster, or a highly visual single-page design, read reference/general-poster.md and implement it as a single-page or few-page editable PPTD; when the user only asks for an image, still build it with PPTD first, then output the image via screenshot or rendering. Do not load this reference file for ordinary PPT requests.

Design system

Read the general constraints section of the reference/slides_categories.md guide, and read the scenario document corresponding to the user's query as the design foundation
Read the specified design system as the presentation style: either the user-provided design scheme, or the matching preset under reference/design_system/. Consult reference/design_system/README.md for the full catalog — it maps every preset to its recommended file. Some presets exist in two formats (the polished design.md "Signature System" and an original en/*.md source doc); always prefer the folder's design.md when present. It is strictly forbidden to reference or mix in other design styles
Produce the presentation with reference to the above
Do not auto-pick a preset during self-directed design; only use reference/design_system/ when a preset is explicitly specified

Using a template

Convert the user's uploaded pptx file into pptd form with scripts/import_pptx.py (best-effort import; review the reported "skipped" warnings)
Review the converted pages to understand the template's visual style (color scheme, font style, element characteristics, layout characteristics, content density, etc.)
Identify page types; focus on reading special pages such as the cover, summary pages, and section dividers (single-page screenshots, .page files), extracting their page layouts, content structures, reusable components (icons, shapes, smartart, reusable body layout schemes, etc.), and element styles (e.g., whitespace/line/card separators, square/rounded corners, etc.)
Produce the presentation using the template

Style transfer

Analyze the reference file's visual style (color scheme, font style, element characteristics, layout characteristics, content density, etc.), page layouts, content structures, reusable components (icons, shapes, smartart, reusable body layout schemes, etc.), and element styles (e.g., whitespace/line/card separators, square/rounded corners, etc.).

If the user provides a style reference URL, do not only read the text content; refer to and learn from the page's visual effect more to help understand the style

Produce the presentation using the reference file's style characteristics. You are encouraged to reuse illustrations, fonts, font-size hierarchies, elements, etc. from the original pdf/url

Images and Visual Materials

Images are an effective way to enrich a presentation's visual impact. Appropriate images should be used not only on covers and section dividers, but also on body pages to enrich the page, aid understanding, or support decision-making
Images are used to show concrete subjects, explain content, provide evidence, or establish a scene. Logos, icons, decorative textures, and very small thumbnails do not count as substantive imagery.
When a page involves products, people, places, buildings, events, cases, interfaces, experimental subjects, or spatial environments, prioritize corresponding real images or screenshots. If real images and screenshots cannot be obtained, generated images may be used instead.
Image priority: images provided by the user; images from official websites, official reports, and credible sources; searched images that are directly relevant to the content; images generated for conceptual expression or atmosphere.
After deciding which images are needed, complete image search, generation, and downloading in a batch before designing pages around their proportions. Save images in the media directory, keep them clear, and never stretch or distort them.
Analytical, technical, and academic PPTs should use corresponding evidence images when products, experiments, interfaces, cases, or on-site materials are available. Do not reduce every page to text, color blocks, and shapes.
Do not add irrelevant images merely to meet a quantity target. Every image must be directly relevant to the page's conclusion or communication goal.

Content Guidelines

唯一字体（强制）：全片只使用微软雅黑（Microsoft YaHei），中文、西文、数字、表格、图表、图标一律如此。不得设置任何其他 fontFamily，不得使用 customFonts；reference/design_system/ 里所有设计系统的字体条目一律忽略（详见 reference/fonts.md）。渲染器会在导出时强制覆盖为微软雅黑，视觉层级用字号/字重/颜色/字距表达，而不是换字体。
Language style: unless the user explicitly requests otherwise, strictly avoid overly abstract expressions and uncommon metaphors

Do not overuse metaphors, slogans, or abstract jargon such as distribution, an N-step argument, everything at a glance, a closed loop, hands-on practice, verification, deconstruction, second-class citizens, poison pills, or wall clocks
Do not use common AI phrasing such as "not X, but Y," "X is Y," "why / based on what / how," "key takeaway," or "N battlefronts / paths"
Do not use overly colloquial expressions such as "where should the ammunition go," "the Nth thing," "can't pick the right one," or "cannot be used as X"

step4. Human review gate (MANDATORY checkpoint — never skip)

The human decides the direction; the agent only proposes. Present the draft and stop.

Render the overview image:

python3 <skill-dir>/scripts/export_images.py \
  /abs/path/project/deck.pptd \
  --output /abs/path/project/.qa-images

Generate a draft .pptx with scripts/export_pptx.py (same command as step6) so the human can open it in PowerPoint/WPS.
Deliver to the human, in one message:
- the overview image (.qa-images/overview.jpg) — the main artifact for judging the design;
- the draft .pptx and the project directory (clickable absolute links);
- a 2–3 line summary: chosen style, page structure (cover/TOC/sections/closing), and the 2–3 things most worth their attention.
END YOUR TURN HERE — make no further tool calls this turn. This message IS the completion of your current task. Do not self-QA, do not polish, do not re-export a "final", do not run the step5 checklist, do not edit any .page file in this turn. You will be told what to do next.
Handle the verdict (in a later turn, after the human replies):
- "方向可以 / 继续" → go to step5 (final QA).
- 具体修改意见 → apply ONLY the requested changes to the relevant .page files, re-run export_images.py --force, and present again. Do not touch pages the human did not mention. Repeat until the human approves or the feedback dries up (usually 1–3 rounds).
- "风格/结构不对" (the user may switch model or instructions) → do not defend the draft. Regenerate from scratch with the new direction — a rewrite of a wrong draft is cheaper than patching it.
The human's verdict overrides every rule in this file.

step5. Final QA (single pass — only after human approval)

QA is for bugs, not taste. Taste was settled at the human gate. One pass, then ship.

Validate the pptd against reference/pptd.md (required fields, types, bounds, theme tokens, resource paths) and repair only errors that break rendering.
When the model supports image input, read the overview image and check the pages against this list once:
1. 图片是否清晰、不变形（无拉伸、压缩、模糊）
2. 文字是否压在关键画面（人脸、产品主体、Logo 等）上
3. 元素坐标是否超出页面边界
4. 边界与配色对比是否足够（文字与背景、相邻色块之间）
5. 排版是否统一（对齐、间距、字号层级、页边距）
6. 文字是否可能溢出文本框（文本过长、行距过密、字号过大）
7. 内容是否被上层元素遮挡
Fix only clear defects found in that pass (overflow, out-of-bounds, missing images, garbled text). Do not redesign, re-layout, or re-typograph pages the human already approved. At most 2 targeted fix→re-render rounds; then ship.
The QA renderer is intentionally lightweight: it draws backgrounds, text (including alpha blending), common shapes, images, tables, icon glyphs, and labeled chart placeholder boxes. Chart pixels and complex icon shapes are not replicated — chart correctness is verified in the exported PPTX.
When the model cannot read images, fall back to a structural review (bounds, overflow-prone long text, contrast, density) in one pass, and state that image-based QA was skipped.
.qa-images/ is an intermediate artifact and may be deleted after delivery.

step6. PPT output and delivery

Always produce a self-contained project directory. Keep the .pptd manifest and every referenced dependency together; never deliver a standalone manifest without its referenced files. Use this layout unless an existing project already has a valid equivalent structure:
```
deck/
  deck.pptd
  pages/
    *.page
  media/
    *                # when the deck has local media
  deck.pptx          # generated by default
```
Generate the .pptx by default after final QA, even when the user only asks to create or edit a presentation. Skip PPTX export only when the user explicitly requests PPTD-only output or the environment cannot run the exporter; in the latter case, report the exact blocker and still deliver the complete PPTD project.
Deliver with normal clickable local links using absolute paths. In the final response, link all of the following:
- the project directory;
- the .pptd manifest;
- the pages/ directory and media/ directory when present;
- the generated .pptx file.
PPTX conversion: use scripts/export_pptx.py. It reads the .pptd project locally with python-pptx + PyYAML, renders every element to OOXML, patches the default slide-level fade transition into every slide, validates the PPTX zip integrity, and checks the transition element order. It performs no network access except downloading remote image URLs explicitly referenced inside the PPTD (and it caches those downloads under the system temp dir, keyed by URL). It does not launch a browser.
Default PPTX options:
- page transition: fade (淡入淡出), written to every slide after python-pptx renders the deck;
- font embedding: not supported by the local writer. The CLI accepts --embed-fonts for compatibility with the previous Kimi-editor-based pipeline; when set it logs a note and continues with fonts referenced by name only. Pass --no-embed-fonts (the default) to suppress the note.
Export command:
```
python3 <skill-dir>/scripts/export_pptx.py \
  /abs/path/project/deck.pptd \
  --output /abs/path/project/deck.pptx
```
A project directory may be passed instead of the manifest only when it contains exactly one .pptd file anywhere under it (the search is recursive). Existing output files are not overwritten unless --force is passed.
Local export requirements and boundaries:
- requires Python 3.9+ (python3 / pip); python-pptx, PyYAML, and Pillow are auto-installed when missing (venv-aware; opt out with HXMPPT_NO_INSTALL=1);
- runs entirely offline. The only optional network access is downloading remote image URLs referenced inside the PPTD itself (https://... paths on image elements or image fills), which is done with the standard library urllib;
- does not require Node.js, npm, agent-browser, Chrome, or any local server;
- the generated PPTX is written directly by python-pptx and then patched in place to inject the fade transition. The output passes a zip CRC check and a structural validation of every slide's transition element.
After export, verify that the output exists and report the generated path. Confirm that every slide has exactly one root-level fade transition in valid CT_Slide order (cSld, optional clrMapOvr, transition, optional timing/extLst) and that the PPTX ZIP passes integrity checks. A byte-string search for <p:fade> is insufficient because Office ignores transitions nested inside cSld. For higher-risk decks, additionally inspect font parts and representative rendered/opened pages as appropriate.
Element animations (page.animations in PPTD — entrance / emphasis / exit / motion-path; see reference/pptd.md §6): use them only when the user explicitly requests animations, or when the deck is clearly intended for live presentation / slideshow playback and animation provides a clear benefit for staged disclosure, process demonstration, causal explanation, pacing, visual impact, or brand storytelling. By default, do not add element animations to reading-oriented, self-study, print, or primarily send-and-browse decks. Prefer 1–3 animation groups per page and simple effects such as fade, fly, and zoom. This is separate from the default PPTX slide-level fade page transition written by export_pptx.py.
Speaker notes (notes on each .page): use them only when the user explicitly requests them; otherwise, do not add them.
Parallel tool calls: during PPT production, make tool calls in parallel whenever possible; in each round, write multiple page files in parallel to reduce the number of steps.

Limitations of the local writer (vs. the previous Kimi-editor-based pipeline)

The current PPTX exporter is a self-contained Python renderer; the trade-offs are intentional so the export never depends on an external service that can be shut down. When you hit a limitation, either pick an alternative or tell the user.

Font policy (locked): every text run, table cell, native-chart label, and icon glyph is exported as 微软雅黑 (Microsoft YaHei) — the only font. Any fontFamily written in the PPTD is overridden. Font embedding is not supported: viewers without YaHei installed (e.g. macOS without the font) substitute a system font; matplotlib fallback chart images and LaTeX formulas use 微软雅黑 when installed, otherwise the system CJK font.
Charts are supported. bar / line / area / scatter / bubble / pie(含 donut) / radar render as native editable PowerPoint charts (single-type, no secondary axis). candlestick / waterfall / heatmap / treemap / sunburst / sankey and mixed-type combos (e.g. bar+line) render as static images via matplotlib (auto-installed on demand; un-editable). When matplotlib cannot be installed, those charts are skipped with a clear warning. Advanced chart options (secondary axes, per-point gradients, stream stack shaping, spokeAxis styling) are approximated, and the exporter prints one warning line listing which fields were not fully honored.
Icons (elementType: icon) render as monochrome Unicode glyphs that respect the fill color for ~100 common icon names; unmapped names fall back to a rounded-rectangle placeholder with a warning. Font Awesome glyph files are not bundled.
Custom shape paths (shapeName: custom) are approximated as polylines with dense sampling of lines, cubic/quadratic Bezier curves, and elliptical arcs (16–24 points per segment). Good for logos and decorative shapes, but not pixel-faithful for extreme precision work.
Image cropShape on image elements supports roundRect / ellipse / rect; a custom clip path falls back to a rectangle with a warning.
Element animations (page.animations) are not translated into PPTX animation XML; the exporter prints a warning per page. The slide-level fade transition still applies.
Text styling: element opacity, text highlight (backgroundColor), letter spacing, vertical text direction and outer shadows (shadow with blur/color/offset) are rendered. Text gradient and text shadow are not; they fall back to the flat text color with a warning. Gradients with more than 2 stops and radial gradients are approximated as 2-stop/linear with a warning.
Math (LaTeX) formulas: a text element consisting of exactly one \(...\) formula is rendered to an image via matplotlib's mathtext engine (no LaTeX install required). Formulas mixed inline with other text remain literal text.
PPTX → PPTD import (scripts/import_pptx.py) is best-effort: text, shapes (incl. custom geometry and adjustments), pictures (incl. crop), tables (incl. merges), connectors and rotation/flip are imported; charts, groups, embedded media, animations and speaker notes are skipped with warnings. The conversion is not lossless — after import, review the rendered pages and repair discrepancies.

hao007007/HXMPPT

¿Qué es HXMPPT?

Preguntar en tu IA favorita

Documentación