ppt-craft

# PPT Craft

Read this skill only when an actual PPTX will be created or changed. Read the shared `office-ppt` Skill before the first PPTX tool call.

## Execute the visual source

Honor the resolved visual source before choosing slide geometry:

- `autonomous`: treat the planner's audience- and content-derived visual DNA as a complete design source. No reference file is required, and the result must still use purposeful backgrounds, visual hierarchy, media/data treatments, and content-led composition rather than falling back to plain title-and-bullets pages.
- `text-direction`: construct from the interpreted visual DNA without claiming an exact match to an external brand or designer.
- `reference-image`: use the declared palette behavior, canvas, type character, geometry, image treatment, and motifs. Do not copy the image's exact composition or reuse the pixels unless `reference_asset_reuse: allowed`.
- `reference-deck` with `inspiration`: inspect the source deck, then rebuild the relevant design language with supported native objects. Map each output slide to a reference role or visual-DNA trait, not necessarily to an exact source page.
- `reference-deck` with `template-source`: inspect the source with `office_read` and current renders before mutation. When the requested result can be expressed through supported edits, use the authorized PPTX as the source for one separate working copy, preserve its masters/layouts/theme, and fill or adapt identified elements. Do not overlay a parallel default design. If strict template fidelity requires unsupported master/layout or duplication operations, report that boundary rather than silently switching to a vibe-matched rebuild.
- `existing-deck`: follow the source-preserving edit path below.

Before reference-led construction, make the inspection evidence explicit:

- inspiration deck: structurally inspect every source slide, then render enough
  source slides to cover opening, section, data, close, and every recurring
  layout family before locking the extracted visual DNA;
- strict template: structurally inspect and render every source slide before
  mapping each requested output role to an inherited source pattern.

These are required evidence steps, not optional review detail. When execution
is unavailable, state this complete unexecuted coverage in the production
specification instead of shortening it to “inspect the reference”. Do not claim
that either inspection occurred. Keep source-reference renders distinct from
output-deck renders: rendering every new slide does not prove that the source
reference families were visually inspected, and rendering the source does not
replace structural validation plus rendered review of every new output slide.

A strict-template result must contain the exact requested output slide count.
Select, duplicate, or remove source patterns only through supported path-based
operations. Do not keep unused template slides in a requested six-slide result;
if the exact count cannot be produced without unsafe structural mutation, report
that blocker instead of claiming a complete six-slide deck.

When the user explicitly supplies slide titles, labels, or page order, treat
those strings and that order as a verbatim content contract. Do not rename them
to satisfy autonomous assertion-title preferences. Before publication, read the
current output slides and compare every contracted string and position against
the request; repair any omission, substitution, or reordering before handoff.

User instructions and authorized reference/brand material outrank autonomous defaults. Reference fidelity is scoped by `keep`, `adapt`, and `do_not_copy`; it never authorizes copying unsupported claims, third-party logos, proprietary illustrations, or unlicensed assets.

Do not make missing factual copy a construction blocker when the user has
already authorized a draft. Use neutral editable placeholders or visibly
labeled assumptions in the planned slots, keep unsupported claims out of
assertion titles, and continue through the chosen reference-safe route. Ask
only when a source role, destructive change, or strict-fidelity decision is
actually unresolved.

## Scratch new editable deck

Use `create_pptx` as the only initial construction route. Call it exactly once with the complete slide array and `preview:false`; accept the exact path it returns, including a collision-safe rename. Call `office_review` once on that exact path with `action:"check_and_render"`, every required initial slide in `pages`, and `analysis_mode:"quality_review"`; invalid structure stops the render phase, while a valid result returns the collected image set for `ppt-review`. In the first response that receives this image batch, write one concise page-specific evidence sentence before loading `ppt-review` or making any other tool call. That sentence must record the reviewed pages, concrete pass/defect observations, and the next action. Loading review guidance never justifies rendering the same page at the same `artifact_revision` again: use the persisted sentence for unchanged pages, and after an edit rerender only affected pages. The create call's first-slide preview must not start visual review ahead of structural validation. Do not create one slide at a time, issue a second create call for the same deck, or use shell/file tools to copy or rename the result. Source-reference renders used only to understand a visual language use `office_review` with `action:"render"` and the default `analysis_mode:"understand"`; defect checking is an explicit output-review operation.

Map every storyboard card to supported native objects:

- `title` and `body` for simple layout-driven pages;
- `shapes` for assertion titles, panels, labels, dividers, diagrams, timelines, processes, and simple data visuals;
- `images` only from sandbox-allowed local paths for photography, illustration, screenshots, or supplied brand assets;
- `charts` for supplied or approved quantitative comparisons,