--- name: ppt-template-workflow description: Create and revise template-based editable PPTX decks, design page mockups and materials, reconstruct visual pages into native objects, and maintain portable source projects. Select one external template and theme at a time; includes its own native compiler and workflows without requiring another installed Skill. metadata: version: "0.5.0" --- # PPT Template Workflow Use **template → theme → layout** as versioned inputs. A catalog can contain multiple independent templates; activate one template and one theme at a time. This skill contains no organization, default palette, template identity or local library path. Templates and themes remain separate packages. Its native compiler, project tools and authoring guidance are bundled; no other installed Skill is required. The installer provides Python libraries and fonts. Image generation and application UI checks use host capabilities when the task needs them. ## Select and review Read the supplied catalog or manifest with `scripts/template_ref.py`. For a foundation project, start with its README consumer links. If the task needs a template and no source is specified, ask once for the source instead of guessing a global library. - `list --catalog ` discovers candidates, including proposals, with their themes and layouts. - `inspect --manifest ` exposes one candidate's status and design references. Read its specification and choose based on audience, geometry, editability and user constraints. Reuse explicit choices; ask only for consequential decisions still missing. - For v2, `export-style --manifest --theme [--layout ] [--out ]` exports complete shared style, palette, assets, asset bindings and actual paths/hashes for agent review and style alignment. It creates no slides and clearly reports proposal/approved/released status. - `resolve --manifest --theme --route native|image-rebuild --workflow interactive-page|batch [--layout ] [--out ]` binds a released v2 template. Legacy v1 manifests use `--mode ` and retain their native PPTX requirement. Read [the interface](references/template-interface.md) for manifest authoring, output fields, path roots and v1 migration. Both output commands protect existing files. Style export is allowed before release; production binding refuses incomplete or non-released packages. Do not rewrite status or invent artifacts to bypass this boundary. ## Apply the chosen template Read the selected specification, shared style, theme and relevant layout. Shared style defines canvas, typography, grid and general rules; the theme supplies named palette entries, assets and declared fill/stroke bindings for parts of suitable icons. Preserve asset proportions and scientific meaning. Exact marks, evidence colors, labels, line styles, numbers and formulas change only as explicitly permitted by the template and the user's content requirements. For SVG assets with `paint_contract`, read the exported `paint_contract_data` before preparing materials. Preserve all element/channel pairs by default; recolor only the contract's `palette` whitelist through the selected theme bindings. Keep `fixed` literals and `structural: none`, including white details and transparent openings. Multiple tokens can distinguish adjustable parts; repeated tokens express a shared semantic paint role. Check stable SVG IDs and original fill/stroke values before applying changes. Never replace colors across an entire image or infer undeclared permissions from a matching color. Stop the affected change when IDs, inherited paint or policies conflict; report the unresolved pair instead of guessing. See [the paint contract](references/template-interface.md#svg-paint-contract) and [material handoff](references/authoring-handoff.md#icon-material-handoff). Use the resolved workspace or native template path. v2 can provide a complete native authoring workspace with `native_template: null`; generate from its SVG sources and full layout roster through the bundled compiler. A manifest or style export does not replace the workspace's source objects. Keep the user's working style above downstream defaults. For `interactive-page`, finish and review the current page before advancing; page count is not batch permission. Reuse settled route, theme and backend decisions. Explain an actual conflict with its source before continuing. - **Native:** read [native authoring](references/native-authoring.md). Author the current SVG page against its declared layout and compile it with `scripts/native_export.py`, retaining Master, Layout and placeholder identities. Avoid slide-local copies that cover inherited objects. - **Page mockups and materials:** read [visual design and materials](references/visual-design.md). Use the host image-generation tool for requested raster mockups, illustrations and image edits; keep exact supplied evidence and identity assets separate from style references. Use existing vectors and the bundled `scripts/paint_asset.py` for declared SVG paint changes. - **Image-rebuild:** read [object reconstruction](references/object-reconstruction.md). Inventory the current page, separate background and foreground sources, then author native text and structural objects in the selected SVG layout. Use source material or host image editing where needed; an image assembly is not editable completion. Read [authoring handoff](references/authoring-handoff.md) for shared page inputs, icon roles and theme changes. Use [PowerPoint checks](references/powerpoint-checks.md) when application opening, rendering or actual editing evidence is needed. If a required host capability is unavailable, finish independent work and name that specific evidence gap; do not substitute an old export or change the selected backend silently. ## Keep a portable source project When the user needs version control, collaboration or rebuilding after moving devices, read [project workspace](references/project-workspace.md) and use `scripts/ppt_project.py`. Keep stable page IDs, page sources/content/notes, data, assets, the selected template snapshot and an explicit local builder together. Declare the builder's actual dependencies and fonts in the environment metadata; this skill does not install them. `init` creates an empty source skeleton with no working builder. For finalized native SVG pages, `scripts/prepare_native_project.py --project ` adds a project-local compiler, builder and environment declaration to a clean skeleton without overwriting custom builders or accepting source changes. Review the changes and explicitly `lock`; add real pages before claiming a usable deck project. The bundled builder reads finalized SVGs and notes; content/data bindings belong to the author and are not inferred. `check` validates portable paths and separate template/author locks without executing the builder; `lock` accepts intentional author changes only. `build` regenerates local receipts, invokes the declared project Python entrypoint and publishes a newly validated PPTX. `pack` carries locked source inputs without old exports or machine-local receipts. Rebuild in a relocated copy and check an intentional source/content change before claiming portability; distinguish same-device relocation from another device's rendering acceptance. Preserve the user's page-by-page workflow. Projectization does not authorize batch creation, Git initialization, commits, publishing or global tool installation. ## Verify and report Check the rendered current page and actual editable objects. Distinguish editable text/shapes/tables/charts/formulas, picture exceptions and inherited placeholders. Confirm native structure separately from appearance. Read [runtime and provenance](references/runtime-and-provenance.md) for dependencies, bundled compiler integrity, supported source boundaries and destination font checks. Deliver the PPTX with its selection record and a compact account of template version, theme, object exceptions, structural evidence, rendering and application checks. XML, screenshots and successful export alone do not prove application editing or projection acceptance.