Templated-PPT-Master/SKILL.md

name, description, metadata

name	description	metadata
ppt-template-workflow	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.	version 0.7.1

PPT Template Workflow

For installation, upgrades and environment checks, read INSTALL.md; for first use and example requests, read USAGE.md. Install this root only. Keep the preserved nested compiler attribution entry disabled in agents that recursively discover skills.

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.

Read production rules for the whole workflow. Preserve source meaning, provenance, real data, implementation claims and rebuildable inputs as requirements; use its planning and design methods as recommendations. Reuse settled choices and review at the authorized granularity. Record justified design exceptions without adding approval gates.

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 <absolute path> discovers candidates, including proposals, with their themes and layouts.
• inspect --manifest <absolute path> 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 <absolute path> --theme <id> [--layout <id>] [--out <absolute path>] 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 <absolute path> --theme <id> --route native|image-rebuild --workflow interactive-page|batch [--layout <id>] [--out <absolute path>] binds a released v2 template. Legacy v1 manifests use --mode <id> and retain their native PPTX requirement.

Read the interface 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 and 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.

If the manifest declares page_library, read page examples. Use scripts/page_library.py list to find compositions, then inspect --entry <id> --theme <id> --for-use to verify a compatible reference and its source/preview hashes. Read its rationale, method and actual preview before adapting the source. Examples do not change the active template, palette, layout roster or review sequence. Templates without a library remain supported.

• Native: read native authoring. 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. 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. 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 for shared page inputs, icon roles and theme changes. Use PowerPoint checks 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.

For data graphics read charts; for native tables, metrics, timelines and explicit linear flows read components. Their generators return data-bound component groups to compose inside an existing template slot, retaining its UI/Master/Layout. Keep sources and synchronize native payloads and visible fallback. New icons follow icon production regardless of whether drawn, generated or externally sourced.

Keep a portable source project

When the user needs version control, collaboration or rebuilding after moving devices, read project workspace 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 <path> 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.

Collaborate by page

When multiple people or Agents are authorized to share the deck, read page collaboration. The coordinator fixes the narrative, stable page IDs, style snapshot and shared inputs before assigning disjoint page directories. Workers deliver source/content/notes, private assets, previews and a page packet; one coordinator integrates order, shared resources, locks and final compilation. Adapt the bundled plan and packet examples. Parallel work does not itself authorize messaging, batch creation or shared writes.

Prepare useful page-library contributions as sanitized candidates with rationale, implementation, source/assets and preview evidence. The template maintainer reviews and versions them. Do not modify a locked vendor snapshot to publish a candidate.

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 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.