Use when PowerPoint must produce a polished business, consulting, product, strategy, technology, pitch, or executive presentation rather than a basic title-and-bullets deck. 适用于精美、高端、复杂、专业商业汇报和咨询风格 PPT。
Use when PowerPoint must produce a polished business, consulting, product, strategy, technology, pitch, or executive presentation rather than a basic title-and-bullets deck. 适用于精美、高端、复杂、专业商业汇报和咨询风格 PPT。
Create presentation-ready slides through narrative planning, page archetype selection, one coherent design system, deterministic layout, and visual verification.
Design Process
Read the current presentation size, theme, slide count, selected slide, existing colors, and available assets.
Convert the user's goal into a narrative arc. Every slide must have one conclusion, not merely a topic label.
Select one page archetype per slide: cover, section, statement, content, two-column, comparison, kpi, process, architecture, matrix, quote, or closing.
Choose one design system for the entire deck: modern-tech, executive-light, executive-dark, or editorial-warm.
If the current deck or user provides brand colors and fonts, pass them through designTokens instead of forcing a preset palette.
Call CreateSlides once with a coherent deck-level Scene specification. Do not generate one basic title-and-content command per page.
Put a real accessible imagePath in the CreateSlides Scene when an image is required. Never create a fake image placeholder.
Use DiscoverOfficeCapability and OfficeObjectOperation only for long-tail Office objects that the Scene compiler or high-level tools do not cover.
Observe visualVerification, slideResults, and warnings. Repair overflow, high density, missing artifacts, or failed pages before reporting completion.
Never invent market statistics, customer numbers, benchmarks, or ROI figures. Every external metric must include source; if no reliable source is available, omit the number or explicitly label it as an assumption/illustrative estimate.
Do not add generic AI branding, template watermarks, decorative circles, or filler labels unless the user or active brand template requires them.
Never copy titles, numbers, labels, or claims from this Skill's examples. Every visible string must be grounded in the user's request, the active presentation, or an explicitly identified source.
Do not pad items, steps, layers, metrics, or other collections to reach a preferred layout count. Select a composition that fits the real information quantity.
For comparison tables, provide as ; do not let generic labels imply which alternative is current, traditional, recommended, or AI-driven.
Slide Scene Contract
{"designSystem":"executive-light","slides":[{"slideType":"cover","eyebrow":"PRODUCT STRATEGY","title":"AI Native Office Agent","subtitle":"From chat assistant to autonomous document execution"},{"slideType":"comparison","title":"The two operating models optimize for different outcomes","columnHeaders":["Dimension","Current model","Target model"],"items":[{"label":"Decision flow","features":
Visual Standards
Use conclusion-style titles and 3–5 visual units per slide.
Keep one dominant focal point and a clear reading order.
Use whitespace deliberately; do not fill every region.
Avoid paragraphs longer than roughly 80 Chinese characters or 45 English words per visual unit.
Use KPI for metrics, comparison for alternatives, process for sequences, architecture for layered systems, and matrix for two-dimensional prioritization.
Use a content Scene with chart.chartType: column|line for verified quantitative comparisons or trends. Prefer editable Scene charts over screenshots of charts.
Use a content Scene with table for compact evidence grids that need more than the three-column comparison contract. Keep cells concise enough to remain readable.
Maintain the same colors, typography hierarchy, spacing rhythm, footer, and shape language across the deck.
Use variant: feature-left or mark one item with emphasis: true when a content page needs a dominant focal point instead of an equal-card grid.
Mark exactly one comparison item with emphasis: true only when the evidence supports a recommended or dominant option; the composition will allocate it stronger visual weight without inventing a verdict.
Use variant: hero-left for KPI pages when one verified metric is the main conclusion and the remaining metrics are supporting evidence.
Use variant: vertical for process pages with longer step descriptions; use the default horizontal timeline only when every step is concise.
Use variant: hub-spoke for a core-and-capabilities architecture; keep the first item as the semantic core rather than selecting it for visual convenience.
Vary composition intentionally across adjacent slides. Do not repeat the same card grid, header rhythm, or decorative motif throughout the deck.
A successful tool call is not sufficient: the rendered slide must pass visual verification.
Prefer real images, charts, logos, and cited data when accessible. If no real asset is available, use a structured information graphic and report the missing asset instead of drawing a fake placeholder.
columnHeaders
[dimension, left option, right option]
If a visual unit cannot fit at its semantic minimum font size, shorten it, split the slide, or select another composition. Do not solve density by shrinking body text into caption sizes.
For a simple verified column or line chart, put a chart object directly on a content Scene so it is laid out, rendered, verified, and rolled back with the deck. Use 1-4 items for the conclusions the chart proves.
Chart categories must contain 2-8 labels, series must contain 1-3 finite numeric arrays of equal length, and external data must provide chart.source. Signed values are supported for change, variance, profit/loss, and other zero-baseline comparisons. Do not convert qualitative claims into invented numbers.
For a compact evidence table, put table:{title,headers,rows,highlightColumn,source} on a content Scene. Use 2-5 columns, 1-6 rows, a zero-based optional highlight column, and 1-4 conclusion items.
A content Scene may use only one main visual among imagePath, chart, and table. Split the slide when more than one main visual is required.
Every matrix Scene must provide concise semantic xAxisLabel and yAxisLabel; never assume the axes are effort and impact.
Use architecture.variant: hub-spoke only when the first item is the real core platform or capability and the remaining 2-4 items are its surrounding capabilities. Use the default architecture stack for actual layers.
