Codex Ppt

Codex PPT

Overview

This skill creates image-based PowerPoint decks from source material. Each slide is a complete 16:9 generated image. Final images are assembled into .pptx with scripts/assemble_ppt.py.

Use this when the user wants a visually unified presentation and accepts full-slide image pages. Do not use it when every textbox, chart, or shape must remain separately editable.

Prefer the built-in image generation/editing tool. Use scripts/image_gen.py only when the built-in backend is unavailable, lacks a required capability, or the user explicitly asks for API/CLI mode.

Hard Constraints

• Read the relevant Reference Map files before each phase. This file is the orchestration contract; detailed rules live in docs/ and worker prompts in prompts/.
• Respect approval gates. Do not create final deck_spec.json, speech.md, prompt jobs, slide images, or .pptx before the approvals in docs/workflow-gates-and-progress.md.
• After the user approves the sample slide and authorizes full-deck generation, every remaining slide image job must be dispatched to a slide subagent whenever subagents are available.
• The main agent owns orchestration, prompt jobs, state recording, QA, speaker notes, and assembly. Do not silently replace available slide subagents with sequential production.
• Every final origin_image/slide_XX.png must be generated by the selected image backend: built-in image generation/editing tool or scripts/image_gen.py.
• Local drawing, Pillow, SVG, HTML/CSS/canvas screenshots, python-pptx/PptxGenJS layouts, and manual overlays are failure modes, not fallbacks.
• The selected image backend must stay fixed after backend confirmation. Do not let subagents switch backend for convenience.
• After sample approval, record how the approved sample was generated and pass that exact method to every slide subagent.
• Slide dispatch and result state must be recorded with the bundled scripts. Chat messages alone do not make a slide dispatched or complete.
• If a required subagent, image backend, or required-image path is unavailable, stop and report a blocker with the slide id and evidence. Do not create a lower-quality replacement.

Visible Progress

For non-trivial decks, keep a user-visible checklist with one active step. Canonical completion evidence is in docs/workflow-gates-and-progress.md.

Default visible steps:

1. Prepare source, outline, style, and backend decisions. 2. Generate and approve one sample slide. 3. Prepare slide jobs and slide state. 4. Dispatch slide subagents. 5. Record generated slide results. 6. QA, repair, notes, and PPT assembly.

Do not mark a step complete from chat alone; use real files or script-recorded state.

Default Workflow

1. Understand the source content.

• Identify topic, audience, goal, page count, style/brand constraints, and sections to include or exclude.
• If no page count is specified, choose a practical count. Typical decks are 8-12 slides.

2. Plan the deck outline.

• Before writing or updating outline.md, read docs/workflow-gates-and-progress.md and docs/outline-style-and-sample.md.
• Draft slide roles and required source images. Ask for confirmation, then stop before style, backend, sample, or downstream artifacts until approved.

3. Confirm a unified visual style.

• Before offering style options or using files from references/, read docs/outline-style-and-sample.md.
• Offer 2-3 concrete style directions, recommend one, wait for confirmation, then keep one visual identity while varying layouts by page role.

4. Confirm the image backend.

• Before generating any slide image, read docs/backend-selection.md.
• Check whether a built-in image tool is callable, state what you checked, name the backend, explain fallback status, and wait for confirmation.
• If CLI/API fallback is selected, read docs/cli-api-fallback.md. Read docs/image-model-configuration.md only after config errors or explicit API-setting requests.

5. Generate one sample slide for approval.

• Before generating or approving the sample slide, read docs/outline-style-and-sample.md.
• Generate exactly one representative sample after outline, style, and backend are confirmed. Do not generate the full deck until approved.
• After approval, record sample_generation_method in deck_spec.json so jobs and subagents inherit the same path.

6. Create the project directory.

• Before initializing folders or assembling files, read docs/project-assembly-and-reporting.md.
• If no destination is specified, use the current working directory or the source file directory.

7. Prepare user-supplied assets.

• Before using paper figures, charts, screenshots, logos, or other required assets, read docs/user-supplied-assets.md.
• Treat required assets as strict inputs and confirm slide-to-asset mapping before generation.

8. Generate all slide images.

• Before full-deck image generation, read docs/slide-generation-and-subagents.md.
• Create per-slide jobs with scripts/prepare_slide_prompts.py or saved prompts/slide_XX.json files.
• Every final image must come from the selected backend and be recorded with bundled state scripts.

9. Dispatch slide subagents.

• Before dispatching or replacing slide workers, read docs/slide-generation-and-subagents.md and prompts/slide-worker.md.
• Use one subagent per remaining slide job whenever possible. If required subagents cannot be spawned, stop and report a blocker unless the user changes the workflow.

10. Quality check and repair.

• Before QA or assembly, read docs/project-assembly-and-reporting.md.
• Inspect every slide before assembly: text, outline match, truncation, style, unwanted page numbers, overlaps, and required assets.
• Regenerate severe failures with a tighter prompt. Use backend editing for localized issues when available.
• For CLI/API fallback edit commands, read docs/cli-api-fallback.md. Replace the final slide only after validating the edited output.

11. Write speaker notes and assemble the PPT.

• Before writing speech.md or running assembly, read docs/project-assembly-and-reporting.md.
• Make sure outline.md reflects the final confirmed deck outline. Use speech.md headings that map to Slide N.
• Before assembly, ensure slide_jobs.json shows generated slides as recorded and approved samples as accepted. If any slide is pending, dispatched, or blocked, stop.

12. Report the result.

• Use the final report checklist in docs/project-assembly-and-reporting.md.
• Include paths, slide count, backend used, recorded-result status, and any limitations or blockers.

13. Save reusable styles when requested.

• If asked to save the current deck style or a supplied image/PDF/PPT/PPTX style, read docs/style-library.md.

Subagent Dispatch

Slide subagents are mandatory after sample approval whenever the runtime can spawn them. The main agent prepares jobs and records state; each worker handles exactly one prompts/slide_XX.json job and returns only selected image path, backend, and QA note.

Use docs/slide-generation-and-subagents.md for dispatch, commands, result recording, blockers, and backend provenance. Use prompts/slide-worker.md as the handoff template.

Subagents must not edit outline.md, deck_spec.json, other slide jobs, origin_image/, speech.md, or the final .pptx. The parent records outputs and assembles.

Acceptance Criteria

• Output is a valid .pptx.
• Each expected final slide image exists under origin_image/slide_XX.png.
• Every final slide image was generated by the confirmed backend and recorded through record_slide_result.py, except an approved sample marked accepted by run state.
• outline.md reflects the approved deck outline.
• speech.md exists when speaker notes are expected, and assembly writes those notes into the PPT.
• slide_jobs.json and slide_run_state.json reflect the final state.
• Required source images are visibly represented, or a blocker is reported.
• If blocked, the final response identifies phase, slide id, evidence path, and unfinished reason; do not call the deck complete.

Reference Map

• docs/workflow-gates-and-progress.md: approval gates, progress, completion evidence.
• docs/backend-selection.md: backend decision rules and confirmation text.
• docs/outline-style-and-sample.md: outline, style, sample rules, prompt examples.
• docs/user-supplied-assets.md: strict handling for required source assets.
• docs/slide-generation-and-subagents.md: jobs, dispatch, result recording, blockers, provenance.
• docs/cli-api-fallback.md: fallback runtime, generation/edit commands, image limits, troubleshooting.
• docs/image-model-configuration.md: API key, base URL, model, .env; read only when config is needed.
• docs/project-assembly-and-reporting.md: project directory, notes, assembly, final report, prompting principles.
• prompts/slide-worker.md: slide subagent handoff template.
• references/*.md: visual style references.

Documentation and Updates

For source, docs, install, config, and examples, see ningzimu/codex-ppt-skill.

Backend Selection

Read this before confirming the image backend or generating the first sample slide.

This skill supports two image backends:

1. Built-in image tool, preferred when available. Example tool names: Codex image_gen; OpenClaw image_generate. 2. Local API/CLI fallback, using scripts/image_gen.py.

Decision Rules

• Before recommending CLI/API fallback, actively check whether the built-in image generation tool is callable in the current environment. Do not infer availability only from the agent name or subscription context.
• Prefer the built-in image tool when available. In Codex, this usually means the built-in image_gen tool. In OpenClaw, this may be image_generate. Resolution, quality, aspect ratio, slide-edit requests, or the user saying "use gpt-image-2" do not require CLI/API fallback.
• In Codex, treat the built-in image tool as the preferred gpt-image-2 path when it is available. If the user has a GPT subscription / Codex environment and asks for gpt-image-2, do not switch to scripts/image_gen.py only to satisfy the model name.
• Use CLI/API fallback only when the built-in tool is unavailable, the built-in tool failed for a required capability, the user explicitly asks for API/CLI or a third-party image API/provider adapter, or the requested capability is unavailable in the built-in tool.
• Do not recommend CLI/API fallback merely because it provides direct --out file paths, easier local file management, local config reuse, batch generation convenience, or simpler automation.
• Before generating the first image, tell the user which tool availability you checked, which backend you plan to use, why fallback is or is not needed, and ask for confirmation. Do not treat being in a specific agent environment as proof that the built-in image tool is available.
• CLI/API fallback loads ~/.codex-ppt-skill/.env automatically. Run the CLI normally; do not manually parse .env or ask for configuration before an error.
• Ask for OPENAI_API_KEY configuration only after you have intentionally selected CLI/API fallback and that fallback reports missing config, after authentication/base URL/model errors, or when the user explicitly wants to change API settings. Do not mention missing OPENAI_API_KEY while the Codex built-in image tool is available. Configure provided values with scripts/codex_ppt_runtime.py config --api-key.

If CLI/API fallback is selected, read cli-api-fallback.md before generating images. For API key, base URL, model, and .env configuration, read image-model-configuration.md only after the fallback CLI reports missing or invalid configuration, or when the user explicitly wants to change those settings.

Confirmation Text

Built-in backend:

我检查到当前环境可调用内置图片生成工具（Codex 通常是 image_gen，OpenClaw 通常是 image_generate），因此准备优先用内置工具生成样张，不切到本地 API/CLI fallback。可以开始生成 1 页样张吗？

CLI/API fallback:

我检查后没有可用的内置图片生成工具，或内置工具缺少本页必需能力，因此准备使用本地 API/CLI fallback 生成样张，读取 ~/.codex-ppt-skill/.env 中的 OPENAI_BASE_URL / CODEX_PPT_IMAGE_MODEL 配置。可以开始生成 1 页样张吗？

Wait for confirmation before generating the sample slide. If the user questions the backend, resolve that before continuing.

CLI/API Fallback

Use this reference only after CLI/API fallback has been selected and confirmed with the user. The main SKILL.md owns the backend decision rules; this document owns fallback commands, runtime setup, image-input limits, editing, transparency, and troubleshooting.

Let {skill_root} mean the directory containing SKILL.md.

Runtime Setup

CLI/API fallback commands use the shared runtime environment. Before running scripts/assemble_ppt.py or fallback image commands, make sure the shared runtime exists. If ~/.codex-ppt-skill/.venv/bin/python is missing, or if importing script dependencies fails, create or refresh the environment:

python3 {skill_root}/scripts/codex_ppt_runtime.py bootstrap

This is an internal setup step for the skill. Do not ask the user to run it unless dependency installation fails and user approval or troubleshooting is required.

The fallback CLI loads ~/.codex-ppt-skill/.env automatically for OPENAI_API_KEY, OPENAI_BASE_URL, and CODEX_PPT_IMAGE_MODEL. Do not manually parse .env. For API key, base URL, model, and config troubleshooting, read image-model-configuration.md only after the fallback CLI reports missing or invalid configuration, when the user explicitly wants to change those settings, or when a real API call reports authentication, permission, base URL, or model availability failure.

Generate One Slide

Basic generation command:

~/.codex-ppt-skill/.venv/bin/python {skill_root}/scripts/image_gen.py generate \
  --model gpt-image-2 \
  --prompt-file {prompt_file} \
  --size 2560x1440 \
  --quality medium \
  --out {base_dir}/{deck_name}/origin_image/slide_01.png

The fallback CLI accepts model names containing gpt-image-, such as gpt-image-2 or openai/gpt-image-2.

When generating from saved prompts/slide_XX.json files, use the job's prompt field only when the job does not require input images:

python3 -c 'import json, pathlib; print(json.loads(pathlib.Path("{base_dir}/{deck_name}/prompts/slide_01.json").read_text())["prompt"])' | \
~/.codex-ppt-skill/.venv/bin/python {skill_root}/scripts/image_gen.py generate \
  --prompt-file - \
  --size 2560x1440 \
  --quality medium \
  --out {base_dir}/{deck_name}/origin_image/slide_01.png

Before using this text-only generate path, inspect the assigned prompts/slide_XX.json. If input_images is non-empty or requires_context_images is true, this command is not sufficient because it does not attach those images. Use a selected backend/path that can pass the required images, such as the built-in image tool with the images visible in context or a CLI/API edit/image-input path that supplies every required source image. If no such path is available, stop and ask the user whether to switch backend. Do not generate a text-only replacement for a strict input asset.

Capabilities And Sizes

The fallback CLI supports:

• generate: create one or more images from a prompt.
• edit: edit one or more existing images, optionally with a mask.

The fallback CLI defaults to 2K 16:9 landscape output, 2560x1440, because it keeps slide text clearer while staying below the gpt-image-2 pixel limit. For 4K landscape slides, use --size 3840x2160 --quality high only when the user asks for 4K, text-heavy slides need sharper output, or the default result is blurry. For portrait assets, use --size 2160x3840 only if the user requests portrait output.

Editing Slides

If a slide is mostly correct but has a localized issue, use the selected backend's edit capability when available. In CLI/API fallback mode:

~/.codex-ppt-skill/.venv/bin/python {skill_root}/scripts/image_gen.py edit \
  --image {slide_path} \
  --prompt {edit_prompt} \
  --out {new_slide_path}

Replace the final slide only after validating the edited output.

Transparent Backgrounds

Transparent-background requests:

• Built-in mode should use a flat chroma-key background and local removal when appropriate.
• CLI/API fallback should also prefer chroma-key generation plus scripts/remove_chroma_key.py for simple opaque subjects.
• gpt-image-2 does not support --background transparent. If the user needs true model-native transparency, ask before switching to --model gpt-image-1.5 --background transparent --output-format png.

Assembly And Doctor

assemble_ppt.py supports 16:9 and 4:3. Use 16:9 unless the user requests otherwise.

Run the API doctor only when troubleshooting fallback API access:

python3 {skill_root}/scripts/codex_ppt_runtime.py doctor --check-api

Image Model Configuration

Use this reference only when the local API/CLI fallback is needed and the runtime config is missing or must be changed.

Do not manually parse .env. The fallback CLI loads the shared config automatically. Run the fallback command first, then use this document only if the CLI reports missing or invalid configuration.

Ask the user to configure or update settings only when:

• The fallback CLI reports missing OPENAI_API_KEY.
• The user explicitly wants to change API key, base URL, or model.
• A real API call fails with authentication, permission, base URL, or model-not-found errors.

When Configuration Is Needed

Configure image API access only for API/CLI fallback image generation.

Typical cases:

• Codex is using a third-party API or OpenAI-compatible proxy for image generation.
• The skill is being used from Claude Code, OpenClaw, Hermes Agent, or another agent without Codex's built-in image tool.

If Codex is being used through a GPT subscription and the built-in image tool is available, do not ask the user to configure gpt-image-2.

Required And Optional Values

• OPENAI_API_KEY is required for real API/CLI fallback calls.
• OPENAI_BASE_URL is optional. When it is unset, the CLI uses the official OpenAI API. When it is set, the CLI uses the configured third-party provider base URL.
• CODEX_PPT_IMAGE_MODEL is optional. The default is gpt-image-2. Use a custom value only when the provider requires one.

Configure provided API settings with scripts/codex_ppt_runtime.py config --api-key. The config command writes ~/.codex-ppt-skill/.env.

Official OpenAI Example

python3 {skill_root}/scripts/codex_ppt_runtime.py config \
  --api-key "your-api-key" \
  --model gpt-image-2

OpenAI-Compatible Provider Example

Use this shape for providers that implement the OpenAI Images API paths used by the fallback CLI.

python3 {skill_root}/scripts/codex_ppt_runtime.py config \
  --api-key "your-provider-api-key" \
  --base-url "https://xxxx.example.com/v1" \
  --model gpt-image-2

This produces the same effective runtime config as:

OPENAI_API_KEY=your-provider-api-key
OPENAI_BASE_URL=https://xxxx.example.com/v1
CODEX_PPT_IMAGE_MODEL=gpt-image-2

For OpenAI-compatible providers, OPENAI_BASE_URL should normally end at the provider's /v1 root. Do not set it to /images/generations, /images/edits, or another terminal endpoint. The fallback CLI appends the image-generation or image-edit path through the OpenAI SDK.

Use the provider's model name only when the provider documents a custom name. Otherwise prefer gpt-image-2.

AtlasCloud Example

For AtlasCloud, set --model to the base model name. The CLI chooses the matching generation or editing model route internally.

python3 {skill_root}/scripts/codex_ppt_runtime.py config \
  --api-key "your-atlascloud-api-key" \
  --base-url "https://api.atlascloud.ai/api/v1/model" \
  --model openai/gpt-image-2

Runtime Config

The config is written to:

~/.codex-ppt-skill/.env

The file is created with mode 0600. It is shared by Codex, Claude Code, OpenClaw, Hermes Agent, and other local agents.

Process environment variables override .env values. A command-line --model overrides CODEX_PPT_IMAGE_MODEL for that single command.

Outline, Style, And Sample

Read this before writing or updating outline.md, offering visual styles, using files from references/, or generating/approving the sample slide.

If the user asks to save a finished deck style or a user-supplied image/PDF/PPT/PPTX style for future reuse, read style-library.md.

Plan The Deck Outline

Create a concise outline.md draft before generating images. For each slide, define:

• Slide number
• Slide title
• 3-5 key points
• Optional visual idea
• Layout role and intent, such as cover, agenda, section divider, concept explanation, process, comparison, timeline, data evidence, architecture, case study, summary, or Q&A
• Required source images, if any, including the image path or attachment name, its role on the slide, and whether it is a strict input asset or only a style/layout reference

Save the draft to {base_dir}/{deck_name}/outline.md once the project directory is known. If the output directory is not known yet, show the outline in chat first and write it to outline.md immediately after creating the project directory.

Show the outline to the user for confirmation and wait for approval before moving to visual style selection or image generation, unless the user explicitly asked you to skip confirmation. If any slide lists required source images, explicitly ask the user to verify that each image is assigned to the correct slide and role before generation. If the user requests changes, update outline.md and ask for confirmation again.

Stop after writing the outline draft. At this point, report the outline.md path, slide count, required source images and their slide mapping, and that no slide images or PPTX have been generated yet. Do not proceed to deck_spec.json, speech.md, prompt preparation, style selection, backend selection, or sample generation until the user approves the outline.

If the user approved a sample slide, record that approved slide_XX.png path as the deck-level style reference. Later slide prompts and subagent handoffs should include it as a style-only reference so each page keeps the same palette, typography mood, density, texture, and visual identity without copying the sample's exact layout.

Recommended structure:

Slide 1: Cover
Slide 2: Context / problem
Slide 3-7: Main argument or sections
Slide 8: Summary / recommendation / closing

For slides that use source images, add lines like:

Slide 5: Experiment Results
- Key points: ...
- Required images:
  - Main evidence figure; strict input asset; preserve data, axes, labels, legends, colors, and values

    ![Result 01](assets/figures/result_01.png)

  - Supporting model architecture; strict input asset; preserve labels and arrows

    ![Model Architecture](assets/figures/model_architecture.png)

Use Markdown image syntax inside the Required images list whenever the asset is local and renderable in the outline. This lets the user visually verify the exact asset mapping during outline review. Keep the descriptive text next to each image so prepare_slide_prompts.py can convert the same asset into structured prompt input later.

Confirm A Unified Visual Style

Before generating slide images, discuss the visual style with the user unless the user has already provided a clear style direction or reference material.

If the user has already specified a style, provided a style image, or provided a PDF/PPT/PPTX to use as style reference, do not force a 2-3 option style selection. Extract the usable style rules, briefly restate them, then proceed to backend confirmation and sample generation.

For PDF/PPT/PPTX style references, do not infer the visual system from document structure, outline text, XML, file metadata, or slide object hierarchy alone. First render or export representative pages/slides into real page images, inspect those rendered images, and derive the style from what is actually visible on the pages. If the file has multiple visual sections, inspect enough representative pages to capture the shared style and any section-specific variations.

When extracting style from reference material, separate content reuse from style reuse. Unless the user explicitly asks to reuse the source content, treat the provided image/PDF/PPT/PPTX as a style reference only.

If the user has not provided a clear style, prefer a multiple-choice question: offer 2-3 concrete style directions and mark one as your recommendation. Each style option should briefly specify:

• Color palette
• Layout system
• Typography direction
• Illustration or image treatment
• Decorative elements
• Density and whitespace rules

After the user chooses a style, create one final style direction and keep the visual identity consistent across all slide prompts. Keep color palette, typography, texture, icon/illustration language, and overall mood stable. Do not reuse the same layout on every page.

The references/ directory contains optional style references. Use them as inspiration, not as rigid templates. Adapt the style to the topic and audience.

Important: a deck should have one coherent visual identity, not one repeated composition. Treat each reference as a style system: stable palette, typography, icon language, texture, and visual mood; variable page layout chosen from the slide's content role. layout_blueprints are candidate starting points only. Do not apply the same blueprint to every slide.

Available references:

• references/清爽专业风.md
• references/创意杂志风.md
• references/电子墨水杂志风.md
• references/数据仪表盘风.md
• references/科研答辩风.md
• references/复古扁平插画风.md
• references/手绘技术解释风.md
• references/手绘白板风.md
• references/温暖手工风.md
• references/麦肯锡风格.md

When adding a reusable style to the library, also add its references/{style_name}.md file to this list.

Example style confirmation:

我建议用 A，因为它最适合这份内容的受众和表达目标。

A. 清爽专业风（推荐）：浅色背景、蓝绿强调色、结构清晰，适合汇报、答辩和技术分享。
B. 创意杂志风：大标题、强图片、留白更大胆，适合分享和传播。
C. 数据仪表盘风：指标卡、图表感布局，适合数据密集型报告。

你选哪个？也可以指定要调整的配色、布局或插画方向，或者上传一张喜欢的 PPT 风格图片让我参考。

Generate One Sample Slide For Approval

After the outline, style, and image backend are confirmed, generate exactly one sample slide image before full production.

Sample slide requirements:

• Use the confirmed style description.
• Prefer a representative content slide over the cover when possible.
• Demonstrate the intended deck rhythm: the sample should show how the chosen style adapts to a real content page, not just a generic fixed template.
• Save it directly as the intended final slide filename, such as {base_dir}/{deck_name}/origin_image/slide_08.png. In CLI/API fallback mode, use scripts/image_gen.py generate --out for that exact path.
• Show the sample image to the user.
• Ask the user to confirm the visual style, typography, layout density, and Chinese text quality.

Do not generate the full deck until the user approves the sample slide. If the user requests changes, revise the style description and regenerate that same slide_XX.png file first. Once approved, keep that file as the final slide for its page. Do not create sample_slide.png in origin_image/, because the assembly step is designed around final slide_XX filenames.

After the sample slide is approved, record the sample generation method in deck_spec.json before preparing full-deck jobs. This is the contract the parent passes to subagents so they use the same image-generation path as the sample, not a cheaper local rendering path. Include at least:

• backend_used: the confirmed backend label, such as built-in image tool or scripts/image_gen.py.
• tool_name: the actual tool or command used, such as image_gen, image_generate, or scripts/image_gen.py.
• mode: generate or edit.
• prompt_source: where the approved sample prompt came from.
• size, quality, and model/config details when the backend exposes them.
• approved_sample_path: the approved origin_image/slide_XX.png path.
• input_context_preparation: how local source/style images were made available, such as view_image for built-in mode.
• handoff_rule: subagents must use the same backend/tool/mode and return a blocker if that path is unavailable.

Project Assembly And Reporting

Read this before initializing the project directory, writing speaker notes, assembling the PPT, or sending the final report.

Project Directory

Use this output structure:

{base_dir}/{deck_name}/
├── origin_image/
│   ├── slide_01.png
│   ├── slide_02.png
│   └── ...
├── prompts/
│   ├── slide_01.json
│   └── ...
├── slide_jobs.json
├── slide_run_state.json
├── deck_spec.json
├── outline.md
├── speech.md
└── {deck_name}.pptx

If the user did not specify a destination, use the current working directory or the directory that contains the source file.

You may initialize the directory structure with:

~/.codex-ppt-skill/.venv/bin/python {skill_root}/scripts/assemble_ppt.py {base_dir} {deck_name}.pptx --init

Quality Check And Repair

Before assembling the PPT, inspect every slide image. Check:

• Text is readable and not garbled.
• Slide content matches the outline.
• Title and key points are not truncated.
• Visual style is consistent across slides.
• No page number appears unless the user requested one.
• Important elements do not overlap.

If a slide has severe text or layout issues, regenerate it with a more constrained prompt. If a slide is mostly correct but has a localized issue, use the selected backend's edit capability when available. In CLI/API fallback mode, use scripts/image_gen.py edit --image {slide_path} --prompt ... --out {new_slide_path} and replace the final slide only after validating the edited output.

Speaker Notes

Make sure outline.md reflects the final confirmed deck outline. Do not recreate it from scratch here.

Create speech.md as presenter notes that a speaker can use directly. Do not write a brief summary of visible slide text. Write in the presentation language; for Chinese decks, speaker notes should be in Chinese.

For each slide, keep the spoken script and presenter cues separate:

• The talk track appears directly under the slide heading, without an extra label. It is the script the presenter can read or closely follow. It should connect the slide to the deck's main story, explain the point the audience should take away, and include a natural transition at the end when useful.
• 注意点： is not meant to be read aloud. Use it for emphasis, pacing, visual reading order, caveats, examples, source reminders, or audience interaction prompts.

Separate these two sections with a standalone --- line, so the presenter can quickly distinguish the readable script from the cue list.

Before writing the slide notes, choose a delivery style based on the deck content, audience, and purpose. The delivery style is not a label added after writing; it should shape the actual talk track, including how direct the claim is, how much background is explained, which examples are used, how quickly the speaker moves, and how transitions are phrased.

Common delivery styles:

• Technical explainer: patient, definition-first, example-driven, with careful visual walkthroughs.
• Research or paper reading: evidence-led, method/result/limitation oriented, with clear claims about what the audience should learn from each figure.
• Product or pitch deck: outcome-first, persuasive, focused on user pain, value, proof, and the next action.
• Training or workshop: step-by-step, checkpoint-driven, with small prompts for audience reflection or practice.
• Executive report: conclusion-first, concise, focused on decisions, risks, tradeoffs, and recommended actions.

Keep one deck-level delivery style consistent, but adapt the tone by slide role. For example, an opening slide can be more framing-oriented, a dense diagram slide can slow down for explanation, and a closing slide can become more action-oriented.

Length guidance:

• Title, agenda, and section-divider slides can be 1-2 short paragraphs.
• Normal content slides should usually be 2-5 short paragraphs, or roughly 150-400 Chinese characters for Chinese decks.
• Dense concept, architecture, data, or paper-explanation slides may need more, but split long material if the audience would lose the thread.

Use basic presentation craft in the talk track:

• Lead with the claim before the details.
• Explain visuals in the order the audience should look at them.
• Add examples, contrast, caveats, and "so what" implications instead of rereading the slide.
• Close with a natural bridge to the next slide when useful.

Write the talk track from the presenter's point of view, facing the audience. Avoid generic AI-style phrasing, canned summaries, and phrases that sound detached from the actual talk. The script should sound like a person explaining this specific deck in the room:

• Use natural first-person or speaker-facing phrasing when appropriate, such as "这里我想强调的是..." or "我们先看左边这个结构...".
• Ground each paragraph in the current slide's content and the surrounding deck narrative.
• Prefer concrete explanations, examples, and audience-oriented transitions over broad filler like "本页主要介绍了..." or "综上所述...".
• Do not mention that the notes were generated, inferred, or prepared by an AI.

Use 注意点： for short cues such as:

• 重点： the one or two ideas the presenter must emphasize.
• 画面引导： where the audience should look first, second, and last.
• 节奏： where to slow down, pause, or ask a question.
• 补充： caveats, examples, source details, or context that should stay out of the spoken script unless needed.

Use headings that the assembly script can map back to slide numbers:

## Slide 1: {Title}

{Presenter talk track for slide 1. For Chinese decks, write this in Chinese. Include an optional transition sentence at the end when useful.}

---

注意点：
- 重点：{Key point the presenter should emphasize}
- 画面引导：{How to guide the audience through the visual}
- 节奏：{Where to slow down, pause, or ask a question}
- 补充：{Caveat, example, source detail, or audience takeaway}

## Slide 2: {Title}

{Presenter talk track for slide 2}

---

注意点：
- 重点：{Key point for slide 2}

Assembly

Before running scripts/assemble_ppt.py or the CLI/API fallback scripts, make sure the shared runtime exists. If ~/.codex-ppt-skill/.venv/bin/python is missing, or if importing script dependencies fails, create or refresh the environment:

python3 {skill_root}/scripts/codex_ppt_runtime.py bootstrap

This is an internal setup step for the skill. Do not ask the user to run these commands unless dependency installation fails and user approval or troubleshooting is required.

Run:

~/.codex-ppt-skill/.venv/bin/python {skill_root}/scripts/assemble_ppt.py {base_dir} {deck_name}.pptx --aspect-ratio 16:9

Important:

• {base_dir} is the parent directory of {deck_name}/.
• {deck_name}.pptx must match the project folder name.
• The script reads images from {base_dir}/{deck_name}/origin_image/.
• The script only reads final images named like slide_01.png, slide_02.png, etc.; drafts and sample files are ignored.
• Before running assembly, slide_jobs.json should show every generated slide as recorded and every approved sample slide as accepted. If any slide is pending, dispatched, or blocked, stop and report that state.
• If {base_dir}/{deck_name}/speech.md exists and uses Slide N headings, the script writes those notes into the corresponding PPT speaker notes.
• The script writes {base_dir}/{deck_name}/{deck_name}.pptx.

assemble_ppt.py supports 16:9 and 4:3. Use 16:9 unless the user requests otherwise. image_gen.py loads ~/.codex-ppt-skill/.env automatically for OPENAI_API_KEY, OPENAI_BASE_URL, and CODEX_PPT_IMAGE_MODEL. Run python3 {skill_root}/scripts/codex_ppt_runtime.py doctor --check-api when troubleshooting API access.

Final Report

Report:

• Project directory
• PPT file path
• Slide image directory
• outline.md path
• speech.md path
• slide_jobs.json path
• Number of slides
• Confirm which image backend was used and that every non-sample slide result was recorded with record_slide_result.py.
• Confirm that speaker notes from speech.md were written into the PPT, if applicable
• Any slides that were regenerated, blocked, or still have known limitations

Prompting Principles

• Keep one global visual style fixed across the deck.
• Vary slide composition by page role; style consistency does not mean repeating the same layout.
• Use layout_blueprints as candidate patterns, not mandatory templates.
• Generate one slide per image request.
• Prefer concrete visual direction over generic words like "beautiful" or "professional".
• For dense content, split across more slides instead of crowding one slide.
• Prioritize clarity over decoration.

Slide Generation And Subagents

Read this before full-deck image generation, preparing slide jobs, dispatching subagents, recording results, or handling blockers.

Final Slide Image Generation

Generate one image per slide with the selected image backend. Every final slide_XX.png must be produced by the built-in image tool or by scripts/image_gen.py; programmatic rendering or hybrid text overlay is not acceptable for slide image creation.

After the outline, visual style, image backend, and sample slide have all been approved, create final downstream artifacts if they do not already exist:

• deck_spec.json
• prompts/slide_XX.json
• speech.md

Do not create these final downstream artifacts before outline approval. If the user explicitly asks for pre-approval planning files, use .draft. filenames and synchronize them after approval.

deck_spec.json must include sample_generation_method copied from the approved sample before prepare_slide_prompts.py is run. The helper copies that method into each prompts/slide_XX.json and into slide_jobs.json, so workers can see the exact backend, tool, mode, image context preparation, and output constraints used for the approved sample.

Before full production, create structured per-slide image jobs. Prefer the bundled deterministic helper:

~/.codex-ppt-skill/.venv/bin/python {skill_root}/scripts/prepare_slide_prompts.py \
  --spec {base_dir}/{deck_name}/deck_spec.json \
  --out-dir {base_dir}/{deck_name} \
  --selected-backend "<confirmed backend label>" \
  --force

The helper writes:

{base_dir}/{deck_name}/
├── prompts/
│   ├── slide_01.json
│   ├── slide_02.json
│   └── ...
├── slide_jobs.json
└── slide_run_state.json

Each prompts/slide_XX.json is a self-contained slide job. It includes the slide number, title, output filename, input image list, whether context images are required, and the full prompt text. Use these JSON job files for built-in image generation, CLI/API fallback coordination, and subagent handoff. Do not create a separate job manifest unless the user explicitly asks for one.

The parent agent is responsible for packaging context before dispatch. A slide subagent only sees its assigned single-slide job, the images explicitly passed to it, and the handoff text. Do not assume the subagent knows the source article, full outline, previous slides, later slides, or any concept held only in the parent agent's conversation context.

For any slide that depends on cross-slide or source-wide meaning, write the necessary background directly into deck_spec.json before preparing prompts:

• Use deck-level deck_context for canonical concepts that multiple slides may need, such as the source summary, core claim, term list, taxonomy, characters, definitions, chronology, or required naming.
• Use slide-level local_context for page-specific facts that must be visible to that one worker, such as "summarize these six traits", "compare these two methods", "continue this three-step framework", or "use this exact quote".
• Expand references like "the six traits", "the above framework", "the previous conclusion", or "these examples" into explicit lists or definitions inside deck_context or local_context. Avoid leaving them as implicit pointers.

The goal is not to make subagents validate missing context. The goal is for the parent agent to hand each worker a complete enough task packet so the worker can simply execute the assigned page.

slide_jobs.json is the dispatch state file. It records each slide's prompt job, final output path, status, selected backend, sample generation method, subagent dispatch metadata, result provenance, and blocker state. Do not hand-edit slide statuses; use the bundled status scripts.

deck_spec.json may express required_images either as structured objects or as Markdown image reference strings. The helper extracts the image path from strings such as strict input asset\n\n![Result 01](assets/figures/result_01.png) and carries the surrounding text / alt text into the image role.

Use a structured visual brief for each slide. Image generation works best when the prompt separates canvas, style, layout, text, visual elements, and constraints instead of relying only on a long style paragraph.

Keep the deck visually coherent but vary slide layouts according to page semantics. Treat style references and layout_blueprints as candidate patterns, not fixed templates. Across a normal deck, deliberately mix suitable page types such as:

• cover / section divider
• context or problem framing
• process or timeline
• comparison or tradeoff
• data / evidence / KPI
• architecture or workflow diagram
• summary / conclusion / next steps

Avoid generating every slide as the same three-card layout. For each slide, choose a layout that fits its content and explain that choice in the layout.intent field.

{
  "type": "16:9 full-slide PowerPoint image",
  "language": "Chinese",
  "canvas": {
    "aspect_ratio": "16:9",
    "use_full_canvas": true,
    "slide_number": "do not render a slide number"
  },
  "style": {
    "name": "{confirmed style name}",
    "visual_direction": "{same final style description for every slide}",
    "color_palette": "{main colors and accent colors}",
    "typography": "{font personality, hierarchy, weight, text alignment}",
    "texture_and_finish": "{flat, paper, dashboard, editorial, whiteboard, etc.}",
    "deck_consistency": "same palette, typography, icon language, texture, and mood across all slides"
  },
  "deck_context": {
    "source_summary": "{brief source-wide summary}",
    "core_claim": "{the deck's central thesis}",
    "canonical_terms": ["{term 1}", "{term 2}", "{term 3}"]
  },
  "layout": {
    "role": "{cover, agenda, section divider, concept, process, comparison, timeline, data evidence, architecture, case study, summary, Q&A, etc.}",
    "intent": "{why this page uses this layout: cover, comparison, timeline, data evidence, workflow, summary, etc.}",
    "composition": "{specific layout for this slide}",
    "content_zones": "{title zone, body zone, visual zone, footer or callout zones}",
    "variation_rule": "same style identity as the deck, but vary composition by slide role; do not repeat the same blueprint on adjacent slides unless the content is part of a deliberate repeated sequence",
    "relationship_to_previous_slide": "{new layout, continuation layout, mirrored layout, or deliberate repeated sequence}",
    "spacing": "clear hierarchy, coherent alignment, no overlapping elements"
  },
  "text": {
    "title": "{slide title}",
    "key_points": ["{point 1}", "{point 2}", "{point 3}"],
    "text_quality": "render all Chinese text exactly, clearly, and without garbled characters"
  },
  "local_context": {
    "required_background": "{facts, lists, definitions, comparisons, or prior-slide references this slide needs to be self-contained}"
  },
  "visual_elements": {
    "main_visual": "{icons, diagram, chart, illustration, dashboard cards, collage, or other content-specific visual idea}",
    "supporting_elements": "{arrows, cards, callouts, decorative elements, labels}"
  },
  "constraints": [
    "The final image itself must contain the title and key points.",
    "All text must be readable and correctly spelled.",
    "Keep the confirmed style consistent with the rest of the deck.",
    "No watermark, no unrelated logo, no extra slide number."
  ]
}

If preparing prompts manually instead of using prepare_slide_prompts.py, still save each full slide job under {base_dir}/{deck_name}/prompts/slide_XX.json before generation. The saved job must include prompt, out, and input_images, including any deck-level approved sample slide style reference and all slide-level source images with explicit role labels.

Parallel Slide Generation With Subagents

After the user approves the sample slide and full-deck generation is authorized, slide subagents are mandatory whenever the current runtime can spawn them. Use one subagent per remaining slide image job. Do not generate the remaining deck sequentially merely for convenience. If subagents cannot be spawned, stop at the dispatch step and report a blocker instead of producing a lower-quality sequential deck.

Use the slide state scripts as the dispatch contract: the main agent spawns workers, then records dispatch and result state. A slide is not considered dispatched or complete until the relevant script records it.

Parent agent responsibilities:

• Own outline.md, deck_spec.json, prompts/, origin_image/, QA, speech.md, and final PPT assembly.
• Run prepare_slide_prompts.py or otherwise write full per-slide JSON jobs and slide_jobs.json before delegation.
• Run slide_job_status.py to see dispatch slots and pending slide ids before each batch.
• Ensure the approved sample slide is included in every non-sample job as a style-only input image when available.
• Ensure every dispatched slide job is self-contained. If a slide summarizes, compares, continues, or refers to deck-wide concepts, put the required concepts into deck_context or the slide's local_context before running prepare_slide_prompts.py.
• Ensure sample_generation_method is present in deck_spec.json, every prompts/slide_XX.json, and slide_jobs.json; it must describe the exact backend/tool/mode used to generate the approved sample.
• If the approved sample slide already exists and should not be regenerated, mark that slide in deck_spec.json with sample_approved: true or approved_sample: true before running prepare_slide_prompts.py; the helper records it as accepted when the final image file exists.
• In built-in image_gen mode, ensure every slide-level required local source image has already been inspected with view_image before any delegated job that depends on it.
• In CLI/API fallback mode, ensure each JSON job lists the required source images and that the selected CLI path can use them; if the CLI path cannot attach input images for a slide, do not delegate that slide as a text-only replacement for the asset.
• Spawn subagents with exactly one slide job each, up to dispatch_slots_available.
• Immediately after each successful spawn, run record_slide_dispatch.py with the real agent id and prompt path.
• After each worker returns, visually check its selected output, then run record_slide_result.py to copy the selected generated image into origin_image/slide_XX.png and record backend provenance.
• If a worker cannot use the selected image backend or cannot access required input images, run record_slide_blocker.py and report the blocker.

Subagent responsibilities:

• Read exactly the assigned prompts/slide_XX.json.
• Use the selected image backend only; do not switch between built-in image generation and CLI/API fallback.
• Follow the sample_generation_method from the assigned job. Use the same tool family, generation/edit mode, image context preparation, and model/config details that produced the approved sample.
• Generate the final slide candidate by calling the selected image generation backend. Do not create final slide images with local drawing, HTML/SVG/canvas screenshots, Pillow, python-pptx/PptxGenJS layouts, or manually composited text/image overlays.
• Treat the approved sample slide as style reference only.
• Treat any required source images as strict input assets and preserve their content according to the prompt.
• Inspect the generated candidate for text quality, style consistency, required-image inclusion, and layout issues before returning it.
• Return only the selected original generated image path, the backend used, and a one-sentence QA note.

Subagents must not edit outline.md, deck_spec.json, other slide job files, origin_image/, speech.md, or the final .pptx. The parent agent alone records selected outputs and performs final assembly.

Do not continue sequentially after the sample if subagents are part of the confirmed full-generation workflow and cannot be used. Stop and report the blocker, unless the user explicitly changes the requirement.

Dispatch loop:

~/.codex-ppt-skill/.venv/bin/python {skill_root}/scripts/slide_job_status.py \
  {base_dir}/{deck_name}

~/.codex-ppt-skill/.venv/bin/python {skill_root}/scripts/record_slide_dispatch.py \
  {base_dir}/{deck_name} \
  --slide slide_02 \
  --agent-id <agent id> \
  --agent-nickname "<nickname if available>" \
  --prompt-file prompts/slide_02.json

Result recording:

~/.codex-ppt-skill/.venv/bin/python {skill_root}/scripts/record_slide_result.py \
  {base_dir}/{deck_name} \
  --slide slide_02 \
  --agent-id <agent id> \
  --backend-used "built-in image tool" \
  --selected-source /absolute/path/to/generated/slide_02.png \
  --qa-note "Text readable; style matches the approved sample."

Blocker recording:

~/.codex-ppt-skill/.venv/bin/python {skill_root}/scripts/record_slide_blocker.py \
  {base_dir}/{deck_name} \
  --slide slide_02 \
  --agent-id <agent id> \
  --reason "selected image backend unavailable in worker"

Subagent handoff template lives in ../prompts/slide-worker.md. Use that template instead of writing a new ad hoc worker prompt.

Save images as:

{base_dir}/{deck_name}/origin_image/slide_01.png
{base_dir}/{deck_name}/origin_image/slide_02.png
...

After each image is generated, the parent agent should record it with record_slide_result.py, which copies it into {base_dir}/{deck_name}/origin_image/ and rejects backend provenance that does not match the selected backend or sample generation method. Do not leave final slide images only in a temporary or default generated-images directory, and do not manually mark slide state complete.

In CLI/API fallback mode, read cli-api-fallback.md for text-only generation commands, image-input limitations, edit commands, transparency rules, and runtime troubleshooting.

Final slide image naming rules:

• Rename final slide images strictly by slide order: slide_01.png, slide_02.png, slide_03.png, ...
• Use zero-padded two-digit numbers for normal decks.
• The approved sample slide should already have the correct slide_XX.png filename and should be reused directly.
• Keep rejected variants, drafts, or reference images out of origin_image/. If you need to preserve them, place them in the project root or a separate drafts/ directory.
• Before assembling, verify every expected slide_XX.png exists in origin_image/, there are no missing or extra final slide images, and slide_job_status.py shows all non-sample slide jobs as recorded.

For Chinese decks, explicitly ask the image backend to render Chinese text accurately and avoid garbled characters.

Style Library

Read this when the user asks to save a finished deck style, a sample-slide style, or a user-supplied image/PDF/PPT/PPTX style into the reusable style library.

The goal is to save a reusable visual system, not the current deck's private content.

When To Use

Use this workflow when the user says things like:

• Save this style.
• Add this PPT style to the style library.
• Let future decks use this style.
• Turn this image/PDF/PPT/PPTX style into a built-in reference.
• Save the style from the finished deck.

If the user only wants to use a style once, extract a temporary style description for the current deck instead of writing a new references/ file.

Inspect The Visual Source

Use the actual visible pages as the source of truth.

• For a finished codex-ppt deck, inspect the final origin_image/slide_XX.png files or exported slide page images.
• For a sample slide, inspect the approved sample image.
• For user-provided image references, inspect the image itself.
• For PDF/PPT/PPTX references, first render or export representative pages/slides into real page images, then inspect those images. Do not infer the style from file structure, text, XML, metadata, or object hierarchy alone.

Inspect enough pages to capture the style system. Prefer at least one cover or opener, one ordinary content slide, one diagram/process/data slide when available, and one closing or summary slide. If the deck has obvious section-specific variants, record those variants inside the style file.

Extract The Style System

Extract reusable visual rules:

• style_name: short reusable name.
• best_for: suitable scenarios and audiences.
• visual_direction: one concise description of the style identity.
• canvas: aspect ratio, background, composition, density, whitespace.
• color_palette: primary, secondary, accent, neutral colors, plus usage rules.
• typography: title, body, labels, hierarchy, alignment, text quality rules.
• layout_patterns: recurring page types and composition patterns.
• layout_usage_rule: how to vary layouts while keeping the same identity.
• layout_blueprints: 2-4 reusable composition blueprints, described semantically rather than copied from one slide.
• visual_elements: allowed and avoided icons, diagrams, cards, textures, decorations, photos, charts.
• image_treatment: how photos, screenshots, charts, or illustrations are handled.
• rendering_constraints: rules the image model should follow.

Do not save private or one-off content as style:

• Do not save the user's original article text, business data, personal information, customer names, private project names, paper results, exact quotes, or slide copy.
• Do not save source images or screenshots as required dependencies of the style file.
• Do not preserve identifiable logos or brand names unless the user explicitly asks for a reusable brand style.
• Do not make the style depend on files outside references/.

Name The Style

Name the file:

references/{style_name}.md

Naming rules:

• Prefer a short Chinese style name, usually 2-8 Chinese characters or a concise Chinese phrase.
• Name the reusable visual style, not the project, client, paper, or event.
• Avoid personal names, company names, customer names, paper titles, or temporary task names.
• Avoid vague names like 我的风格1, 好看风, or 新风格.
• Good examples: 深色数据科技风, 极简发布会风, 柔和学术插画风, 高密度咨询风.

If the target filename already exists, ask whether to overwrite, merge, or choose a new name.

Write The Style File

Match the existing references/*.md structure:

{style_name}

适用场景:

• ...
• ...

GPT-Image-2 风格 Brief:

    {
      "type": "16:9 full-slide PowerPoint image",
      "style_name": "{style_name}",
      "best_for": "...",
      "visual_direction": "...",
      "canvas": {
        "aspect_ratio": "16:9",
        "background": "...",
        "composition": "...",
        "density": "..."
      },
      "color_palette": {
        "primary": "...",
        "secondary": "...",
        "accent": "...",
        "neutral": "...",
        "rule": "..."
      },
      "typography": {
        "title": "...",
        "body": "...",
        "labels": "...",
        "text_quality": "..."
      },
      "layout_patterns": [
        "...",
        "..."
      ],
      "layout_usage_rule": "...",
      "layout_blueprints": [
        {
          "name": "...",
          "sections": [
            {"position": "...", "count": 1, "labels": ["..."]}
          ]
        }
      ],
      "visual_elements": {
        "allowed": "...",
        "avoid": "..."
      },
      "image_treatment": {
        "photos": "...",
        "screenshots": "...",
        "charts": "...",
        "illustrations": "..."
      },
      "rendering_constraints": [
        "...",
        "..."
      ]
    }

The JSON should be directly reusable as a slide generation style brief. Keep it descriptive enough for future agents, but avoid embedding task-specific content.

Make The Style Discoverable

After writing references/{style_name}.md, update docs/outline-style-and-sample.md.

Add the new file to the Available references list:

- `references/{style_name}.md`

That list is what future style confirmation steps read before offering or using reusable style references.

Final Response

Report:

• The new style name.
• The saved references/{style_name}.md path.
• That docs/outline-style-and-sample.md was updated.
• A one-sentence note on how to request it later, for example: "以后可以说：用「深色数据科技风」生成这份 PPT。"

User-Supplied Assets

Read this before using paper figures, experiment result charts, screenshots, logos, or other assets that must appear in the deck.

When the user provides paper figures, experiment result charts, screenshots, logos, or other assets that must appear in the deck, treat them as source assets, not as loose visual inspiration.

Recommended project-local asset location:

{base_dir}/{deck_name}/assets/
├── figures/
│   ├── result_01.png
│   └── result_02.png
└── logos/
    └── lab_logo.png

Do not place source assets in origin_image/; that directory is only for final slide_XX.png images.

For slides that must include a user-supplied figure:

• Record the exact asset path or attachment name in outline.md for that slide, preferably as a Markdown image reference inside that slide's Required images list, then ask the user to confirm the mapping before generation.
• Stay on the already selected image backend. Do not switch between built-in image generation and CLI/API fallback only because a slide includes source images.
• Use the selected backend's reference-image or edit capability when available, with the supplied figure visible as an input image.
• In built-in image_gen mode, every source image must be visible in the conversation context before generating any slide that depends on it. User attachments and images generated earlier in the thread already qualify. For local image paths, inspect each required image with view_image first, then generate or edit the slide.
• In built-in image_gen mode, view_image is the required way to make local image paths visible to the conversation before generation. It is not a filename parameter to image_gen; the generation prompt must still label the visible image by role, such as Image 1: strict input asset or Image 2: approved sample slide style reference.
• Ask the model to preserve the supplied figure's data, labels, axes, colors, and visual content, and only compose the surrounding slide layout, title, captions, callouts, and background.
• Do not ask the model to "redraw", "recreate", "imagine", or "generate a similar chart" for result figures unless the user explicitly wants a stylized redraw.
• After generation, inspect the output and ask the user to pay special attention to whether required figures were used correctly.

Example prompt fragment for a result-figure slide:

{
  "source_assets": [
    {
      "path": "{base_dir}/{deck_name}/assets/figures/result_01.png",
      "usage": "embed as the main evidence figure",
      "fidelity": "preserve the figure content; do not redraw or change data, axes, labels, colors, curves, bars, or legends"
    }
  ],
  "visual_elements": {
    "main_visual": "place the supplied result_01.png as a large figure panel, with a short caption and two callouts around it"
  },
  "constraints": [
    "Use the provided figure as an input image, not as a loose style reference.",
    "Do not synthesize a replacement chart.",
    "Keep all numerical values and labels in the supplied figure unchanged."
  ]
}

Workflow Gates And Progress

Read this before creating downstream artifacts, advancing between phases, or reporting progress.

Mandatory Phase Gates

This workflow has explicit approval gates. Do not advance to a later phase until the previous phase has been approved by the user, unless the user explicitly asks to skip that confirmation.

Phase order:

1. Source reading and asset extraction 2. Outline confirmation 3. Visual style confirmation 4. Image backend confirmation 5. One sample slide approval 6. Full slide generation 7. QA, speaker notes finalization, and PPT assembly

Hard rules:

• Before outline approval, do not create final deck_spec.json, speech.md, prompt job files, slide images, or .pptx files.
• If you need an internal planning artifact before approval, name it with .draft. such as deck_spec.draft.json or speech.draft.md, and clearly report that it is not final.
• Downstream artifacts (deck_spec.json, prompts/, slide_jobs.json, speech.md, final slide images, and .pptx) should be created only after the relevant gates have been approved.
• If the deck uses required source images, stop at outline confirmation and ask the user to verify the slide-to-image mapping before style selection or image generation.

Visible Progress Plan

For non-trivial decks, keep a user-visible checklist with one active step:

1. Prepare source, outline, style, and backend decisions. 2. Generate and approve one sample slide. 3. Prepare slide jobs and slide state. 4. Dispatch slide subagents. 5. Record generated slide results. 6. QA, repair, notes, and PPT assembly.

Completion evidence:

• Prepare source, outline, style, and backend decisions: outline.md is approved and image backend is confirmed.
• Generate and approve one sample slide: one final origin_image/slide_XX.png is approved as the style reference.
• Prepare slide jobs and slide state: prompts/slide_XX.json, slide_jobs.json, and slide_run_state.json exist.
• Dispatch slide subagents: slide_job_status.py shows dispatchable slides and each spawned worker is recorded by record_slide_dispatch.py.
• Record generated slide results: each worker output is recorded by record_slide_result.py, which copies the selected image into origin_image/slide_XX.png and records backend provenance.
• QA, repair, notes, and PPT assembly: every expected final image exists, QA is complete, speech.md is final, and {deck_name}.pptx exists.

Do not mark a step complete just because the chat says it is complete; use real files or script-recorded state.

Slide Worker Prompt

Use this template when dispatching a slide subagent after the sample slide is approved and full-deck generation is authorized.

Generate slide <N> for this codex-ppt deck.

Deck dir: <absolute deck dir>
Slide job file: <absolute deck dir>/prompts/slide_<NN>.json
Output target owned by parent: <absolute deck dir>/origin_image/slide_<NN>.png
Selected image backend: <built-in image tool OR CLI/API fallback>
Sample generation method copied from the approved sample:
- backend_used: <exact backend label recorded by parent>
- tool_name: <image_gen OR image_generate OR scripts/image_gen.py>
- mode: <generate OR edit>
- model/config: <model, size, quality, or "built-in default" if not exposed>
- prompt_source: <approved sample prompt source>
- input_context_preparation: <how local images were made visible or attached>
- approved_sample_path: <absolute path to approved origin_image/slide_XX.png>
- handoff_rule: use this same backend/tool/mode; return a blocker if unavailable
Input images already prepared by the parent:
- <absolute path> - approved sample slide style reference; match style only, do not copy layout
- <absolute path> - strict input asset; preserve labels/data/arrows/content

Read the JSON job file, then follow its `prompt` field exactly. Use the selected image backend and the recorded sample generation method only.
You must produce the final slide candidate by calling the selected image generation backend:
- Built-in mode: use the built-in image generation/editing tool.
- CLI/API fallback mode: use `scripts/image_gen.py` with the saved job prompt and required image inputs.

Forbidden for final slide image creation:
- local drawing or rendering scripts
- Pillow-generated slides
- SVG, HTML/CSS, or canvas screenshots
- python-pptx/PptxGenJS/native PPT layout screenshots
- manually composited text, card, chart, or image overlays

If you cannot use the selected image backend, stop and return `blocker=<reason>` instead of creating a lower-quality replacement.
If you cannot follow the recorded sample generation method, stop and return `blocker=<reason>` instead of switching tools.
Do not edit slide job files, origin_image, speech.md, or assemble the PPT.

Before returning, visually check:
- Chinese text is readable and not garbled
- style matches the approved sample slide
- required source images are visibly included and not replaced by a similar redraw
- no overlapping or truncated important content

Return only:
backend_used=<built-in image tool OR scripts/image_gen.py>
selected_source=/absolute/path/to/$CODEX_HOME/generated_images/.../ig_*.png
qa_note=<one sentence>

创意杂志风

适用场景:

• 创意提案
• 品牌展示
• 设计作品集
• 文化活动
• 时尚发布
• 艺术展览
• 创意工作室介绍

GPT-Image-2 风格 Brief:

{
  "type": "16:9 full-slide PowerPoint image",
  "style_name": "创意杂志风",
  "best_for": "需要强视觉记忆点、品牌个性或传播感的分享型演示",
  "visual_direction": "high-end editorial magazine spread, bold asymmetry, art-directed composition, graphic tension, premium creative layout",
  "canvas": {
    "aspect_ratio": "16:9",
    "background": "white, black, or deep charcoal with intentional negative space",
    "composition": "asymmetric editorial layout with a large headline, image/collage zone, and 2-3 supporting text blocks",
    "density": "strong contrast between dense editorial blocks and open whitespace"
  },
  "color_palette": {
    "base": "black, white, and gray",
    "accent": "one vivid accent such as neon pink #FF006E, lemon yellow #FFED00, or electric cyan #00F5FF",
    "support": "optional lavender, coral, or muted fashion tones",
    "rule": "use one dominant accent color consistently; do not make the palette chaotic"
  },
  "typography": {
    "title": "oversized bold display sans-serif or editorial serif, can occupy 25-45% of the slide",
    "body": "small clean sans-serif blocks with strong alignment",
    "emphasis": "keywords may use accent color, rotated labels, vertical text, or extreme scale contrast",
    "text_quality": "Chinese headline and key points must be exact and readable"
  },
  "layout_patterns": [
    "oversized headline on one side with collage or abstract image block on the other",
    "diagonal color block cutting across the slide",
    "magazine cover style with title, subtitle, and three feature teasers",
    "editorial grid with one large image crop and small annotation labels"
  ],
  "layout_usage_rule": "Use layout_blueprints as candidate starting points only. Choose and adapt the composition according to each slide's semantic role; avoid repeating the same blueprint on adjacent slides unless it is a deliberate repeated sequence.",
  "layout_blueprints": [
    {
      "name": "editorial hero spread",
      "sections": [
        {"position": "left 45%", "count": 1, "labels": ["oversized headline"]},
        {"position": "right 55%", "count": 1, "labels": ["collage or abstract image zone"]},
        {"position": "bottom-left", "count": 3, "labels": ["feature teaser 1", "feature teaser 2", "feature teaser 3"]}
      ]
    },
    {
      "name": "cover story grid",
      "sections": [
        {"position": "top", "count": 1, "labels": ["large cover title"]},
        {"position": "center", "count": 2, "labels": ["main visual block", "accent typography block"]},
        {"position": "right edge", "count": 3, "labels": ["short editorial callouts"]}
      ]
    }
  ],
  "visual_elements": {
    "allowed": "bold geometric blocks, cropped photography zones, halftone texture, thin rules, torn-paper collage edges, accent stickers, abstract shapes",
    "avoid": "generic corporate icons, overly symmetrical layout, low-contrast text, too many accent colors"
  },
  "rendering_constraints": [
    "The slide should feel designed, not templated.",
    "Maintain legibility despite bold composition.",
    "No watermark, no unrelated logo, no slide number unless explicitly requested."
  ]
}

复古扁平插画风

适用场景:

• 文化创意项目展示
• 品牌故事讲述
• 旅游景点介绍
• 复古产品发布
• 艺术设计作品集
• 创意活动宣传
• 生活方式类演示

GPT-Image-2 风格 Brief:

{
  "type": "16:9 full-slide PowerPoint image",
  "style_name": "复古扁平插画风",
  "best_for": "文化创意、品牌故事、生活方式、城市旅游和带叙事感的主题演示",
  "visual_direction": "retro flat vector illustration slide, cream paper texture, monoline black outlines, vintage palette, playful handcrafted design",
  "canvas": {
    "aspect_ratio": "16:9",
    "background": "cream/off-white paper #F5F3E8 with subtle grain",
    "composition": "panoramic illustration band plus structured content cards or labels",
    "density": "moderate, decorative but still clear"
  },
  "color_palette": {
    "base": "cream background and dark slate text #34495E",
    "vintage_colors": "coral red #FF6B6B, mint green #95E1D3, mustard yellow #F9CA24, burnt orange #E17055, slate blue #6C7A89",
    "line": "uniform black or deep charcoal outline",
    "rule": "flat fills only, no glossy 3D, no heavy gradients"
  },
  "typography": {
    "title": "bold retro serif or chunky vintage display type",
    "body": "geometric sans-serif, clear and friendly",
    "labels": "small badge labels with outlined shapes",
    "text_quality": "Chinese text must be exact and readable"
  },
  "layout_patterns": [
    "top panoramic flat illustration with bottom content cards",
    "central retro title with three outlined icon cards",
    "2.5D simplified scene with callout labels",
    "vintage poster composition adapted to presentation readability"
  ],
  "layout_usage_rule": "Use layout_blueprints as candidate starting points only. Choose and adapt the composition according to each slide's semantic role; avoid repeating the same blueprint on adjacent slides unless it is a deliberate repeated sequence.",
  "layout_blueprints": [
    {
      "name": "panoramic illustration plus cards",
      "sections": [
        {"position": "top third", "count": 1, "labels": ["panoramic flat vector illustration"]},
        {"position": "middle", "count": 1, "labels": ["large retro title"]},
        {"position": "bottom", "count": 3, "labels": ["outlined content card 1", "outlined content card 2", "outlined content card 3"]}
      ]
    },
    {
      "name": "retro poster diagram",
      "sections": [
        {"position": "center", "count": 1, "labels": ["main simplified scene or object"]},
        {"position": "around center", "count": 4, "labels": ["callout label", "badge", "mini icon", "decorative note"]},
        {"position": "bottom-right", "count": 1, "labels": ["summary plaque"]}
      ]
    }
  ],
  "visual_elements": {
    "allowed": "flat vector scenes, 2-3px monoline outlines, simplified buildings, plants, clouds, badges, dotted textures, small geometric decorations",
    "avoid": "photorealism, complex shadows, neon palette, overly detailed linework, unreadable decorative type"
  },
  "rendering_constraints": [
    "The slide should feel like a polished retro illustration system, not a random cartoon.",
    "Maintain consistent outline weight across objects.",
    "No watermark, no unrelated logo, no slide number unless explicitly requested."
  ]
}

手绘技术解释风

适用场景:

• 中文技术文章配图
• 技术概念解释
• 课程课件
• 知识卡片
• 产品机制说明
• AI / 软件工程主题分享
• 需要降低理解门槛的复杂概念

GPT-Image-2 风格 Brief:

{
  "type": "16:9 full-slide PowerPoint image",
  "style_name": "手绘技术解释风",
  "best_for": "中文技术文章、课程课件、复杂概念解释、知识卡片和软件工程/AI 主题的低压力说明图",
  "visual_direction": "clean Chinese handdrawn technical explainer, near-white paper background, thin sketch lines, light pencil hatching, small precise central diagram, restrained pastel markers, lots of whitespace, calm educational tone",
  "canvas": {
    "aspect_ratio": "16:9",
    "background": "near-white paper #FCFBF7, not yellow, no full-page border",
    "composition": "small central explanatory diagram with sparse labels, surrounding whitespace, short title and minimal visible text",
    "density": "low to moderate; one core idea per slide; avoid dense whiteboard clutter"
  },
  "color_palette": {
    "line": "soft graphite #2F3437 or dark gray ink, thin and slightly irregular",
    "accent": "pale blue #BFD7F1, sage green #CFE2D1, light peach #F4C7B8, pale lavender #D8C7EF",
    "background": "near-white, clean, not kraft, not cream-heavy",
    "rule": "pastel marks are used for emphasis only; keep the page calm and airy"
  },
  "typography": {
    "title": "restrained handwritten Chinese title, medium-large but not poster-sized",
    "body": "short handwritten Chinese labels, few words per label, easy to inspect",
    "emphasis": "light underline, small bracket, soft marker highlight, or tiny note tag",
    "text_quality": "Chinese text must be exact, sparse, and readable; avoid long paragraphs"
  },
  "layout_patterns": [
    "central concept diagram with 3-4 short surrounding labels",
    "before-after explanation with two small sketch panels",
    "flow diagram with 3 steps and minimal arrows",
    "mental model page with one metaphor object and short annotations",
    "matrix or decision guide with sparse handwritten notes",
    "summary page with one small character or object and three takeaway labels"
  ],
  "layout_usage_rule": "Use layout_blueprints as candidate starting points only. Choose and adapt the composition according to each slide's semantic role; keep visual DNA stable while varying archetypes such as metaphor, process, comparison, matrix, and summary. Avoid repeating the same blueprint on adjacent slides unless it is a deliberate repeated sequence.",
  "layout_blueprints": [
    {
      "name": "small central concept map",
      "sections": [
        {"position": "top-left", "count": 1, "labels": ["short handwritten title"]},
        {"position": "center", "count": 1, "labels": ["small precise concept diagram"]},
        {"position": "around center", "count": 4, "labels": ["label 1", "label 2", "label 3", "label 4"]},
        {"position": "bottom-right", "count": 1, "labels": ["one-sentence takeaway"]}
      ]
    },
    {
      "name": "technical before-after",
      "sections": [
        {"position": "top", "count": 1, "labels": ["short page title"]},
        {"position": "left", "count": 1, "labels": ["before sketch panel"]},
        {"position": "right", "count": 1, "labels": ["after sketch panel"]},
        {"position": "between panels", "count": 1, "labels": ["thin handdrawn arrow"]},
        {"position": "bottom", "count": 3, "labels": ["why it matters", "tradeoff", "next step"]}
      ]
    },
    {
      "name": "one idea teaching card",
      "sections": [
        {"position": "center-left", "count": 1, "labels": ["metaphor object or tiny engineer/reader character"]},
        {"position": "center-right", "count": 3, "labels": ["core idea", "common mistake", "useful rule"]},
        {"position": "background", "count": 1, "labels": ["very light pencil hatching and pastel highlight"]}
      ]
    }
  ],
  "visual_elements": {
    "allowed": "thin handdrawn arrows, small diagrams, pencil hatching, pastel marker blocks, bracket notes, simple software/AI icons, tiny engineer or reader character at most once",
    "avoid": "messy whiteboard frame, marker tray, large cartoon characters, dense handwriting, yellowed paper, decorative stickers, poster-scale title, full-page border, digital UI cards"
  },
  "rendering_constraints": [
    "The slide should feel like a calm handdrawn technical article illustration, not a brainstorming whiteboard.",
    "Keep the central drawing small and precise with generous empty space.",
    "Use minimal Chinese text and make every visible word correct.",
    "No watermark, no unrelated logo, no slide number unless explicitly requested."
  ]
}

手绘白板风

适用场景:

• 教学讲解
• 培训课程
• 头脑风暴
• 概念说明
• 技术分享
• 内部研讨

GPT-Image-2 风格 Brief:

{
  "type": "16:9 full-slide PowerPoint image",
  "style_name": "手绘白板风",
  "best_for": "概念解释、技术分享、培训课程和需要亲和力的思路拆解",
  "visual_direction": "realistic whiteboard explanation slide, marker handwriting, sketched diagrams, friendly teaching atmosphere, authentic whiteboard details",
  "canvas": {
    "aspect_ratio": "16:9",
    "background": "warm off-white whiteboard surface #FAFAF5 with subtle marker smudges",
    "composition": "freeform but organized whiteboard layout with title, three concept blocks, arrows, and small doodle illustrations",
    "density": "moderate, readable, brainstorming feel without chaos"
  },
  "color_palette": {
    "primary": "black marker for main text",
    "accent": "red #E74C3C, blue #3498DB, orange #F39C12 marker annotations",
    "support": "green #27AE60, purple #9B59B6, yellow sticky note #FFF9C4",
    "rule": "colors should look like real marker ink, not digital neon"
  },
  "typography": {
    "title": "large neat handwritten Chinese marker style",
    "body": "clear handwritten marker text, slightly irregular but readable",
    "emphasis": "circle, underline, boxed words, sticky-note comments",
    "text_quality": "Chinese handwriting must remain accurate and legible"
  },
  "layout_patterns": [
    "three hand-drawn boxes connected by arrows",
    "central concept bubble with surrounding notes",
    "simple process diagram with sketches and annotations",
    "left explanation list plus right hand-drawn diagram"
  ],
  "layout_usage_rule": "Use layout_blueprints as candidate starting points only. Choose and adapt the composition according to each slide's semantic role; avoid repeating the same blueprint on adjacent slides unless it is a deliberate repeated sequence.",
  "layout_blueprints": [
    {
      "name": "whiteboard process diagram",
      "sections": [
        {"position": "top-left", "count": 1, "labels": ["handwritten title"]},
        {"position": "center", "count": 3, "labels": ["step 1 box", "step 2 box", "step 3 box"]},
        {"position": "between boxes", "count": 2, "labels": ["hand-drawn arrow", "hand-drawn arrow"]},
        {"position": "right edge", "count": 1, "labels": ["sticky-note takeaway"]}
      ]
    },
    {
      "name": "concept map",
      "sections": [
        {"position": "center", "count": 1, "labels": ["main concept bubble"]},
        {"position": "around center", "count": 4, "labels": ["supporting idea", "risk note", "example sketch", "action item"]},
        {"position": "bottom", "count": 1, "labels": ["underlined summary"]}
      ]
    }
  ],
  "visual_elements": {
    "allowed": "whiteboard frame, marker tray, colored markers, arrows, boxes, clouds, sticky notes, doodle icons, underlines, circled keywords",
    "avoid": "messy illegible handwriting, childish clutter, photoreal people, digital UI cards"
  },
  "rendering_constraints": [
    "The slide should look like a real whiteboard captured cleanly for a presentation.",
    "Keep all Chinese text readable despite handwritten style.",
    "No watermark, no unrelated logo, no slide number unless explicitly requested."
  ]
}

数据仪表盘风

适用场景:

• 数据分析报告
• 业绩展示
• KPI 汇报
• 实时数据展示
• 商业智能BI
• 运营数据看板

GPT-Image-2 风格 Brief:

{
  "type": "16:9 full-slide PowerPoint image",
  "style_name": "数据仪表盘风",
  "best_for": "数据密集型汇报、运营分析、KPI 复盘和业务洞察展示",
  "visual_direction": "bright modern SaaS analytics dashboard, clean BI interface, lightweight data cards, precise charts, professional and non-oppressive",
  "canvas": {
    "aspect_ratio": "16:9",
    "background": "white #FFFFFF, very light blue-gray #F5F8FC, or mist gray #F8FAFC",
    "composition": "dashboard grid with title area, KPI cards, chart panels, and status list",
    "density": "medium-high information density with enough card spacing and clear grouping"
  },
  "color_palette": {
    "primary": "data blue #2563EB or #1976D2",
    "secondary": "cyan #06B6D4 and soft purple #8B5CF6",
    "status": "green #10B981, orange #F59E0B, red #EF4444 used sparingly",
    "text": "deep navy #0F172A and neutral gray #64748B",
    "rule": "avoid dark control-room backgrounds, heavy neon, and oppressive black panels"
  },
  "typography": {
    "title": "bold clean sans-serif, dashboard header style",
    "numbers": "large tabular numerals for KPI values",
    "labels": "small but readable sans-serif chart labels",
    "text_quality": "Chinese labels and KPI names must be exact and legible"
  },
  "layout_patterns": [
    "top KPI strip with 3-4 cards and trend arrows",
    "main area split into workflow cards and a line chart",
    "lower area with donut chart, bar chart, and recent activity table",
    "large central insight card surrounded by supporting metrics"
  ],
  "layout_usage_rule": "Use layout_blueprints as candidate starting points only. Choose and adapt the composition according to each slide's semantic role; avoid repeating the same blueprint on adjacent slides unless it is a deliberate repeated sequence.",
  "layout_blueprints": [
    {
      "name": "SaaS BI overview",
      "sections": [
        {"position": "top-left", "count": 1, "labels": ["dashboard title and subtitle"]},
        {"position": "top-right", "count": 4, "labels": ["KPI card 1", "KPI card 2", "KPI card 3", "KPI card 4"]},
        {"position": "middle-left", "count": 3, "labels": ["process card 1", "process card 2", "process card 3"]},
        {"position": "middle-right", "count": 1, "labels": ["line chart panel"]},
        {"position": "bottom", "count": 3, "labels": ["donut chart", "bar chart", "recent records table"]}
      ]
    },
    {
      "name": "single insight dashboard",
      "sections": [
        {"position": "center", "count": 1, "labels": ["large insight card"]},
        {"position": "surrounding", "count": 4, "labels": ["supporting metric", "trend sparkline", "status list", "risk indicator"]}
      ]
    }
  ],
  "visual_elements": {
    "allowed": "white cards, soft shadows, pale borders, line charts, bar charts, progress rings, KPI cards, status dots, trend arrows, mini sparklines",
    "avoid": "dark monitoring wall, dense cyberpunk glow, unreadable tiny table text, random numbers without structure"
  },
  "rendering_constraints": [
    "The slide should look like a polished SaaS analytics product screenshot adapted for presentation.",
    "Charts should be visually plausible and organized, even when illustrative.",
    "No watermark, no unrelated logo, no slide number unless explicitly requested."
  ]
}

清爽专业风

适用场景:

• 毕业答辩
• 工作总结
• 工作 review
• 技术分享
• 项目复盘
• 晋升述职
• 阶段性成果汇报

GPT-Image-2 风格 Brief:

{
  "type": "16:9 full-slide PowerPoint image",
  "style_name": "清爽专业风",
  "best_for": "毕业答辩、工作总结、工作 review、技术分享、项目复盘和晋升述职等需要清晰表达过程、成果、问题和下一步的场景",
  "visual_direction": "clean modern professional deck, calm technical presentation, structured evidence-driven layout, readable pragmatic visual system, light background with crisp hierarchy",
  "canvas": {
    "aspect_ratio": "16:9",
    "background": "warm white #FFFFFF, light gray #F8FAFC, or very pale blue #F6F9FF",
    "composition": "title zone, structured content zone, evidence/diagram zone, and concise takeaway zone",
    "density": "medium information density, enough room for technical details without visual clutter"
  },
  "color_palette": {
    "primary": "professional blue #2563EB or slate blue #334155",
    "secondary": "calm teal #0F766E or muted cyan #0891B2",
    "accent": "soft amber #F59E0B for highlights and risk/attention notes",
    "neutral": "slate gray #475569, light border #E2E8F0, pale card background #F8FAFC",
    "rule": "use restrained professional colors; avoid playful neon, luxury gold, or heavy dark backgrounds"
  },
  "typography": {
    "title": "clear bold sans-serif, report-like and authoritative",
    "body": "clean sans-serif, strong hierarchy, left-aligned for readability",
    "labels": "small but readable labels for timeline, evidence, metrics, and code/process diagrams",
    "text_quality": "Chinese text must be exact, readable, and suitable for formal reporting"
  },
  "layout_patterns": [
    "problem-process-result-next steps",
    "timeline plus milestone cards",
    "technical architecture diagram with key takeaways",
    "summary dashboard with achievements, issues, learnings, and plan",
    "defense slide with research question, method, evidence, and conclusion"
  ],
  "layout_usage_rule": "Use layout_blueprints as candidate starting points only. Choose and adapt the composition according to each slide's semantic role; avoid repeating the same blueprint on adjacent slides unless it is a deliberate repeated sequence.",
  "layout_blueprints": [
    {
      "name": "work review summary",
      "sections": [
        {"position": "top", "count": 1, "labels": ["slide title and context subtitle"]},
        {"position": "left column", "count": 3, "labels": ["目标", "完成情况", "关键结果"]},
        {"position": "right column", "count": 2, "labels": ["问题与风险", "下一步计划"]},
        {"position": "bottom", "count": 1, "labels": ["one-sentence takeaway"]}
      ]
    },
    {
      "name": "technical sharing flow",
      "sections": [
        {"position": "top-left", "count": 1, "labels": ["topic title and motivation"]},
        {"position": "center", "count": 1, "labels": ["architecture / workflow / method diagram"]},
        {"position": "right", "count": 3, "labels": ["核心机制", "实践经验", "注意事项"]},
        {"position": "bottom", "count": 3, "labels": ["before", "after", "impact"]}
      ]
    },
    {
      "name": "graduation defense evidence slide",
      "sections": [
        {"position": "top", "count": 1, "labels": ["研究问题 / 答辩主题"]},
        {"position": "left", "count": 1, "labels": ["方法路线图"]},
        {"position": "center", "count": 2, "labels": ["实验/项目证据", "关键数据"]},
        {"position": "right", "count": 1, "labels": ["结论与贡献"]},
        {"position": "bottom", "count": 1, "labels": ["限制与后续工作"]}
      ]
    }
  ],
  "visual_elements": {
    "allowed": "timeline, checklist, progress bars, architecture blocks, process arrows, evidence cards, metric badges, issue/risk callouts, code-like panels, simple icons",
    "avoid": "overly decorative poster layout, random stock photos, cute stickers, dense unreadable tables, exaggerated marketing style"
  },
  "rendering_constraints": [
    "The slide should look suitable for a real workplace review, thesis defense, or technical sharing session.",
    "Prioritize clarity, evidence, and logical flow over decoration.",
    "All diagrams and labels should feel purposeful and related to the slide content.",
    "No watermark, no unrelated logo, no slide number unless explicitly requested."
  ]
}

温暖手工风

适用场景:

• 儿童教育
• 文化活动
• 手工艺展示
• 温馨主题
• 亲子活动
• 艺术工作坊
• 社区公益项目

GPT-Image-2 风格 Brief:

{
  "type": "16:9 full-slide PowerPoint image",
  "style_name": "温暖手工风",
  "best_for": "教育、公益、文化、成长、社区和需要温度感的主题演示",
  "visual_direction": "warm handmade paper collage slide, tactile paper craft, gentle human-centered storytelling, cozy scrapbook composition",
  "canvas": {
    "aspect_ratio": "16:9",
    "background": "warm cream paper #F5F1E8 or pale wood #E8DCC8 with subtle paper fibers",
    "composition": "paper cutout title area, 3 paper note cards for key points, gentle illustration accents",
    "density": "airy and comforting, generous breathing room"
  },
  "color_palette": {
    "primary": "warm brown #A67C52 and deep cocoa #5C4033 for text",
    "soft_colors": "dusty pink #F5C4B8, sage green #B8D4A8, sky blue #A8D8EA, sunset orange #FFA574, lavender #C9B1D0",
    "surface": "cream, handmade paper, kraft paper, pastel sticky notes",
    "rule": "all colors should feel soft, matte, and paper-like"
  },
  "typography": {
    "title": "rounded handwritten or friendly display style",
    "body": "clear friendly handwritten or rounded sans-serif Chinese text",
    "emphasis": "paper labels, stitched tags, small handwritten captions",
    "text_quality": "Chinese text must be accurate and legible"
  },
  "layout_patterns": [
    "three torn-paper cards aligned naturally across the slide",
    "scrapbook title ribbon with small illustrated stickers",
    "central handmade diagram with taped labels",
    "soft paper collage with one warm illustration and supporting notes"
  ],
  "layout_usage_rule": "Use layout_blueprints as candidate starting points only. Choose and adapt the composition according to each slide's semantic role; avoid repeating the same blueprint on adjacent slides unless it is a deliberate repeated sequence.",
  "layout_blueprints": [
    {
      "name": "paper note cards",
      "sections": [
        {"position": "top", "count": 1, "labels": ["torn-paper title ribbon"]},
        {"position": "center", "count": 3, "labels": ["paper card 1", "paper card 2", "paper card 3"]},
        {"position": "corners", "count": 4, "labels": ["small sticker", "tape strip", "plant doodle", "paper clip"]}
      ]
    },
    {
      "name": "scrapbook story",
      "sections": [
        {"position": "left", "count": 1, "labels": ["warm illustration or paper collage scene"]},
        {"position": "right", "count": 3, "labels": ["key point note", "example note", "takeaway note"]},
        {"position": "bottom", "count": 1, "labels": ["handwritten closing line"]}
      ]
    }
  ],
  "visual_elements": {
    "allowed": "paper texture, torn edges, tape, paper clips, buttons, watercolor blocks, simple doodles, plant stickers, soft shadows",
    "avoid": "glossy plastic look, corporate sharp edges, harsh black text, neon colors, overly childish clutter"
  },
  "rendering_constraints": [
    "The slide should feel handmade but still presentation-ready.",
    "Paper shadows and textures should be subtle and not reduce text legibility.",
    "No watermark, no unrelated logo, no slide number unless explicitly requested."
  ]
}

电子墨水杂志风

适用场景:

• 线下分享
• 行业内部讲话
• AI / 科技产品发布
• Demo day
• 个人观点型演讲
• 非虚构叙事
• 需要强节奏感的主题演讲

GPT-Image-2 风格 Brief:

{
  "type": "16:9 full-slide PowerPoint image",
  "style_name": "电子墨水杂志风",
  "best_for": "线下演讲、观点分享、AI/科技发布、非虚构叙事和需要强个人表达的横向演示",
  "visual_direction": "electronic ink editorial presentation, premium magazine layout, serif headline, sans-serif body, monospace metadata, restrained WebGL-like ink flow background only as subtle texture, strong hero/non-hero rhythm",
  "canvas": {
    "aspect_ratio": "16:9",
    "background": "off-white #F7F4EA, ink black #111111, deep indigo #1E2A78, forest ink #163B2F, kraft paper #D8C3A5, or dune sand #D9C29E depending on theme",
    "composition": "editorial grid with strong margins, magazine-like hierarchy, hero pages alternating with quieter content pages",
    "density": "moderate to low information density, designed for stage readability and narrative pacing"
  },
  "color_palette": {
    "base": "paper-like light background or deep ink background",
    "primary": "ink black, off-white, or deep indigo",
    "accent": "one restrained accent such as vermilion, electric blue, forest green, or sand gold",
    "metadata": "muted gray or low-contrast monochrome",
    "rule": "use a curated theme palette; avoid random custom colors and decorative gradients"
  },
  "typography": {
    "title": "large editorial serif Chinese headline or elegant high-contrast display type",
    "body": "clean sans-serif, short paragraphs or compact bullets",
    "metadata": "small monospace labels for chapter, date, source, index, or tags",
    "text_quality": "Chinese text must be exact, readable, and typeset like a magazine spread"
  },
  "layout_patterns": [
    "hero cover with oversized serif headline and subtle ink-flow background",
    "chapter divider with one provocative sentence and metadata strip",
    "data poster with one huge number, footnote, and tiny supporting labels",
    "left text right image with image treated as editorial photography or abstract ink plate",
    "big quote page with pull quote, source line, and large whitespace",
    "before-after comparison with two editorial columns"
  ],
  "layout_usage_rule": "Use layout_blueprints as candidate starting points only. Choose and adapt the composition according to each slide's semantic role; alternate hero and non-hero pages to create rhythm, and avoid repeating the same blueprint on adjacent slides unless it is a deliberate repeated sequence.",
  "layout_blueprints": [
    {
      "name": "hero editorial opener",
      "sections": [
        {"position": "left or center", "count": 1, "labels": ["oversized serif headline"]},
        {"position": "top or side edge", "count": 3, "labels": ["chapter label", "date/source", "short metadata"]},
        {"position": "background", "count": 1, "labels": ["subtle ink-flow or paper texture"]},
        {"position": "bottom", "count": 1, "labels": ["one-line thesis"]}
      ]
    },
    {
      "name": "magazine argument spread",
      "sections": [
        {"position": "top-left", "count": 1, "labels": ["slide title"]},
        {"position": "left column", "count": 2, "labels": ["argument block", "evidence block"]},
        {"position": "right half", "count": 1, "labels": ["editorial image, diagram, or abstract visual plate"]},
        {"position": "bottom", "count": 1, "labels": ["monospace metadata strip"]}
      ]
    },
    {
      "name": "data broadsheet",
      "sections": [
        {"position": "center-left", "count": 1, "labels": ["huge number or keyword"]},
        {"position": "right column", "count": 3, "labels": ["supporting fact 1", "supporting fact 2", "supporting fact 3"]},
        {"position": "bottom-left", "count": 1, "labels": ["source / caveat / time range"]}
      ]
    }
  ],
  "visual_elements": {
    "allowed": "editorial rules, thin dividers, paper grain, subtle ink-flow texture, cropped photography zones, metadata strips, chapter marks, pull quotes, huge numerals",
    "avoid": "template-like cards, shiny corporate gradients, cute illustrations, dense tables, dashboard overload, generic stock-photo collage"
  },
  "rendering_constraints": [
    "The slide should feel like an electronic magazine page adapted for a stage presentation.",
    "Use large readable typography and strong whitespace.",
    "Do not turn every page into a hero cover; alternate page intensity across the deck.",
    "No watermark, no unrelated logo, no slide number unless explicitly requested."
  ]
}

科研答辩风

适用场景:

• 科研项目申报答辩
• 基金申请与重点专项汇报
• 中期检查与结题验收
• 论文开题、预答辩和毕业答辩
• 课题分解、技术路线、研究基础、风险分析和预期成果展示
• 高校、科研院所、实验室和产学研项目的正式汇报

GPT-Image-2 风格 Brief:

{
  "type": "16:9 full-slide PowerPoint image",
  "style_name": "科研答辩风",
  "best_for": "科研项目申报、基金答辩、课题中期检查、结题验收、论文答辩和实验室阶段性成果汇报等正式学术场景",
  "visual_direction": "formal Chinese academic research defense deck, authoritative but adaptable project presentation, evidence-driven layout, structured scientific diagrams, concise conclusions, and disciplined visual hierarchy",
  "canvas": {
    "aspect_ratio": "16:9",
    "background": "clean white #FFFFFF with subtle light gray #F5F7FA content background",
    "composition": "structured academic slide with title area, evidence area, explanatory diagrams, tables, callouts, or conclusion area chosen according to slide content",
    "density": "medium-high to high information density, suitable for serious academic defense, while keeping clear reading order and alignment"
  },
  "color_palette": {
    "primary": "deep academic blue #003F8F or #004A9F",
    "secondary": "research blue #0B5CAD and pale blue #EAF2FF",
    "accent": "formal red #B5121B or #C00000 used sparingly for key conclusions, risks, breakthroughs, and emphasized phrases",
    "neutral": "black #111111, dark gray #333333, light border gray #D8DEE8, pale table fill #F3F6FA",
    "optional": "muted gold #F3DFA2 only for cover or major title emphasis",
    "rule": "prefer blue for structure and red for critical arguments, but adapt emphasis to the topic and source material; avoid colorful decorative palettes, heavy gradients, playful icons, and casual illustration styles"
  },
  "typography": {
    "title": "bold Chinese sans-serif, large, formal, report-like, left aligned",
    "section_labels": "white bold Chinese text on deep blue blocks or arrow labels",
    "body": "dense but readable Chinese sans-serif, mostly black, key phrases in red bold",
    "tables": "compact academic table typography with clear header rows and restrained category emphasis",
    "text_quality": "Chinese text must be exact, readable, non-garbled, and suitable for formal research defense"
  },
  "page_system": {
    "header": "usually use a clear title area with optional section number and optional project/institution mark; cover pages and divider pages may use a different composition",
    "divider": "optional thin horizontal rule, blue segment, or subtle academic separator when it helps hierarchy",
    "body": "structured content area with light borders, module labels, evidence cards, diagrams, or tables as needed",
    "footer": "optional one-sentence takeaway strip or conclusion line when the slide needs a strong final claim",
    "logo_rule": "use only user-provided logos or a neutral text placeholder such as 项目标识; do not invent real institution logos or unrelated brand names"
  },
  "layout_patterns": [
    "research background with literature timeline, policy/report evidence, and problem statement",
    "research status with left-side evidence collage and right-side challenge comparison",
    "topic decomposition with multi-column task chain and right-side vertical research path",
    "research content page with three evidence cards and supporting mechanism images",
    "core objective page with arrow label, large target sentence, technical route, and mechanism diagram",
    "platform support page with equipment photos, prior achievements, certificates, and bullet evidence",
    "risk analysis four-quadrant grid with risk type, risk judgment, mitigation evidence, and bottom conclusion",
    "expected outcomes table with category, measurable indicators, and assessment method"
  ],
  "layout_usage_rule": "Use these patterns as flexible starting points, not mandatory templates. Keep the deck's academic tone, disciplined hierarchy, restrained palette, and evidence-first logic, while adapting the body layout to each slide's role and source material.",
  "layout_blueprints": [
    {
      "name": "研究背景 / 研究现状",
      "sections": [
        {"position": "top", "count": 1, "labels": ["one-sentence problem or status statement with optional emphasized phrases"]},
        {"position": "left large area", "count": 1, "labels": ["literature timeline / technical evolution / evidence collage"]},
        {"position": "right column", "count": 1, "labels": ["report evidence / industry challenge / application pain point"]},
        {"position": "bottom", "count": 1, "labels": ["optional takeaway conclusion"]}
      ]
    },
    {
      "name": "课题分解 / 技术路线",
      "sections": [
        {"position": "top", "count": 1, "labels": ["project objective sentence"]},
        {"position": "middle", "count": 3, "labels": ["课题一", "课题二", "课题三"]},
        {"position": "left side", "count": 2, "labels": ["应用基础研究", "关键任务核心内容"]},
        {"position": "right side", "count": 4, "labels": ["性能研究", "应用验证", "深入探索", "关系研究"]},
        {"position": "bottom", "count": 1, "labels": ["chain-summary sentence"]}
      ]
    },
    {
      "name": "核心目标 / 研究目标",
      "sections": [
        {"position": "top-left", "count": 1, "labels": ["blue arrow label: 核心目标 or 研究目标"]},
        {"position": "top-right", "count": 1, "labels": ["target sentence with key phrases"]},
        {"position": "middle", "count": 2, "labels": ["content detail box 1", "content detail box 2"]},
        {"position": "bottom", "count": 3, "labels": ["method diagram", "mechanism image", "application validation image"]},
        {"position": "bottom-center", "count": 1, "labels": ["technical route statement"]}
      ]
    },
    {
      "name": "研究内容 / 证据展示",
      "sections": [
        {"position": "top", "count": 1, "labels": ["research content sentence with key variables"]},
        {"position": "middle", "count": 3, "labels": ["研究内容一", "研究内容二", "研究内容三"]},
        {"position": "inside each card", "count": 3, "labels": ["blue title bar", "scientific figure or chart", "short evidence caption"]},
        {"position": "bottom", "count": 1, "labels": ["integrated conclusion or mechanism statement"]}
      ]
    },
    {
      "name": "风险分析",
      "sections": [
        {"position": "top", "count": 1, "labels": ["risk control thesis statement"]},
        {"position": "middle grid", "count": 4, "labels": ["技术风险", "安全风险", "性能风险", "管理风险"]},
        {"position": "bottom", "count": 1, "labels": ["supporting scientific images and final conclusion"]}
      ]
    },
    {
      "name": "预期成果 / 考核指标",
      "sections": [
        {"position": "top", "count": 3, "labels": ["高价值", "全覆盖", "可量化"]},
        {"position": "middle", "count": 1, "labels": ["large table: 类别 / 具体指标 / 考核方式"]},
        {"position": "left table column", "count": 4, "labels": ["理论创新与知识产权", "技术突破与材料开发", "人才培养与学术影响", "长远发展潜力"]}
      ]
    }
  ],
  "visual_elements": {
    "allowed": "academic tables, blue arrow labels, restrained red emphasis text, flow arrows, technical route diagrams, paper figure collages, mechanism diagrams, laboratory or equipment photos, certificates, report thumbnails, structured grids, light shadows",
    "avoid": "minimalist empty pages, marketing hero layouts, cartoon illustrations, decorative gradients, random icons, playful stickers, excessive whitespace, vague stock photos, fruits, animals, people cutouts, unrelated decorative objects"
  },
  "writing_style": {
    "sentence_patterns": [
      "系统研究……并揭示……机制",
      "构建……体系，实现……精准调控",
      "围绕……形成完整闭环研究链条",
      "通过……验证……性能",
      "可有效规避或化解……风险",
      "所有成果均设置具体、可测量指标"
    ],
    "emphasis_rule": "Use red bold text selectively for the scientific problem, key breakthrough, risk judgment, measurable outcome, or page-level conclusion; do not over-highlight every sentence."
  },
  "rendering_constraints": [
    "The slide must look like a serious Chinese academic research defense deck, not a commercial pitch deck.",
    "Keep a recognizable academic presentation system across slides, but do not force every page into the same header or grid.",
    "Every page should have a clear top-to-bottom or left-to-right reading order.",
    "Use high-density scientific content, but keep text blocks aligned and readable.",
    "Use blue structural labels and red conclusion phrases when useful, without making the page mechanically blue-red.",
    "Do not include fruit, people, animals, random objects, fictional brand marks, or unrelated decorative icons.",
    "No watermark, no unrelated logo, no fake real institution logo, no extra slide number unless requested."
  ]
}

麦肯锡风格

适用场景:

• 商业咨询型 PPT / PPTX 整套演示
• PPT 封面页、章节页、关键观点页
• 咨询分析页、框架页、方法论页
• 流程图、路线图、矩阵图、价值链、五力模型、2x2 定位图
• 结论页、建议页、执行路线页
• 商业策略、增长、转型、组织、效率、机会、风险等主题
• 需要“文字主导 + 商业隐喻 + 咨询报告质感”的视觉型演示

GPT-Image-2 风格 Brief:

{
  "type": "16:9 full-slide PowerPoint image",
  "style_name": "麦肯锡风格",
  "best_for": "商业咨询型 PPT / PPTX 整套演示，包括封面页、章节页、关键观点页、咨询分析页、框架页、方法论页、流程图、路线图、矩阵图、价值链、五力模型、2x2 定位图、结论页、建议页和执行路线页；适合商业策略、增长、转型、组织、效率、机会、风险等需要麦肯锡式理性气质、高端咨询报告视觉、标题信息重构、商业隐喻和清晰商业叙事的场景",
  "visual_direction": "McKinsey / BCG / Bain style rational consulting visual, premium executive report cover, modernist typographic poster, art-directed business metaphor, reconstructed title as architectural structure, precision annotation system, sharp Swiss grid, light blue-gray white palette, clean corporate editorial design, boardroom-ready restraint with real graphic tension",
  "canvas": {
    "aspect_ratio": "16:9",
    "background": "white or very pale cool gray field with optional subtle paper grain, light print texture, precise thin grid, quiet margin system, and restrained report-like metadata; avoid turning metadata into a repeated slide template",
    "composition": "first decide the PPT slide role: title/divider/key-message slides use one giant reconstructed core word, one dominant metaphor, strong negative space, and an intentional focal axis, vanishing point, or typographic architecture; analysis/framework/process slides use one core analytical structure and 3-6 ordered modules",
    "density": "title/divider/key-message slides are low-density with strong whitespace and one obvious center; analysis/framework/process slides are medium density, richer but still ordered, scannable, and built around one reading path"
  },
  "color_palette": {
    "primary": "white, off-white, light cool gray, pale blue-gray, ink blue-gray #243447 used as text or hairline emphasis",
    "secondary": "restrained consulting blue-gray, steel blue, mist blue, precise hairline gray",
    "accent": "very small restrained blue, steel blue, or muted gray-blue only for key node, value point, end point, decision point, or important arrow; avoid orange as a default accent",
    "neutral": "near-black #111111 only for small text, slate gray #475569, cool gray #6B7280, light border gray #D8DEE8, very pale background gray #F6F8FA",
    "rule": "colors must feel rational, premium, controlled, and light; avoid large dark navy blocks, orange-led accents, blue-purple neon, cyberpunk glow, fancy gradients, rainbow colors, high-saturation advertising colors, and large warm backgrounds"
  },
  "typography": {
    "title": "modern, clear, restrained, stable consulting-report typography; the main visual title should be custom-reconstructed with thin structural strokes, semi-hollow forms, split strokes, extended strokes, modular cuts, embedded grids, or architectural skeletons; keep it readable and avoid crude bold filled type",
    "body": "short precise Chinese/English labels, no long paragraphs, clear hierarchy, micro-typography for tags, variables, legends, nodes, occasional footers, and conclusions",
    "labels": "use restrained English classification labels such as STRATEGY, MARKET INSIGHT, BUSINESS MODEL, OPERATING MODEL, GROWTH SYSTEM, TRANSFORMATION, INDUSTRY VIEW, METHODOLOGY, RECOMMENDATION, ROADMAP, 2026",
    "text_quality": "main title, subtitle, brand names, people names, terms, English capitalization, and Chinese characters must be accurate; preserve the user's core input term; do not garble Chinese or invent unrelated labels"
  },
  "layout_patterns": [
    "PPT title or divider slide: top information bar with full title, English category tags, year or section number; central giant reconstructed core word; 2-3 edge anchor concepts; optional short takeaway only when it strengthens the page",
    "PPT key-message slide: extract a 2-8 character Chinese core word or 1-4 word English phrase as the main visual, keep the full claim as smaller subtitle text, and use only one dominant metaphor",
    "PPT title/key-message slide: fuse one business metaphor into the typography itself, such as path through strokes, funnel in negative space, matrix grid as character skeleton, data flow emerging from the word, fault line cutting the word, or architecture becoming the word body",
    "PPT title/key-message slide: make the core word feel engineered and art-directed: letter strokes may be cropped, extended, split, semi-transparent, line-drawn, or connected to crosshairs, target marks, measurement lines, nodes, and micro labels",
    "PPT title/key-message slide: create graphic tension through scale contrast, asymmetrical balance, precise alignment, restrained perspective rays, one focal point, and large quiet whitespace; avoid flat centered template composition",
    "PPT title/divider archetype: typographic science/report slide with ultra-thin Chinese character strokes, molecular or data-path particles crossing the word, side annotations, and optional evidence labels",
    "PPT key-message archetype: executive insight slide with a bold but controlled headline, one ribbon/path/spiral/arrow metaphor, vertical outcome scale, small right-side labels, and wide blank field",
    "PPT title/divider archetype: modernist typographic poster slide with oversized English or Chinese letterforms, curved line systems, crop marks, circular labels, and sparse deck metadata",
    "PPT analysis/framework slide: top claim area, central structure such as process, matrix, system, path, funnel, value chain, or layered architecture, side modules for insight, variables, constraints, risks, and opportunities, and an optional recommendation area if the slide needs a takeaway",
    "PPT analysis/process slide: use a clear reading path from left to right, top to bottom, problem to solution, input to output, current state to opportunity, or mechanism to result",
    "PPT framework slide: keep one large analytical mechanism as the hero and use micro annotations, numbered labels, hairline connectors, and restrained side notes instead of icon-heavy cards",
    "PPT analysis archetype: BCG-style matrix, five-forces map, value-chain map, operating-model map, roadmap, or 2x2 decision map with one dominant diagram, disciplined sidebars, small methodology labels, and at most one dark emphasis block",
    "metaphor library: choose exactly one most accurate dominant metaphor from funnel, path, ladder, matrix, coordinate, flywheel, node network, data flow, threshold, window, defense line, fault line, container, compass, or architecture",
    "business metaphor matching: funnel for conversion and filtering; path for strategy and transformation; ladder for maturity and value upgrade; matrix for positioning and priority; coordinate for market map and risk-return; flywheel for growth loops; node network for system collaboration; data flow for automation and efficiency; threshold for gating and risk control; window for timing and opportunity; defense line for governance and compliance; fault line for structural shifts; container for value pools; compass for direction choice; architecture for organization and capability base"
  ],
  "layout_usage_rule": "Use layout_blueprints as candidate starting points only. First identify the PPT slide role: title slide, section divider, key-message slide, analysis/framework slide, process/roadmap slide, matrix/positioning slide, or summary/recommendation slide. For title, divider, and key-message slides, use one giant reconstructed title, one dominant metaphor, low information density, strong whitespace, very few auxiliary words, and a visible graphic idea in the typography itself. For analysis, framework, process, and recommendation slides, use 3-6 main modules, one core structure, one dominant metaphor, concise labels, small legends or numbering, and a clear reading path. Keep a McKinsey-like rational, professional, restrained, premium identity while varying slide layouts across the deck. The slide should feel designed, not merely organized: use optical balance, scale contrast, precise margins, micro labels, and one memorable visual decision. Do not turn a secondary motif, footer, icon, callout strip, or module arrangement into a repeated master layout. Avoid default card grids, generic flowchart templates, and slides that only look organized but have no visual concept.",
  "layout_blueprints": [
    {
      "name": "PPT 封面页 / 章节页: 重构标题 + 单一商业隐喻",
      "sections": [
        {"position": "top", "count": 1, "labels": ["完整标题 / 英文分类标签 / 年份或编号"]},
        {"position": "center", "count": 1, "labels": ["giant reconstructed core word"]},
        {"position": "inside typography", "count": 1, "labels": ["one dominant metaphor fused into typography"]},
        {"position": "left and right edge", "count": 3, "labels": ["起点词", "终点词", "价值词"]},
        {"position": "optional bottom or side", "count": 1, "labels": ["short takeaway only when useful"]}
      ]
    },
    {
      "name": "PPT 关键观点页: 字体结构 + 咨询报告系统",
      "sections": [
        {"position": "top-left", "count": 1, "labels": ["small complete title system"]},
        {"position": "top-right", "count": 4, "labels": ["STRATEGY", "INSIGHT", "REPORT COVER", "2026"]},
        {"position": "center 70%", "count": 1, "labels": ["large typographic architecture"]},
        {"position": "background", "count": 1, "labels": ["thin grid, nodes, coordinates, hairline rules"]},
        {"position": "optional edge metadata", "count": 3, "labels": ["CLARITY", "STRUCTURE", "IMPACT or slide-specific tags"]}
      ]
    },
    {
      "name": "PPT 分析页: 核心结构 + 左右辅助模块",
      "sections": [
        {"position": "top", "count": 1, "labels": ["title, subtitle, classification tags"]},
        {"position": "center", "count": 1, "labels": ["core flow / matrix / system / funnel / value chain"]},
        {"position": "left", "count": 2, "labels": ["background insight", "key variable"]},
        {"position": "right", "count": 2, "labels": ["risk or constraint", "opportunity or action"]},
        {"position": "optional bottom or right rail", "count": 1, "labels": ["1-3 concise conclusions when needed"]}
      ]
    },
    {
      "name": "PPT 框架页: 矩阵 / 坐标 / 路线图",
      "sections": [
        {"position": "top", "count": 1, "labels": ["complete analytical title and short subtitle"]},
        {"position": "main area", "count": 1, "labels": ["2x2 matrix / coordinate map / roadmap"]},
        {"position": "inside structure", "count": 4, "labels": ["category", "priority", "risk", "opportunity"]},
        {"position": "side rail", "count": 1, "labels": ["methodology notes and legend"]},
        {"position": "optional bottom or side note", "count": 1, "labels": ["executive implication when needed"]}
      ]
    }
  ],
  "visual_elements": {
    "allowed": "custom typographic reconstruction, thin rules, precision grid, small nodes, coordinates, occasional target marks, crosshair marks, measurement lines, path lines, subtle vanishing rays, restrained arrows, faint perspective, variable report metadata, small numbering, minimal business diagrams, restrained chart fragments, one dark emphasis area when analytically necessary, paper grain, light print texture, subtle shadows, small legends, micro annotations",
    "avoid": "ordinary big title, no title reconstruction, no visual metaphor, disconnected metaphor and text, unrelated background decoration, generic PPT template, default rounded card grid, repeated decorative motif across all slides, repeated header/footer treatment across all slides, repetitive icon rows, icon-heavy modules, business people icons, handshake icons, cartoon characters, robot avatars, sci-fi blue-purple background, uncontrolled complex infographic, content with no hierarchy, overly thick or ornate typography, unreadable main title, overfilled composition, cheap self-media poster feel"
  },
  "rendering_constraints": [
    "The image must feel like a premium top-tier consulting-company visual work, not an official McKinsey template, not an ordinary PPT page, and not a social-media template.",
    "Text must be part of the structure, not just placed on top of the layout.",
    "The slide must have a visible graphic idea: a typographic structure, focal axis, engineered metaphor, or analytical mechanism that would still be recognizable without decorative labels.",
    "If the source title is long, extract a core visual word or phrase and preserve the complete title as smaller text in the header, side title system, or subtitle.",
    "Choose exactly one dominant metaphor for PPT title, divider, and key-message slides; do not stack multiple unrelated metaphors.",
    "For PPT analysis, framework, process, roadmap, and recommendation slides, all modules must unfold around one dominant metaphor and one core analytical structure.",
    "For PPT title, divider, and key-message slides, allow only 1 giant main visual title, 1 complete small title, 2-4 English tags, 1 dominant metaphor, optional short conclusion, and a few thin lines, nodes, numbering, or grid marks.",
    "For PPT title, divider, and key-message slides, forbid 5 or more modules, 3 or more charts, long explanations, dense icons, multiple conclusion boxes, and full process breakdown.",
    "For PPT analysis, framework, process, roadmap, and recommendation slides, use 3-6 main modules, 1 core large structure, 1-2 auxiliary small structures, key data, labels, numbering, annotations, and optional recommendation or implication area.",
    "For PPT analysis, framework, process, roadmap, and recommendation slides, forbid 8 or more modules, too many colors, too many icons, unlayered text, long paragraphs inside every module, and data/graphics without logical relationship.",
    "Use precise thin lines, small labels, grid, nodes, and a restrained light blue-gray-white palette; avoid large areas of heavy dark blue.",
    "Avoid making every page a neat card layout; use scale, negative space, alignment, and typographic reconstruction to create design value.",
    "Across a deck, keep palette, typography, line language, and report discipline consistent, but vary the dominant structure, secondary motif, and module arrangement according to each slide's role.",
    "Even if most decoration is removed, the core structure and business logic must still stand.",
    "Do not invent a real McKinsey logo, client logo, confidential label, proprietary watermark, unrelated logo, or watermark."
  ]
}