ppt-atelier-skill

name	ppt-atelier-skill
description	Design and build polished, fully editable PowerPoint presentations through a high-fidelity visual workflow with a mandatory three-direction approval gate. Use this skill whenever the user provides a requirement paragraph, outline, prototype, screenshot, sample slide, document, existing deck, brand guide, layout request, or style reference and wants a professional PPT, 高保真PPT设计稿, 根据样例图做PPT, 三种版式方案, 设计稿还原为可编辑PPT, or editable PowerPoint reconstructed from images. The skill interprets mixed inputs, creates exactly three genuinely different layout/style directions, waits for explicit user selection, then expands the chosen system, recreates separate visual assets, builds native editable slides, and renders QA previews. Do not use it for outline-only writing, review without file creation, or a small text-only edit to an existing deck.
compatibility	Requires the installed imagegen and Presentations skills. Optional ZenMux generation requires Python 3, network approval, and ZENMUX_API_KEY in the environment. The default path uses built-in image generation and @oai/artifact-tool through the Presentations skill.

PPT Atelier Skill

把用户的需求、内容与视觉偏好先转化为三套可比较的高保真设计方向。用户明确选定其中一个方向后，再扩展整套设计、重绘独立素材，并以 PowerPoint 原生对象重建为完全可编辑的 .pptx。

Core contract

The three-direction approval gate is part of the deliverable, not an optional review step.

• Use the user's source material and approved copy as the content truth.
• Interpret requirements, sample images, layout notes, style references, and brand constraints according to their declared roles; do not silently treat every image as both structure and style truth.
• Create exactly three materially different design directions before producing the full deck.
• Stop after presenting the three directions. Do not create remaining page drafts, isolated assets, build code, or a PPTX until the user explicitly selects or approves a direction.
• Use the approved design direction as the layout, spacing, palette, and art-direction truth.
• Rebuild text, rectangles, lines, dividers, tables, charts, and simple diagrams as native PowerPoint objects.
• Use separate transparent PNG files only for distinctive icons, illustrations, textures, and complex decorative artwork that cannot be reproduced cleanly with native objects.
• Never use a full-slide screenshot as the final slide.
• Never crop icons from the design draft. Recreate them individually with clean edges, consistent styling, and sufficient resolution.
• Keep every user-facing text string editable. Image-generated text is never the source of truth.
• Preserve information architecture and business logic before adding visual polish.

Supporting skills

Before generating images, read and follow the installed imagegen skill completely. Its built-in path is the default provider.

Before authoring or editing the .pptx, read and follow the installed Presentations skill completely. Use its required @oai/artifact-tool JavaScript workflow, rendering tools, and slide overflow checks. Do not substitute python-pptx.

Read these bundled references only when their phase begins:

• references/prompt-library.md before creating the three options or any full-page draft.
• references/zenmux-provider.md only if the user explicitly chooses ZenMux.
• references/editability-and-qa.md before PPTX construction and final QA.

Phase 1: Interpret mixed input and lock requirements

Extract usable constraints from the conversation and supplied files before asking questions. The input may be any mixture of:

• a requirement paragraph or business goal;
• an outline, exact copy, data, or slide list;
• a prototype, sample image, screenshot, hand sketch, or reference slide;
• an existing PPT, document, spreadsheet, or brand guide;
• explicit layout, density, palette, typography, illustration, or tone requirements.

Inspect local images before using them as references. For each input, record one or more roles:

• content_truth: authoritative wording, values, or claims;
• structure_lock: information hierarchy, rows, columns, sequence, and business relationships to preserve;
• style_reference: visual mood or component language to interpret, not copy blindly;
• brand_reference: required colors, fonts, logo use, or brand restrictions;
• source_asset: approved photography, logo, or artwork that may be placed directly.

When references conflict, prioritize factual correctness and explicit user constraints. Ask one bundled question only when an unresolved conflict would materially change the result. Otherwise make the smallest reasonable assumption and label it.

Lock:

1. Purpose, audience, and presentation context.
2. Source hierarchy and exact factual content.
3. Required slide count or a justified range.
4. Canvas, defaulting to 16:9.
5. Hard layout and brand constraints.
6. Flexible visual preferences and references to avoid.
7. Whether each sample image locks structure, suggests style, or supplies an asset.
8. Image provider: built-in imagegen by default; ZenMux only when explicitly chosen.
9. Delivery path and language.

Write planning/requirements-map.txt with these sections:

Hard constraints
Flexible preferences
Input-role mapping
Inferred decisions
Unanswered blockers

Use this workspace structure:

source/                     original references and extracted source notes
planning/                   requirements, exact copy, blueprints, and visual system
design/options/             three pre-approval high-fidelity directions
design/full-page/           chosen-direction page drafts
prompts/design-options/     prompts for A, B, and C
prompts/design/             one final design prompt per slide
prompts/assets/             one prompt per generated asset
assets/<slide-id>/          transparent PNG assets
build/                      plain JavaScript .mjs source for the deck
qa/rendered/                rendered slide PNGs
qa/editability-report.txt
outputs/                    final PPTX and requested previews

Keep final user deliverables outside scratch if the host defines a separate output location.

Phase 2: Content blueprint

Create the exact editable content before generating design images. This prevents distorted image text from leaking into the final deck.

Write:

• planning/deck-brief.txt: purpose, audience, source hierarchy, page count, constraints, and assumptions.
• planning/slide-blueprint.json: one record per slide with exact title, body copy, rows/columns, hierarchy, source provenance, and required visual relationships.
• planning/visual-system.json: known brand constraints plus undecided fields marked for style exploration.

Classify each page as title, section divider, executive summary, comparison, matrix, process, dashboard, timeline, evidence, or closing page. Preserve different silhouettes across a multi-slide deck instead of turning every page into the same card grid.

For sparse or incomplete input, draft concise copy and clearly distinguish user-supplied facts from inferred framing. Do not invent numbers, evidence, customer names, or business claims.

Phase 3: Create exactly three design directions

Read references/prompt-library.md. Create three high-fidelity 16:9 options using the same locked content and business logic.

Choose the comparison canvas:

• For a one-slide request, create three versions of that slide.
• For a multi-slide deck, choose one representative anchor content slide that exposes the deck's real hierarchy, density, and visual needs. Prefer a summary, matrix, process, or data slide over a cover.
• If the user explicitly requests three versions of every page, comply; otherwise do not triple the cost of the whole deck before direction approval.

Design A, B, and C must differ materially across at least these axes:

1. Information composition and page silhouette.
2. Typography hierarchy and rhythm.
3. Density and whitespace strategy.
4. Graphic metaphor, icon language, and decorative system.
5. Color application and visual emphasis.

Do not present three recolors or minor component reskins. Preserve the same facts, labels, rows, columns, and relationships so the user is comparing design rather than content.

For each option:

1. Give it a short, relevant direction name based on the brief.
2. Generate one complete presentation page, not a website, product UI, or marketing poster.
3. Keep the composition feasible to reconstruct with native PowerPoint objects and isolated assets.
4. Inspect it at full size for hierarchy, whitespace, legibility, and source fidelity.
5. Save the image as design/options/option-a.png, option-b.png, or option-c.png.
6. Save its prompt under prompts/design-options/.
7. Record its rationale, strengths, tradeoffs, and best-fit use in planning/style-options.txt.

Create a labeled comparison montage that shows A, B, and C at equal size. Present the montage plus a compact comparison of the three directions.

Mandatory approval gate

After presenting A, B, and C, stop the workflow and ask the user to select one direction or request revisions. This stop applies even when the original request says “直接完成”, “全流程执行”, “不用中途问我”, or equivalent. Those instructions may streamline later execution, but they do not waive style approval.

Valid outcomes:

• The user explicitly selects A, B, or C.
• The user explicitly approves one named direction.
• The user requests a hybrid. Create one hybrid confirmation sample, present it, and stop again until the user explicitly approves it.
• The user rejects all three. Revise the brief and create a new set of three options.

Do not infer approval from silence, positive sentiment without a choice, or the agent's own preference. Before approval, do not generate isolated icons, remaining page drafts, build source, or a PPTX.

Phase 4: Lock the selected system and expand the deck

After explicit approval, write planning/style-decision.txt with:

• selected direction and user wording;
• approved hybrid changes, if any;
• palette, typography, grid, radii, stroke, icon language, density, and decoration rules;
• elements explicitly rejected by the user.

Update planning/visual-system.json, then generate one complete chosen-direction design image per slide.

For each slide:

1. Build a prompt from the exact slide blueprint and approved visual system.
2. Preserve the structure and business logic of any structure-locked reference.
3. Use built-in imagegen unless the user explicitly selected ZenMux.
4. Generate at a wide 16:9 resolution. Prefer 3840x2160 when supported; otherwise use the closest landscape size with a 16:9 center-safe composition.
5. Inspect the draft at full size and iterate with one targeted change at a time.
6. Save the selected draft to design/full-page/slide-XX.png and its prompt to prompts/design/slide-XX.txt.

Vary page silhouettes according to content while retaining the approved visual DNA. Image-generated wording remains a composition reference; the final PPTX uses the locked text in slide-blueprint.json.

Phase 5: Inventory and recreate isolated assets

Analyze each approved design draft and write planning/asset-manifest.json. Give every visible element one disposition:

• native_text: all readable copy.
• native_shape: color blocks, containers, borders, dividers, backgrounds, badges, and simple geometry.
• native_table_or_chart: structured tables, matrices, and data charts.
• generated_png: distinctive icons, illustrations, textures, or complex decorative artwork.
• source_image: user-provided photography or approved source artwork.

For every entry record the slide, element ID, bounds or normalized position, colors, intended PPT layer, output path, and why the disposition preserves editability.

For every generated_png entry:

1. Recreate one asset per generation; do not create a sprite sheet.
2. Match the chosen direction's color, roundness, stroke weight, depth, and finish.
3. Exclude text, labels, watermarks, and unrelated decoration.
4. Generate against a flat chroma-key background and remove it locally with the installed imagegen helper.
5. Validate alpha, transparent corners, crisp edges, no key-color fringe, and sufficient resolution.
6. Save it under assets/<slide-id>/<element-id>.png and retain its prompt.

Build lines, gradients, circles, rounded rectangles, and other deterministic geometry natively instead of generating PNGs.

Phase 6: Reconstruct the editable PPTX

Read the installed Presentations skill and references/editability-and-qa.md before coding.

Use the approved full-page drafts only as visual calibration layers during development. Reconstruct each slide in plain JavaScript .mjs with @oai/artifact-tool:

1. Set the correct 16:9 slide size.
2. Map image coordinates to slide coordinates consistently.
3. Create connectors and lines before foreground nodes when layering diagrams.
4. Rebuild all locked copy with native text boxes.
5. Rebuild tables, matrices, charts, backgrounds, cards, and separators with native objects.
6. Place each approved transparent PNG at the manifest position without visible upscaling blur.
7. Keep recurring elements, margins, title positions, and page markers consistent.
8. Export a distinct final .pptx; preserve any input deck unless the user explicitly requests in-place editing.

Do not place a complete design draft behind native text as a shortcut. The final slide must remain visually coherent if all full-page design images are removed.

Phase 7: Render, compare, and fix

Render every slide to PNG with the Presentations skill's tools. Inspect each slide individually at full size; use a montage only for deck-level consistency.

Run the required overflow and overlap checks, then compare renders with the approved drafts. Fix:

• text overlap, clipping, unintended wrapping, and overflow;
• incorrect row or column alignment;
• spacing, color, font hierarchy, and layer-order drift;
• blurred or stretched icons;
• unresolved placeholders or image-generated text;
• chart or table values that do not match the source;
• any unintended full-slide raster image.

Write qa/editability-report.txt using references/editability-and-qa.md. Continue until all blocking checks pass.

Phase 8: Delivery

Deliver at least:

• the final editable .pptx;
• a rendered preview montage or requested per-slide previews.

Retain the selected direction, full-page drafts, asset manifest, generated PNGs, prompt records, and build source for follow-up edits. Do not clutter the final response with scratch files unless the user asks for the production package.

Report briefly:

• final PPTX and preview paths;
• number of slides;
• selected design direction;
• image provider used;
• whether ZenMux received prompts or reference-image data;
• any accepted non-blocking fidelity limitations.