pptz

Use This Skill For

• templates/catalog.yaml to select a first-party template pack.
• REFERENCE.md for the accepted schema, diagnostics, and CLI contract.
• examples/minimal for a small known-good source deck.
• references/page-plan.md before creating page YAML for any multi-slide deck.
• references/*.md when the deck type matches technical, data-report, product-demo, or course-lecture guidance.

Required Output

deck-topic/
|-- brief.md
|-- deck.pptz.yaml
|-- pages/
|   |-- cover.page.yaml
|   `-- agenda.page.yaml
|-- images/
`-- dist/
    |-- deck.pptx
    `-- svg/

Workflow

1. Establish a short brief.md before writing YAML. If the user provided only a topic or vague goal, ask for the few missing facts that change deck structure: audience, purpose, target page count, and source material. If the provided material is sufficient, infer the brief and continue.
2. Lock these brief fields: purpose, audience, source_facts, content_policy, slide_count, visual_style, template_pack, page_rhythm, page_plan, and must_use. Later template, layout, diagram, chart, and page-density decisions must follow this brief. For multi-slide decks, read references/page-plan.md before creating page YAML.
3. Read templates/catalog.yaml and select the closest template pack by use_for, avoid_for, visual_style, and page_patterns. Prefer the 11 first-party packs before creating a custom theme: technical-dark, technical-light, data-report, course-lecture, product-demo, executive-briefing, research-report, strategy-consulting, startup-pitch, brand-editorial, and training-workshop. Copy the pack into the deck directory and edit the copied YAML sources.
4. If no template fits, create deck.pptz.yaml with deck size, theme colors, text/table/chart styles, reusable components, layouts, and ordered page paths.
5. Create pages/*.page.yaml with explicit bounds and theme tokens.
6. Put local assets under the deck directory and reference them with relative paths.
7. Compile from the deck directory:

   moon runwasm Milky2018/pptz@0.7.1 deck.pptz.yaml --out dist/deck.pptx --svg-out dist/svg

   When working inside this repository, use the local package instead:

   moon runwasm . examples/minimal/deck.pptz.yaml --out examples/minimal/dist/deck.pptx --svg-out examples/minimal/dist/svg

8. Inspect the generated PPTX in Microsoft PowerPoint. Use the SVG previews as a fast precheck for slide dimensions, major regions, cards, tables, diagrams, and chart placeholders.
9. Deliver the source directory and generated .pptx.

Current Boundaries

• Use paths relative to the deck directory. Published wasm runs with sandboxed file access.
• Stay inside the documented pptz schema. Unknown fields are rejected before 1.0, and raw OpenXML passthrough is intentionally unsupported.
• Treat writer capability errors as schema boundaries, not TODOs to work around with backend internals.
• Do not rely on line/connector shape presets, unsupported icon names, unsupported connector kinds, or unsupported shape names.
• font_family must be one PowerPoint typeface name, not a CSS fallback list. Use "Aptos" or one concrete CJK font such as "PingFang SC"; do not write "Aptos, Arial" or "MiSans, PingFang SC, Microsoft YaHei".
• Text uses strict overflow validation by default and shrink autofit by default. Split text, enlarge bounds, or choose a denser layout before weakening overflow handling.

High-Value Patterns

theme:
  text_styles:
    body:
      font_size: 22
      font_family: "Aptos"
      color: "$text"
    caption:
      extends: "$body"
      font_size: 12
      color: "$muted"
  table_styles:
    base:
      font_size: 14
      font_family: "Aptos"
      border: { style: "solid", width: 1, color: "$line" }
    compact:
      extends: "$base"
      header_fill: "$surface_alt"
      header_text_color: "$text"
      body_text_color: "$text"

layouts:
  content:
    slots:
      eyebrow:
        bounds: [72, 38, 500, 24]
        style: "$caption"
      heading:
        bounds: [72, 72, 900, 72]
        style: "$title"
    elements:
      - id: "accent"
        type: "shape"
        bounds: [48, 40, 6, 96]
        content:
          shape: "rect"
          fill: { type: "solid", color: "$primary" }

layout: "$content"
slots:
  eyebrow: "Risk model"
  heading: "风险分析"

components:
  stat_card:
    bounds: [0, 0, 180, 90]
    elements:
      - id: "card"
        type: "shape"
        bounds: [0, 0, 180, 90]
        content:
          shape: "round_rect"
          fill: { type: "solid", color: "$surface" }
          border: { style: "solid", width: 1, color: "$muted" }
          text:
            style: "$caption"
            align: ["center", "center"]
            body:
              inset: { left: 12, right: 12, top: 10, bottom: 10 }
            text: "$label"

components:
  - id: "npm_card"
    use: "$stat_card"
    bounds: [72, 160, 180, 90]
    props:
      label: "npm packages"

theme:
  table_styles:
    compact:
      font_size: 14
      font_family: "Aptos"
      header_fill: "$surface_alt"
      header_text_color: "$text"
      body_text_color: "$text"
      border: { style: "solid", width: 1, color: "$muted" }
content:
  style: "$compact"
  data:
    - ["Metric", "Q1", "Q2"]
    - ["Revenue", "100", "150"]

theme:
  chart_styles:
    report_bar:
      kind: "bar"
      legend: "bottom"
      style: 4
      data_labels: "outside_end"
content:
  chart_style: "$report_bar"
  title: "Revenue"
  data:
    - ["", "Q1", "Q2", "Q3"]
    - ["Revenue", 100.0, 150.0, 125.0]

Built-In Diagrams

• Prefer built-in diagram elements over hand-placed connectors for common relationship patterns.
• cycle: 3-8 items plus a center; best for closed loops and flywheels. It supplies generated SVG chrome while keeping labels editable.
• central_idea: exactly 8 items plus a center; best for central concept summaries. Items 2 and 6 are number-only top/bottom nodes. The fixed grid is: 01/08/07 vertically aligned, 03/04/05 vertically aligned, 01/02/03 horizontally aligned, and 07/06/05 horizontally aligned.
• hub_spoke: center concept plus surrounding capabilities.
• matrix: 2x2 comparison.
• process: linear workflow.
• architecture_flow: 3-6 ordered architecture nodes with optional boundary, callouts, and takeaway; use it instead of hand-placing boxes, rails, and labels for source-to-writer architecture slides.

- id: "ecosystem"
  type: "diagram"
  bounds: [100, 120, 1080, 460]
  content:
    kind: "cycle"
    center: { title: "生态闭环", subtitle: "关键路径在自己手里" }
    items:
      - { title: "自有语言", subtitle: "入口与抽象层" }
      - { title: "编译器 / 运行时", subtitle: "确定性与性能" }
      - { title: "包仓库 / 标准库", subtitle: "生态资产" }
      - { title: "IDE / 测试 / 验证", subtitle: "工程能力" }
    style:
      accent_color: "$primary"
      connector_color: "$muted"

- id: "idea"
  type: "diagram"
  bounds: [90, 110, 1100, 540]
  content:
    kind: "central_idea"
    center: { title: "生态闭环", subtitle: "关键路径在自己手里" }
    items:
      - { title: "代码资产", subtitle: "迁移成本" }
      - { title: "自有语言" }
      - { title: "编译器 / 运行时", subtitle: "确定性与性能" }
      - { title: "包仓库 / 标准库", subtitle: "生态资产" }
      - { title: "IDE / 测试 / 验证", subtitle: "工程能力" }
      - { title: "软件流水线" }
      - { title: "生产系统", subtitle: "运行闭环" }
      - { title: "社区反馈", subtitle: "需求入口" }

- id: "architecture"
  type: "diagram"
  bounds: [100, 150, 1080, 430]
  content:
    kind: "architecture_flow"
    boundary:
      title: "VALIDATION BOUNDARY"
      subtitle: "Diagnostics before writer checks."
      from: "parser"
      to: "loader"
    callouts:
      - { target: "source", text: "Intent stays visible." }
      - { target: "writer", text: "Resolved layout reaches PPTX." }
    takeaway: "Responsibility flow and validation ownership stay visible."
    items:
      - { id: "source", title: "Source", subtitle: "author intent", role: "input" }
      - { id: "parser", title: "Parser", role: "boundary" }
      - { id: "loader", title: "Loader", role: "boundary" }
      - { id: "writer", title: "Writer", subtitle: "resolved layout", role: "output" }

Validation

• The PPTX is generated successfully.
• The YAML sources remain editable and are delivered with the PPTX.
• Assets are local to the deck directory and referenced relatively.
• The deck does not assume unsupported schema features.
• Each slide has a visual structure: image, chart, table, icon, connector, shape composition, or built-in diagram.
• Render or preview every deck before delivery. Do not leave unreadable table text, clipped text, broken wrapping, empty semantic cards, labels floating outside their cards, or connectors crossing unrelated nodes.

moon check
moon test
scripts/validate_templates.sh --keep-artifacts
moon info