| name | ppt-deck-builder |
| description | Use this skill after PPT slide writing is approved to build an editable PowerPoint/PPTX from PPT Project Brief v3. It routes into either the default SVG-native page-by-page design branch or the optional PPTGenJS template-native branch, applies playback/animation settings, runs build QA, and outputs PPT Project Brief v4: Built Deck. |
PPT Deck Builder
Use this skill to turn PPT Project Brief v3: Slide Spec into an editable .pptx delivery package.
This skill owns visual route selection, page-level visual design, SVG composition, selective image generation/placement, typography, visual hierarchy, playback behavior, PPTX generation, and build QA.
For V2 project-mode runs, read ../../references/v2-architecture.md, ../../references/svg-visual-route.md, ../../references/visual-lock.md, ../../references/svg-technical-standards.md, ../../references/image-generation-system.md, ../../references/svg-quality-check.md, ../../references/visual-component-registry.md, and ../../references/template-system-v2.md. SVG is the default page-by-page design branch, but it must export to editable native PPTX objects whenever possible; do not degrade to whole-slide bitmap PPT. This skill owns the design/build artifacts under 04-design/ and 05-build/.
Responsibility Boundary
- If audience/scenario/goal is unclear, return to
ppt-goal-setting.
- If page sequence or core messages are wrong, return to
ppt-slide-structure.
- If page copy, page structure, layout intent, asset status, or visual recommendations are missing, return to
ppt-slide-writing.
- If v3 is complete and the task is visual/build execution, continue here.
Do not hide weak content with design. Do not use one old template for every deck type.
This skill owns the final design system: visual route, style system, typography, colors, spacing, SVG visual language, page rhythm, component/image fusion, and export QA.
Visual Route Strategy
Skill 4 has two build branches. Default to the SVG-native branch, while preserving the template-native branch as an explicit option.
| Branch | Default? | Use when | Core idea |
|---|
svg-native | yes | user asks for a designed deck, no strict corporate PPTX template is supplied, or the deck needs stronger visual impact | Generate each page as an SVG-led design, quality-check the SVG, then convert/assemble into editable native PPTX objects. AI images are supporting assets, not whole-slide fallbacks. |
template-native | no | user supplies a corporate template, requests strict template following, wants fastest deterministic production, or explicitly says not to use SVG | Use registered layout/theme/component templates and render with PPTGenJS native shapes/text. |
Default to svg-native unless the user explicitly chooses template-native or provides a strict template that must be preserved.
Route selection rules:
- If the user says "SVG", "视觉路线", "设计感", "像海报/杂志/活动页", or wants stronger aesthetics, choose
svg-native.
- If the user says "按公司模板", "套模板", "保持原模板", "稳定模式", "快速生成", "不要 SVG", or provides a
.pptx template, choose template-native.
- If the user does not choose, proceed with
svg-native.
- Do not mix both routes randomly page by page. A deck should have one primary route.
- Legacy aliases: treat
svg-visual and editable-page-design as svg-native; treat template as template-native.
svg-native route model:
page-by-page SVG design plan
-> hand/authored SVG pages or generated SVG page specs
-> SVG quality check
-> SVG-to-native-PPTX conversion/assembly
-> optional AI image assets inserted into SVG/PPT slots
-> QA and playback settings
- SVG-native output target: final PPTX should keep text, shapes, lines, cards, icons, diagrams, and numbers editable as native PowerPoint objects where the converter/toolchain supports it.
- AI image layer: cover atmosphere, hero scene, product/lifestyle image, premium visual impact, content moments that benefit from realism or artistry.
- Never rasterize the whole slide into one flat image as the final PPT route. Whole-slide bitmap fallback is forbidden unless the user explicitly accepts a non-editable preview artifact.
template-native route model:
registered theme/layout/component selection
-> PPTGenJS native object rendering
-> optional local SVG/icon/image components
-> QA and playback settings
Primary Toolchain
Engines:
svg-native: SVG page design plus SVG-to-native-PPTX conversion/assembly.template-native: TypeScript + PptxGenJS.- A reusable
ppt-builder-cli style pipeline when available
- Structured builder JSON derived from v3
slide-spec.json as the Skill 3 to Skill 4 handoff contract when project mode is used- Visual page plans, SVG pages, layout registry, and theme tokens for deterministic rendering
- Editable PPTX output
- Optional
design-lock.json, asset-manifest.json, and pptx-quality-report.json when project mode is used
- V2 project artifacts:
04-design/design-brief.json, 04-design/design-system.json, 04-design/visual-route.json, 04-design/visual-page-plan.json, 04-design/template-selection.json, 04-design/asset-plan.json, 05-build/svg-pages/, 05-build/deck-builder-input.json, and 05-build/output.pptx
Optional:
pptx-automizer for strict template-following from a provided PPTX.- Platform preview/export tools such as Quick Look, LibreOffice, PowerPoint, Google Slides, or Codex presentation preview tools only when the user explicitly asks for preview images, screenshots, PDF export, or visual render verification.
Image generation:
- If v3 marks an asset as
can_generate, call an installed image-generation skill/tool such as the platform-native image tool, nano-banana-image, or baoyu-image-gen.
- Use the full image prompt specification from v3. Do not invent unrelated prompts when v3 already provides the image purpose, subject, scene, composition, style, aspect ratio, size, and avoid-list.
- Do not hand-write ad hoc provider API code inside this skill.
- If image generation tools are unavailable, create a clearly marked placeholder and record the limitation.
- In Codex test runs, use Codex's built-in image generation path for generated bitmap assets unless the user explicitly asks for a different provider.
- Copy generated project-bound images from the platform default generated-image location into the project
assets/ folder before referencing them from deck-builder-input.json. Never leave a PPT-referenced image only under the tool's default generated-image cache.
- Do not rasterize critical labels, coupon rules, source notes, QR codes, or data into generated images. Keep those as editable PPT text and use the image as scene/atmosphere/context.
Required Input
Prefer:
PPT Project Brief v3: Slide Spec03-production/slide-production-spec.json when project mode is used- user-provided assets/screenshots/templates if any
- source files or data if charts/tables are required
v3 must include for each slide:
- page type
- final title
- visible body copy
- body sections
- layout intent
- page layout blueprint
- native component specification for every editable diagram/card/checklist/table/flow
- visual/asset recommendation
- visual necessity, visual role, visual message, and visual-to-text match
- image prompt specification for every generated image
- required assets with material status
- design note for Skill 4
- data/source requirement
- risk/placeholder
If these fields are missing across many slides, do not build blindly. Return a fix request to ppt-slide-writing.
If a slide requests a generated image but does not include a complete image prompt specification, return to ppt-slide-writing. Skill 4 must not fill that gap by free-associating an image.
Protocol Contracts
Read these references before building from project-mode artifacts:
../../references/slide-spec.md for the Skill 3 to Skill 4 data contract.../../references/design-router.md and ../../references/design-brief.md for scenario-to-design decisions.../../references/component-pack-registry.md for reusable component pack selection.../../references/layout-registry.md for stable generic layout IDs.../../references/theme-tokens.md for the design token model.../../references/svg-visual-route.md for the default SVG visual-composition route.../../references/visual-lock.md for the per-page SVG execution lock.../../references/svg-technical-standards.md for SVG/PPTX compatibility rules.../../references/image-generation-system.md for deck-wide image rendering/palette and prompt rules.../../references/svg-quality-check.md for SVG QA requirements.../../references/skill4-slide-spec-build.md for the slide-spec build sequence and layout resolution rules.../../references/visual-component-registry.md for component, icon, chart, and Mermaid rules.../../references/template-system-v2.md for theme/layout/component/template layering.
Build order:
- Read
03-production/slide-production-spec.json.
- Read each slide's
visualStrategy before choosing assets, diagrams, or components.
- Read or create
04-design/design-brief.json using the Design Router.
- Choose
visualRoute: default svg-native, optional template-native.
- Read or create
04-design/design-system.json.
- Write
04-design/visual-route.json.
- Write or update
04-design/visual-lock.json.
- Read or create
04-design/visual-strategy-report.json.
- Read or create
04-design/asset-plan.json.
- For
svg-native, create 04-design/visual-page-plan.json and page-level SVG composition specs before compiling build input.
- For
template-native, create or update 04-design/template-selection.json and map each slide to a registered renderer.
- Convert the resolved render plan into
05-build/deck-builder-input.json.
- Generate PPTX with PPTGenJS.
- Run SVG quality check when SVG pages are present, then run package-level PPTX quality check.
When the local builder is available, prefer the slide-spec entrypoint:
cd tools/ppt-builder-cli
npx tsx src/cli.ts validate-slide-spec <v3-slide-spec.json>
npx tsx src/cli.ts visual-strategy-report <v3-slide-spec.json> --out <visual-strategy-report.json>
npx tsx src/cli.ts compile-slide-spec <v3-slide-spec.json> --out <v4-build-input.json>
npx tsx src/cli.ts build-slide-spec <v3-slide-spec.json> --out <deck.pptx>
Use direct build <deck-builder-input.json> only for legacy inputs or targeted debugging.
Skill 4 may choose exact renderer coordinates, font sizes, crop rectangles, SVG composition, visual rhythm, and theme token values. It may not change page intent, visible copy, slide count, case selection, required evidence, or image purpose.
Skill 4 must respect visualStrategy:
- If
primaryVisualType is ai-generated-image, require a complete image prompt and do not replace it with Mermaid unless the image path fails.
- If
secondaryVisualType is ai-generated-image, generate and place the image in the layout slot defined by Skill 3 while keeping the primary editable component visible.
- If
primaryVisualType is mermaid-diagram, render the diagram or its PPT-native fallback visibly.
- If
primaryVisualType is ppt-native-component, prioritize editable components.
- If
primaryVisualType is chart-table, require source-aware chart/table content.
- If
primaryVisualType is real-asset or screenshot, do not fabricate substitutes.
- If
primaryVisualType is none, do not add decorative imagery. Use typography, spacing, color fields, rules, or subtle native background motifs.
- If the selected primary visual path lacks the required downstream fields, stop and route back to
ppt-slide-writing.
Project Mode Artifacts
When a project folder exists, read and write these files:
projects/<deck-slug>/
├── 03-production/slide-production-spec.json
├── 04-design/design-brief.json
├── 04-design/design-system.json
├── 04-design/visual-route.json
├── 04-design/visual-lock.json
├── 04-design/visual-page-plan.json
├── 04-design/template-selection.json
├── 04-design/asset-plan.json
├── 05-build/svg-pages/
├── 05-build/svg-native-output.pptx
├── 05-build/deck-builder-input.json
├── 05-build/output.pptx
└── 06-review/quality-report.json
Use ../../references/design-lock.md for the design lock contract and ../../references/asset-manifest.md for asset tracking.
Rules:
- Read
04-design/design-brief.json before choosing final theme, layout pack, component pack, icon policy, decoration policy, or image policy.
- Read
04-design/design-system.json before building or rebuilding when it exists.
- If no design system exists, create one from the selected theme, typography, colors, layout rules, and forbidden patterns before generating PPTX.
- If no
visual-route.json exists, create it and set route = "svg-native" unless the user explicitly chose template-native.
- If using
svg-native, create visual-lock.json and visual-page-plan.json before building. visual-lock.json must be treated as the execution truth for colors, fonts, icons, images, rhythm, and SVG restrictions.
- Read
visual-lock.json before generating or repairing each SVG page.
- If no design lock exists, include a
themeTokens block compatible with ../../references/theme-tokens.md.
- Read
04-design/asset-plan.json before inserting user-provided or generated assets when it exists.
- Update asset statuses after build:
available, generated, build-native, placeholder, or missing.
- Write the final builder input to
05-build/deck-builder-input.json when using project mode.
- Run the PPTX quality checker after build when Node.js is available.
Design Router Rule
Do not solve different deck scenarios by creating a new one-off theme for each case.
Skill 4 should combine reusable layers:
designMode + layoutPack + componentPack + iconPolicy + decorationPolicy + colorSystem + imagePolicy
If the design brief says brand-event, Skill 4 should not silently render the whole deck as a generic business/SMP-style page set. If the renderer cannot yet support the requested component pack, report the renderer gap and build the closest acceptable fallback only when the user wants a prototype.
For the svg-native route, the same reusable layers still apply, but they constrain the SVG visual language rather than forcing every page into a fixed registered template.
V2 Template Selection
Use this section only for the template-native branch or as a constraint source for the svg-native branch. It is no longer the default generation strategy.
Do not treat a theme as the whole template. Select a combination:
theme: color, type, spacing, line, page chromelayoutPack: cover/content/section/closing skeletonscomponentPack: icon cards, KPI cards, flows, matrices, Mermaid stylingiconPack: icon family and usage rules
Write this decision to 04-design/template-selection.json in project mode.
Minimum V2 implementation:
- theme:
blueprint-swiss-v2 or the closest available native theme
- layout pack:
swiss-editorial
- component pack:
business-teaching-components
- icon pack: line icons
V2 Component Rendering
Render componentPlan before inventing new visual structures.
Minimum V2 component support:
icon-card: editable card grid with consistent iconskpi-card: large numeric proof block with source noteprocess-flow: editable step flow with arrows or railscomparison-matrix: editable matrix/tablemermaid-diagram: render to local SVG/PNG when Mermaid tooling is available; otherwise use PPT-native fallback
Mermaid must remain a local component. Do not render the whole slide as Mermaid unless the slide spec explicitly requires a diagram-only page.
Current PPTGenJS-native behavior:
- If a Mermaid renderer is available, render Mermaid as a local SVG/PNG component.
- If Mermaid tooling is unavailable, render an editable PPT-native fallback from the provided syntax/fallback.
- If Mermaid is only a supporting component and the primary component uses a full-page renderer, it may not appear visually. Treat this as a spec issue and route back to
ppt-slide-writing or choose a diagram-first layout.
- For
layout.recommendedLayout = "diagram-first", compile diagramPlan as the primary component and render a visible diagram page.
Visual Strategy Execution
Skill 4 should build each slide from the visual strategy outward:
visualStrategy
-> primary visual object
-> registered layout
-> component renderer / asset slot / chart renderer / image slot
-> typography and page chrome
-> QA
Execution rules:
- Do not add images only to make the page look richer.
- Do add images when the approved v3 spec says the image carries scene, emotion, audience empathy, or product experience that text/components cannot carry.
- Do not replace a real asset or screenshot requirement with generated imagery.
- Keep factual labels, numbers, titles, source notes, and callouts editable in PPT.
- If using an AI-generated image, place it as a supporting visual and keep key explanation in PPT text.
- If using Mermaid, make the diagram visible in the chosen layout; otherwise route the spec back to Skill 3.
- If using PPT-native components, render the actual
componentPlan.content; do not use empty decorative cards.
- If using icons, use
iconPlan.items and keep icon style consistent across the deck.
- If using chart/table, build from chart/table data and source requirements; never render data as a decorative illustration.
- If no visual is requested, improve hierarchy with type, spacing, blocks, rules, and background motifs rather than inserting random art.
For the svg-native route:
- Read
04-design/visual-lock.json before each page's SVG generation or repair.
- Generate
04-design/visual-page-plan.json before creating deck-builder-input.json.
- Generate or update
05-build/svg-pages/slide-xx.svg for every slide that has a non-empty SVG role.
- Create page-level SVG compositions for backgrounds, motifs, icons, schematic shapes, callout frames, and diagrams.
- Use generated bitmap images only where they improve meaning, emotion, realism, or first impression.
- Keep SVG and images visually fused through shared palette, crop rules, spacing, and safe areas.
- Keep critical text editable in PPT, even if the SVG contains decorative micro-type.
- Do not use AI images as filler. Every image must have a page-level purpose and a complete prompt inherited from Skill 3 or the asset plan.
- If SVG generation cannot support the requested page, record the gap and repair the SVG/page plan. Do not silently fall back to the template route.
- Run
check-svg before PPTX assembly when SVG files exist. SVG errors block delivery.
Build Modes
| Mode | When to use | Rule |
|---|
create | No template supplied | Select theme family and layouts from v3 |
template-following | Company template supplied | Preserve template visual grammar |
reference-inspired | Reference deck supplied | Borrow rhythm/taste, not exact copying |
targeted-edit | Existing PPT needs specific changes | Preserve existing style and edit only scope |
Build Mode is separate from Visual Route. For example, create + svg-native is the default for new decks, while template-following + template-native is used for strict corporate-template work.
Theme Router
Choose a theme family from deck type, audience, scenario, and v3 design direction.
| Theme family | Best for | Visual behavior |
|---|
teaching-toolkit | tool training, AI tutorials, courseware, beginner workshops | clean, modern, screenshot-friendly, low cognitive load, strong steps/practice blocks |
ai-product-swiss | AI product/capability sharing, technical tutorials, demo-day style talks | Swiss-inspired, high contrast, full-screen hero cover, grid discipline, strong typographic hierarchy, restrained accent color |
business-report | work reports, business reviews, executive updates | restrained, evidence-led, chart-safe, conclusion-first |
product-launch | launches, product intros, demo keynotes | product-centered, high rhythm, large visuals, reveal moments |
knowledge-sharing | topic sharing, methods, public talks | structured, example-rich, concept/case rhythm |
education-literary | literature, humanities, close reading | warm, readable, text-centered, quote-friendly |
proposal-sales | proposals, sales decks, customer plans | pain-solution-proof-action, trustworthy polish |
If v3 recommends a theme family, use it unless it conflicts with a provided corporate template.
Style Template Registry
Theme family is not enough. A style template must define a complete visual system, not just colors.
Use this registry as the default candidate set. Start with the most appropriate template, then adapt only within its rules.
| Style template | Best for | Visual behavior |
|---|
swiss-minimal | business, consulting, AI/product teaching, technology talks | strict grid, clear typography, high whitespace, one accent color; use native icons/illustrations or meaningful images to avoid empty pages |
ai-product-swiss | AI product tutorials, technical demos, product capability sharing | Swiss grid plus product-teaching components: prompt boxes, demo strips, case walkthroughs |
business-minimal | work reports, strategy, executive updates, business reviews | restrained, evidence-led, chart-safe, conclusion-first |
bento-grid | SaaS/product feature overviews, AI tools, capability maps | modular cards, dense but organized, strong information grouping |
editorial-magazine | knowledge sharing, storytelling, industry insight, brand/person topics | magazine rhythm, large titles, image/text contrast, narrative pages |
mondrian-de-stijl | design topics, creative lectures, art/brand concept decks | black grid lines, primary color blocks, rectilinear composition |
bauhaus-functional | design systems, methods, education, engineering concepts | geometric forms, functional hierarchy, playful but orderly |
glassmorphism-tech | future tech, AI demos, SaaS showcases | dark background, glass panels, subtle glow; use sparingly |
neo-brutalism | young brands, creator talks, bold marketing concepts | strong borders, high contrast, hard shadows, expressive labels |
nordic-minimal | education, lifestyle, public-good, warm knowledge sharing | soft neutrals, calm spacing, understated visual language |
art-deco-luxe | premium brands, ceremonies, luxury launches | symmetry, black/gold/ivory, fine line ornament, high formality |
architectural-blueprint | technical plans, architecture, roadmaps, system design | blueprint grid, line drawings, annotations, precise structure |
Selection rules:
- Use
swiss-minimal or ai-product-swiss for practical AI/tool teaching unless the user asks for a different style.
- Use
business-minimal for executive reports and data-heavy reviews.
- Use
editorial-magazine for narrative knowledge sharing or public talks.
- Use
bento-grid when the deck needs many feature modules or capability cards.
- Use expressive templates such as
mondrian-de-stijl, bauhaus-functional, neo-brutalism, or glassmorphism-tech only when they fit the audience and topic. Do not use them just to look different.
- A deck uses one style template by default. Do not mix style templates page by page unless building a deliberate section contrast and the user accepts it.
Template Anatomy
Every style template must define how the following page types look. If the selected style does not define a required page type, choose the closest registered layout; do not improvise a random layout.
Required anatomy for each style template:
- cover page
- section divider
- normal content page
- method/process page
- case/example page
- prompt/demo page
- screenshot/callout page
- comparison/before-after page
- data/chart page
- checklist/risk page
- practice/interaction page
- summary page
- closing/Q&A page
For each page type, define:
- layout structure
- required components
- text density
- visual treatment
- best suited content
- what to avoid
Example anatomy:
Style: swiss-minimal
- Cover: blue-background typography cover by default: strong blue field, subtle dot/plus pattern, large white left-aligned title, small metadata; no vertical accent line by default.
- Section: oversized section number + short title, high whitespace, one accent line.
- Content: title top-left, 2-3 structured blocks, strict grid alignment; include small native icon marks, number badges, or concise image/diagram zones when content would otherwise feel sparse.
- Method/process: horizontal or vertical step flow; each step has number, title, one-line explanation.
- Case/example: left problem/prompt, right result/evidence, bottom evaluation strip.
- Comparison: two equal panels, before/after labels, center divider.
- Checklist/risk: left warning statement, right editable checklist rows.
- Closing: three takeaways or one concise closing sentence + Q&A/contact.
Swiss Minimal Theme
When using swiss-minimal, read and follow references/swiss-minimal-theme.md before building the deck.
Hard requirements:
- Use the registered-layout system and write
registeredLayout (SM01-SM10) into every swiss-minimal slide.
- Do not rely on
pageType alone; pageType describes the content job, while registeredLayout chooses the visual skeleton.
- Do not invent ad hoc Swiss body layouts during generation.
- Cover pages use
SM01, split colon titles into two lines, remove the colon, and do not show page counters.
- Product/photos must use proportional cover/crop behavior; never stretch images.
- Generated PPTX files must support manual click/keyboard advance and include compatible slide transition settings.
Blueprint Swiss PPTX Theme
When using blueprint-swiss, read and follow references/blueprint-swiss-pptx-theme.md before building the deck.
Hard requirements:
- Generate directly with PPTGenJS; do not generate HTML and convert it to PPT.
- Use
registeredLayout values from the Blueprint Swiss BP01-BP22 system.
- Use the Blueprint Swiss registered layout system
BP01-BP22; each layout has a PPTGenJS-native renderer.
- Recreate the static Swiss visual system: strict grid, IKB/single-accent color, light large typography, hairlines, square badges, dot matrices, and proportional image crop.
- Do not attempt to recreate WebGL or Motion One effects inside PPTX.
Global Style Tokens
Every style template must define tokens for:
- color
- typography
- spacing
- shape
- line
- component treatment
- page chrome and source notes
Minimum token set:
{
"color": {
"background": "",
"surface": "",
"text": "",
"muted": "",
"line": "",
"accent": "",
"accentOn": "",
"success": "",
"warning": "",
"danger": ""
},
"typography": {
"fontFamilyZh": "",
"fontFamilyEn": "",
"fontFamilyMono": "",
"coverTitle": { "size": 52, "weight": 300, "lineHeight": 1.05 },
"sectionTitle": { "size": 42, "weight": 300, "lineHeight": 1.08 },
"slideTitle": { "size": 30, "weight": 600, "lineHeight": 1.15 },
"subtitle": { "size": 15, "weight": 400, "lineHeight": 1.25 },
"body": { "size": 14, "weight": 400, "lineHeight": 1.35 },
"cardTitle": { "size": 17, "weight": 600, "lineHeight": 1.15 },
"caption": { "size": 8, "weight": 500, "lineHeight": 1.2 },
"number": { "size": 34, "weight": 600, "lineHeight": 1.0 }
},
"spacing": {
"pageX": 0.72,
"pageTop": 0.42,
"blockGap": 0.32,
"sectionGap": 0.62
},
"shape": {
"radius": 0,
"lineWidth": 0.8
}
}
Typography Rules
Use these rules adapted from the proven Blueprint Swiss and magazine PPT systems. Convert the ideas to PPTX units; do not copy HTML vw/vh values directly.
- One deck should use at most two font families: one display/body family plus optional mono/numeric family.
- Use clean sans-serif for Swiss, business, AI product, bento, and tech templates.
- Use serif title + sans body only for editorial or academic/narrative styles.
- Large titles may use lighter weight; small text must use stronger weight for readability.
- Do not use thin weight for small captions, labels, or body text.
- Chinese titles are visually heavier than English titles; reduce size or shorten text when the title is long.
- Do not solve overcrowding by shrinking text. Compress copy, split the page, or choose a layout with more capacity.
- Cover title must be visibly larger than body-page titles.
- Body text should generally stay within 13-16 pt for presentation readability.
- Caption/source text can be 7-10 pt, but must not carry essential content.
- Keep a stable hierarchy: title, subtitle/key claim, body, caption/source. Avoid more than 3-4 text levels on one page.
Suggested PPTX hierarchy for 16:9:
| Text role | Size | Weight | Notes |
|---|
| Cover title | 44-58 pt | 300-700 | weight depends on style; Swiss can be lighter |
| Section title | 36-48 pt | 300-700 | short, high impact |
| Slide title | 26-34 pt | 600-700 | stable across body pages |
| Subtitle / lead | 14-18 pt | 400-500 | do not overuse |
| Body | 13-16 pt | 400-500 | primary readable copy |
| Card title | 15-20 pt | 600-700 | short labels |
| Caption/source | 7-10 pt | 500-600 | readable but quiet |
| KPI / large number | 34-64 pt | 300-700 | use only with real numbers |
For swiss-minimal, use a slightly larger, more presentation-friendly hierarchy by default:
| Text role | Default size |
|---|
| Body-page title | 32-36 pt |
| Subtitle / lead | 14-17 pt |
| Card title | 20-24 pt |
| Card body | 13-15 pt |
| Checklist row title | 16-18 pt |
| Checklist row body | 12.5-14 pt |
| Native badge / label text | 9.5-10 pt |
swiss-minimal should not look like a sparse document page. If a slide has few words, enrich the page with one of:
- official or user-provided image crop
- native icon badges
- number rail
- thin grid/axis line
- compact comparison matrix
- native schematic illustration
Do not add decorative stock images. The visual must clarify the message, organize information, or create a stronger presentation rhythm.
Chinese title length guide:
| Title shape | Guidance |
|---|
| 1 line, <= 8 Chinese chars | can use largest title size |
| 1 line, 9-14 Chinese chars | use normal title size or split naturally |
| 2 lines, each <= 8 Chinese chars | acceptable for cover/section |
| 2 lines with long phrases | shorten the title before reducing size |
| 3+ lines | rewrite or split page; do not force-fit |
Theme Rhythm Rules
Plan visual rhythm before building.
- Cover and closing must be visually distinct from body pages.
- Avoid 3+ consecutive pages with the same visual rhythm.
- For decks longer than 10 slides, insert section/statement/hero pages every 3-5 content pages when it helps pacing.
- Alternate dense method pages with lighter case/demo/statement pages.
- Do not make the whole deck a sequence of identical cards.
- Use dark/light, sparse/dense, text/visual, and method/case changes deliberately.
- Before building, create a rhythm plan: page number -> page type -> style layout -> density -> visual role.
Layout Registry Rules
Do not invent a new visual structure for every slide. Each style template must have registered layouts for common page types.
Rules:
- Map v3
page_type and page layout blueprint to a registered layout.
- If the registered layout cannot fit the content, first compress content or choose another registered layout.
- If no registered layout fits, create a new layout only when it can be reused or clearly belongs to the style template.
- Keep layout names stable so future decks can reuse them.
- Native components from v3 must be built as editable PPT objects using the selected style's component rules.
- Do not rasterize native diagrams/checklists/flows.
Component Rendering Rules
For build_native assets from v3, Skill 4 must construct the specified components:
- flow: editable cards/steps + lines/arrows
- checklist: rows with checkbox/symbol, label, advice
- prompt box: editable text box with field labels and optional annotation
- practice card: task card + answer/template area
- comparison grid: before/after or option A/B panels
- decision tree: branches built with lines, labels, and condition cards
- capability stack/map: layers/groups with labels and short explanations
- evaluation matrix: rows/columns with editable criteria
Each component should inherit the selected template's typography, spacing, line, fill, and accent rules.
If v3 says build_native but does not specify component structure/content, return to ppt-slide-writing.
Layout Safety Gate
Before accepting a build, verify that the selected layout can carry the text. Text overlap, body-title wrapping, and cramped component cards are Skill 4 defects.
For Blueprint Swiss, use these capacity limits as a hard baseline:
| Element | Capacity |
|---|
| Cover title | may use deliberate two-line typography; visual review required when > 42 Chinese chars |
| Body slide title | must be one line; <= 18 Chinese chars preferred; 19-22 is near capacity; > 22 must be fixed upstream |
| Subtitle | <= 72 Chinese chars |
icon-card | <= 4 items; title <= 18 chars; body <= 34 chars |
kpi-card | <= 4 items; title <= 14 chars; body <= 28 chars |
process-flow / timeline | <= 5 items; title <= 8 chars; body <= 12 chars |
comparison-matrix | <= 6 items; title <= 16 chars; body <= 22 chars |
checklist | <= 5 items; title <= 22 chars; body <= 32 chars |
If content exceeds capacity, route back to ppt-slide-writing, move explanation from title into subtitle/body, split the page, or choose a higher-capacity layout. Do not make tiny text or forced title wrapping the default solution.
Layout Router
Map v3 page_type and layout intent to reusable layouts.
| Page type | Typical layout |
|---|
cover | cover-hero: full-screen first impression with large title, subtitle, speaker, date/session, and strong background or large visual |
learning-objectives | objective cards or outcome checklist |
problem-example | bad example vs better example |
concept-explain | definition + example + caution |
step-flow | horizontal/vertical step flow |
prompt-template | structured editable prompt box + annotated fields |
live-demo | prompt panel + result image/screenshot + evaluation strip |
screenshot-callout | large screenshot + numbered callouts |
before-after | two-panel comparison |
practice-task | task card + timer/steps + template |
risk-warning | warning strip + examples + mitigation |
checklist | large checklist with status icons |
summary | key takeaway blocks |
qa-closing | closing message + Q&A prompt |
Do not repeatedly use one layout unless the content intentionally repeats.
Cover Hero Rules
The cover is not a normal content page.
For formal sharing, tutorial, launch, or report decks, the cover must include:
- main title
- subtitle or promise
- speaker / organization if known
- date, session, or event context if known
- strong first-viewport signal of the topic
Cover style requirements:
- use a full-screen or large-bleed composition
- avoid small card-like inner-page layouts
- avoid dense body text
- avoid three-column card grids
- make the title the dominant visual element
- use one strong image/background/typographic system, not many small elements
If speaker/date/session are missing, mark them as placeholders in v4 rather than omitting the metadata silently.
For AI product/tutorial decks, prefer an ai-product-swiss or teaching-toolkit cover with:
- large clean typography
- one accent color
- abstract product/capability visual or real product screenshot if appropriate
- minimal metadata
- no fake product UI
Visual Style Principles
Use these distilled principles from high-quality magazine/Swiss-style slide systems:
- Choose the style first, then choose layouts. Do not mix unrelated themes.
- Use one theme family and one accent palette across the deck.
- For technology, AI, engineering, and data-driven sharing, prefer Swiss-inspired grid, strong type hierarchy, and restrained high-contrast accent.
- For humanistic or narrative sharing, a warmer editorial style may fit better.
- Plan theme rhythm before building: cover/hero, content pages, demo pages, warning pages, and closing should not all look identical.
- Avoid more than 3 consecutive pages with the same visual rhythm.
- Insert a hero/section/statement page every 3-4 pages when the deck is longer than 10 slides.
- Cover and closing pages must be designed separately from body pages.
- Image slot ratio comes from the layout. Generate or crop images to fit the slot, not the other way around.
- If a page needs images/screenshots and none are available, mark the deck as visually incomplete.
- After generation, inspect previews only when the user explicitly asks for rendered screenshots/PDF/preview images or when final visual acceptance depends on a rendered export. Do not invoke Keynote, PowerPoint, LibreOffice, or any other renderer by default.
Theme Requirements
Each theme family must define:
- cover style
- cover metadata treatment: speaker, date, session, organization
- section divider style
- normal content page style
- demo/screenshot page style
- chart/table style
- warning/checklist style
- closing page style
- typography direction
- color palette
- image treatment
- page chrome and source-note style
- theme rhythm plan
For teaching-toolkit, prioritize:
- real screenshots when required
- editable prompt boxes
- numbered callouts
- practice cards
- step bars
- before/after frames
- readable large text
- light background and high contrast
For ai-product-swiss, prioritize:
- full-screen hero cover
- large sans-serif title with strong hierarchy
- restrained palette: neutral background plus one accent
- grid-based body layouts
- sparse, high-signal text
- screenshot/callout pages with disciplined margins
- demo pages with one large visual and minimal explanation
- closing page with three crisp takeaways
AI Product Swiss Design System
Use this system when the deck is about an AI product, AI capability, AI workflow, technical product tutorial, or product demo for adult learners or professional audiences.
This is not a generic "technology blue" template. It is a disciplined product-teaching system: strong title, clear grid, low decoration, real examples, screenshots when useful, and visuals that explain the product rather than merely making the page look full.
Core Design Contract
- One slide, one job. Each page must teach, prove, compare, demonstrate, warn, or summarize one clear point.
- The audience should understand the page hierarchy in 3 seconds: title first, visual or main claim second, supporting detail third.
- Prefer product evidence over atmosphere: screenshot, workflow diagram, prompt/result pair, comparison table, or concrete example beats abstract generated art.
- Use generated images only when they make an idea easier to understand and v3 provides a complete image prompt specification.
- No decorative tech backgrounds, floating particles, random devices, fake dashboards, fake ChatGPT UI, fake logos, or irrelevant futuristic objects.
- Keep the page editable except real screenshots and generated images.
Page Type Rules
| Page type | Required structure | Visual rule | Density rule |
|---|
cover | large title + subtitle/promise + speaker/date/session metadata + one topic signal | full-bleed typography or one meaningful hero visual; no card-grid cover | title 8-18 Chinese chars or 4-9 English words when possible; subtitle <= 28 Chinese chars |
section-divider | section number + section title + one sentence transition | typography-first; optional small product/capability mark | no body paragraphs |
concept-explain | one-sentence definition + why it matters + minimum example | native diagram, screenshot crop, or icon/label system | max 3 support blocks; each block <= 28 Chinese chars |
capability-map | capability groups + what each group enables | editable map/table; avoid generated illustration | 3-5 groups only |
step-flow | action sequence + user decision points + expected output | editable horizontal/vertical flow, not decorative image | 3-6 steps; each step title <= 10 Chinese chars |
prompt-template | prompt formula + fields + example line | editable prompt box with field labels | prompt example can be longer, but annotate only key parts |
live-demo | task/prompt + result/screenshot + observation/evaluation strip | large real screenshot/result image; generated image only for output example | explanation <= 3 bullets |
screenshot-callout | screenshot + numbered callouts + key takeaway | real screenshot preferred; callouts must point to visible UI areas | 3-5 callouts |
before-after | weak example vs improved example + reason | two balanced panels; result image allowed if it proves difference | each side <= 3 bullets |
practice-task | task goal + materials + steps + success criteria | worksheet/card style; optional small example | must be actionable in class |
risk-warning | risk statement + failure example + mitigation | warning strip/table; no dramatic stock image | max 4 risks |
summary | three takeaways + next action | typography/card hybrid; no generic thank-you image | exactly 3 takeaways unless user asks otherwise |
qa-closing | closing sentence + Q&A prompt + contact/next step if known | clean closing page, not another content page | sparse by default |
Cover Rules for AI Product Swiss
The cover must look like the entry point of a product/tutorial talk, not an inner content page.
Required elements:
- Main title: product or capability name plus the teaching angle.
- Subtitle or promise: what the audience will be able to do after the session.
- Speaker, date/session/event metadata. If unknown, show a clear placeholder and record it in v4.
- One first-screen topic signal: product screenshot crop, meaningful generated concept visual, or pure typographic hero.
Layout constraints:
- Use either
left-title / right-visual or center-title / background-visual; do not use normal body cards.
- Title area should occupy at least 45% of the visual weight.
- Metadata should be small and aligned to the grid, usually bottom-left or top-left.
- Do not use more than one hero visual.
- Do not place a random image on the cover only because an image is available.
Good cover directions:
- A clean product-teaching cover: large title, short promise, speaker/date, one screenshot or product-output example.
- A Swiss typographic cover: oversized title, accent vertical rule, no image if no meaningful visual exists.
- A capability cover: one generated visual that directly represents the capability being taught, such as "prompt to image workflow", not abstract AI energy.
Bad cover directions:
- Three-card summary cover.
- Small centered title with a large unrelated image.
- Fake product interface or fake OpenAI/ChatGPT screen.
- Dense agenda text on the cover.
Body Page Rules
For normal body pages, use one of these structures:
- Claim + evidence: large conclusion title, one evidence block, one small source note.
- Explain + example: definition on left, concrete example or diagram on right.
- Steps + output: numbered steps with expected result.
- Problem + fix: weak practice, improved practice, reason.
- Principle + checklist: rule statement plus 3-5 checks.
Body page constraints:
- Title should be a conclusion or learning point, not a vague label.
- Avoid page titles such as "功能介绍", "案例展示", or "注意事项" unless the subtitle or body gives a concrete angle.
- Body copy should be scannable: prefer short blocks, labels, and callouts over paragraphs.
- Do not put more than 5 independent text blocks on one page.
- Do not use the same card layout for more than 3 consecutive pages.
Demo and Screenshot Rules
Demo pages are the most important pages in AI product tutorials.
Required structure:
- Task: what the user is trying to accomplish.
- Input: prompt, operation, or starting material.
- Output: screenshot, generated result, or expected product response.
- Observation: what the audience should notice.
Visual priority:
- Real product screenshot from user or official source.
- User-provided generated output.
- Editable mock flow with explicit "schematic" label.
- Generated illustrative output, only when it is not pretending to be UI.
- Placeholder with missing asset note.
Never create fake UI screenshots. If the exact UI is unavailable, build an editable schematic or ask for the screenshot.
Prompt Page Rules
Prompt pages should teach reusable method, not dump long prompts.
Use this structure:
- Formula: role/task + subject + constraints + style + output requirements.
- Example: one realistic prompt, with only the key parts highlighted.
- Why it works: 2-3 short annotations.
- Try next: one small variation for audience practice.
Keep prompt text editable. Use monospace-like visual treatment if the font supports it, but do not turn the prompt into an image.
Visual and Image Prompt Rules
For ai-product-swiss, Skill 4 must classify every visual before building:
product-evidence: screenshot, official product image, actual output, benchmark, chart.instructional-diagram: workflow, decision tree, prompt formula, capability map.comparison: before/after, bad/good, option A/B.generated-example: generated image used as the learning example itself.atmosphere: decorative mood image.
Only the first four are acceptable by default. atmosphere is allowed only on cover or section divider, and only when it directly reinforces the topic.
If v3 requests a generated image, the prompt must specify:
- slide purpose and exact conclusion supported
- subject and scene
- key elements to show
- composition and crop ratio
- style and color palette matching
ai-product-swiss
- target size/aspect ratio
- text policy
- must-avoid list, including fake UI/logos/unreadable text
- fallback if the generated image is weak
Reject images that are beautiful but do not explain the slide.
Typography and Spacing Rules
- Use a clean sans-serif font, defaulting to the configured deck font.
- Use strong hierarchy: title, subtitle/key claim, body, caption/source.
- Prefer large title and fewer words over small dense paragraphs.
- Leave stable margins; do not run content to the slide edge except intentional full-bleed cover visuals.
- Keep source notes and captions small but readable.
- Use accent color for hierarchy, not decoration.
Suggested hierarchy for 16:9 slides:
- Cover title: 38-54 pt depending on title length.
- Section title: 34-46 pt.
- Body title: 24-34 pt.
- Body text: 13-18 pt.
- Caption/source: 7-10 pt.
Color Rules
Default palette behavior:
- Background: near-white or deep near-black.
- Text: high-contrast ink/white.
- Accent: one primary accent, usually blue.
- Status colors: green/yellow/red only for meaning, not decoration.
- Lines and frames: subtle neutral.
Do not make the deck read as a single flat blue block. Use whitespace, black/white contrast, and limited accent instead of filling every shape with blue.
Rhythm Rules
For AI product tutorial decks longer than 10 slides:
- Start with cover.
- Add an agenda or promise page only when it helps the audience follow the session.
- Insert a section divider or statement page every 3-4 content pages.
- Alternate among concept, workflow, demo, comparison, practice, and risk pages.
- Close with three takeaways and next practice, not only "Q&A".
Recommended rhythm for a 1-hour AI tool tutorial:
- Cover
- Why this product/capability matters
- What it is and what it is not
- Core capability map
- Basic workflow
- Prompt formula
- Demo 1
- Before/after improvement
- Demo 2 or practice
- Common failure modes
- Usage boundaries and risks
- Summary and next practice
AI Product Swiss QA
Before exporting, check:
- Does the cover look like a real cover rather than a body page?
- Does every body page have one clear learning point?
- Are screenshots/results/diagrams used where they teach better than images?
- Are generated images tied to a specific slide conclusion?
- Are there any decorative images that can be removed without reducing understanding?
- Are prompt pages editable and annotated?
- Are demo pages built around input, output, and observation?
- Does the deck avoid repetitive card pages?
- Does the deck feel like an AI product tutorial rather than a generic business deck?
Asset Execution Rules
For every required asset in v3:
ready: use it and record path/source.missing_user_asset: do not fake it; ask for it or use a clearly marked placeholder if draft mode is acceptable.can_generate: generate through available image skill/tool; record prompt, tool, path, and risk.build_native: build as editable PPT shapes/text/chart/table.placeholder_ok: use a labeled placeholder and record that it must be replaced.must_verify: do not present as final until checked.not_needed: do not add decorative filler.
If a deck requires visuals and none are generated, provided, or built natively, mark the build as incomplete.
Do not generate fake product UI, fake logos, fake real people, fake news scenes, fake charts, or fake screenshots.
Visual Fit Gate
Before generating or inserting any visual, run this gate:
- What slide conclusion does this visual support?
- What exact sentence or body section does it help the audience understand?
- Is the visual role one of
explain, demonstrate, compare, prove, navigate, or focus?
- Would removing the visual make the slide less understandable?
- Is a native editable diagram, screenshot, table, or typography-only layout more accurate than a generated image?
Reject the visual if it is mainly decorative, abstract without instructional meaning, or unrelated to the page conclusion. In that case, use the v3 fallback, build a native diagram, or create a no-image layout.
Generated images are allowed only when the image prompt specification is complete:
- Purpose
- Subject
- Scene
- Key elements
- Composition
- Style
- Color palette
- Aspect ratio
- Target size
- Must include
- Must avoid
- Text policy
- Relationship to slide text
- Fallback if image is weak
After generation, inspect the image against the prompt and the slide content:
- Does the subject match?
- Does the composition fit the intended layout slot?
- Does it avoid fake UI, logos, unreadable text, or irrelevant objects?
- Does it clarify the slide instead of competing with the copy?
- Does it match the deck's theme family?
If the generated image fails, regenerate once with a tightened prompt. If it still fails, do not insert it; use the fallback from v3.
If a missing real screenshot is not essential to the learning objective, redesign the slide as a native method/diagram page instead of leaving a known blocker. For example, replace a missing product UI screenshot with an editable "operation formula", "decision tree", or "before/after instruction" page. Only keep a screenshot blocker when the user's explicit goal is to demonstrate that exact UI.
If an asset is marked can_generate but image tooling is unavailable, create a clearly documented draft-quality concept asset or placeholder and record it as fallback, not as a final generated asset. Do not repeatedly leave the same known issue unresolved when a design fallback can serve the current draft.
Editability Rules
Keep editable:
- titles and body text
- prompt boxes
- callouts
- diagrams
- checklists
- tables
- charts when practical
Raster images are acceptable for:
- generated illustrations
- screenshots
- photo-like examples
- mood/cover images
Never flatten a whole slide into one image unless explicitly accepted.
Playback and Animation Rules
Skill 4 owns presentation playback behavior because it is part of the built PPTX file, not upstream content writing.
Manual Advance
Every generated deck should support normal presenter navigation by default.
- Set every slide to allow manual advance by click/keyboard when the backend supports it.
- For PPTX XML post-processing, inject or preserve a transition node equivalent to:
<p:transition advClick="1"/>
- Do not generate kiosk-only, auto-play-only, or no-manual-advance decks unless the user explicitly asks for unattended playback.
- If auto-advance timing is requested, keep manual advance enabled unless the user explicitly says it must be locked.
Animation Policy
Use animation to improve teaching rhythm, not to decorate the deck.
Default policy:
{
"slideTransition": "subtle-fade",
"contentReveal": "none",
"defaultTrigger": "onClick",
"manualAdvance": true
}
Supported levels:
| Level | Use when | Behavior |
|---|
none | formal reports, dense reference decks, user asks for no animation | no page transition beyond manual advance |
subtle | default for tutorials, sharing, product demos | light page transition, no distracting movement |
instructional | teaching pages, process pages, checklist pages | subtle transition plus limited step/bullet reveal |
cinematic | launch/keynote moments only | stronger section/hero transitions, still restrained |
Recommended behavior:
- Cover, section divider, summary, and closing pages may use a subtle fade transition.
- Normal content pages should use no transition or subtle fade.
- Step-flow, checklist, prompt-template, and practice pages may use click-to-reveal by section when the reveal helps the audience follow the explanation.
- Demo/result pages may reveal input, output, and observation in order.
- Avoid fly-in, spin, bounce, excessive zoom, path animation, or more than one animation style on a single page.
- Keep animation optional and non-blocking: if a viewer does not support the animation, the slide should still be readable.
Element Animation Constraints
Element-level animation is more fragile than slide transitions. Use it only when the generated backend can maintain stable shape IDs and compatible PPTX timing XML.
Allowed first-phase element animations:
- title appears with page
- bullet or section reveal on click
- image/result fade-in on click
- step cards reveal left-to-right or top-to-bottom
Not supported by default:
- motion paths
- rotating/scaling objects
- complex chained timelines
- animations that hide essential content until many clicks
If the backend cannot safely implement element animation, fall back to slide-level transitions and record the limitation in v4. Do not fake animation by duplicating many near-identical slides unless the user explicitly accepts that approach.
Build Workflow
- Read v3 and inspect provided assets/templates.
- Run completeness gate: page copy, layout intent, visual recommendation, and asset status must be present.
- Choose build mode.
- Choose theme family using the theme router.
- Choose a style template from the style template registry.
- Load or define the style template anatomy and global style tokens.
- Create a theme rhythm plan: page number, page type, registered layout, density, visual role.
- Map every page type and page layout blueprint to a registered layout.
- Create an asset plan from v3.
- Run the Visual Fit Gate for every visual.
- Generate only the assets marked
can_generate and only from complete v3 prompt specifications.
- Inspect generated images; reject or regenerate weak images before inserting them.
- Build native diagrams, prompt boxes, callouts, checklists, and charts as editable elements using v3 native component specifications.
- Choose playback and animation policy from deck scenario and user preference.
- Generate PPTX using TypeScript + PptxGenJS or the selected backend.
- Apply PPTX post-processing for manual advance and supported slide transitions/element animations.
- Export rendered previews only when explicitly requested or when final visual acceptance requires rendered verification. Use the preview renderer if available; if not available, write a skipped preview report and continue with package-level QA.
- Run build QA and the PPTX quality checker when available.
- Fix visual/build issues before handing off.
- Output the full delivery package and
PPT Project Brief v4: Built Deck.
Handoff And Confirmation Policy
Step 4 is not a default confirmation gate in standard mode.
After building the editable PPTX:
- Run local build QA first. If the issue belongs to Skill 4, fix and rebuild before handing off.
- Continue automatically to
ppt-final-check when the delivery package is complete.
- Do not ask the user to confirm the built deck before final check unless the user requested manual review, preview screenshots, or a specific visual variant decision.
- If the build reveals upstream content, structure, or goal problems, route back to the owner skill instead of hiding the problem visually.
- Optional previews, screenshots, contact sheets, and PDF exports are generated only when the user explicitly asks or when final check requires rendered visual verification. Missing preview tools should be reported as a limitation, not treated as a build failure.
Required Delivery Package
Produce a task-specific folder:
ppt-delivery-package/
├── deck.pptx
├── project-brief-v4.md
├── deck-builder-input.json
├── asset-log.json
├── asset-manifest.json
├── design-lock.json
└── pptx-quality-report.json
Optional files, only when explicitly requested:
ppt-delivery-package/
├── preview-report.json
├── contact-sheet.png
└── slide-previews/
├── slide-001.png
├── slide-002.png
└── ...
Do not use Keynote, PowerPoint, LibreOffice, or any renderer to create previews unless the user asks for rendered previews or visual export. When preview export is requested, prefer the non-interactive render-preview CLI command over opening desktop presentation software.
QA Gates
Before delivery, check:
- theme matches deck type and audience
- selected style template matches deck type and audience
- global typography tokens are applied consistently
- title/body/caption sizes stay within the chosen template's hierarchy
- long Chinese titles are shortened or sized according to typography rules
- cover looks like a real cover, not an inner page
- cover metadata is present or explicitly marked as missing
- cover, section, body, case, risk, summary, and closing pages follow the selected template anatomy
- theme rhythm is planned and visible
- cover, body pages, demo pages, practice pages, and closing page have distinct appropriate layouts
- no more than 3 consecutive pages use the same visual rhythm unless intentionally repeated
- text does not overlap or overflow
- text density is appropriate for a presentation, not a document
- every slide has a clear visual focus
- required images/screenshots are present or explicitly marked as placeholders
build_native components are built from editable PPT text/shapes and match v3 native component specifications- generated images are appropriate and documented
- charts/tables have source notes
- text and shapes remain editable
- playback supports manual click/keyboard advance
- animation policy is appropriate, restrained, and recorded
pptx-quality-report.json passes or reports only accepted warnings when the checker is available- if previews were requested, contact sheet shows a coherent but not repetitive deck
If build QA finds a Skill 4 issue, fix it here and rebuild. Do not pass obvious layout errors to Skill 5.
Output Format
## PPT Project Brief v4: Built Deck
### Deliverables
- PPTX:
- Builder input:
- Asset log:
- Contact sheet:
- Slide previews:
- Output directory:
### Build Summary
- Mode:
- Toolchain:
- Theme family:
- Style template:
- Global style tokens:
- Theme rhythm plan:
- Playback/animation policy:
- Slide count:
- Layouts used:
- Cover metadata:
- Generated images:
- Placeholders:
### Asset Log
| Slide | Asset | Status | Visual role | Source / Tool | Prompt source | Editable? | Risk |
|---:|---|---|---|---|---|---|---|
For generated images, include the final prompt or a path to the prompt record. The log must be sufficient to understand why the image exists and how it was produced.
### Build QA
- Theme fit:
- Layout variety:
- Readability:
- Asset completeness:
- Visual-to-content fit:
- Generated image prompt compliance:
- Editability:
- Manual advance:
- Animation behavior:
- Preview coverage, if requested:
- Fixes applied:
- Remaining risks:
### Handoff
- Recommended next skill: `ppt-final-check`
- Pages needing user review:
- Missing materials:
- Pages that must be rebuilt after assets arrive:
Quality Bar
A good Skill 4 output is not just an editable file. It must look like the right kind of PPT for the scenario.
An AI tool teaching deck should look like a tool-training deck. A business report should look like a business report. A product launch should look like a launch. Do not reuse an unrelated old theme.
