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

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.

When the user requests this Skill, creating a buildable project with its project tools is mandatory, including for a single slide. Continue a valid existing Skill project when one is supplied. After selecting the template/theme, initialize the project and author inside it; configure its real builder, retain the inputs and build the delivered PPTX through that entrypoint. Do not hand-assemble a PPTX, bypass this Skill's compiler with an ad hoc packager, or backfill an empty project around an already assembled deck. A skeleton or cached export is not buildable completion.

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

Report logic, chapter relationships and page content allocation are maintained separately by the optional report-structure Skill, including its user examples and derived rules. Consume an existing content plan through content handoff: identify what the audience should understand, necessary premises, progression within the page, key reasoning steps and the visual association between conclusions and evidence. This Skill remains independently usable: establish a minimal current-page brief when none is provided, and return consequential content changes for review at the user's agreed granularity. It does not maintain a second narrative rule or example library.

For a structure-workflow handoff, receive the page-explanation PDF together with its editable page source. Take slide text, formulas and required visual descriptions from that source, keeping speaker analysis separate; PDF text extraction is not a prerequisite. Reuse the user's confirmed review assignments, post-revision review, page/block production mode, ImageGen scope and alternatives through execution and review. Confirm only consequential choices still unresolved, together before dependent work; do not silently replace a declined tool or Agent arrangement.

For every authored or reconstructed page, apply the required text and container rules: prefer one native text frame per paragraph; any necessary fragments must remain one logical text block with unified content and layout. Keep substantive explanations out of small muted notes, distinguish different text roles by size/weight/color, and use one shared internal layout implementation per container type/variant. Authors supply content and whole-container bounds, never instance-specific child positions.

Paragraphs must also obey punctuation prohibitions at line starts/ends and must never leave a line with only one substantive character, alone or surrounded by punctuation. Check every rendered line, including the final line, and reflow the whole paragraph without breaking its logical identity. The shared paragraph helper supports measured plain-text wrapping; it does not replace actual render checks.

Spacing is fixed by the template and shared recipe for each relationship, including paragraph gaps. Content callers supply content and whole-container placement, never numeric spacing, check thresholds or per-instance variants. Check fixed values, collisions and actual visual clearance. The text-block and spacing helpers preserve these values through reflow. For mathematics, read math authoring: use the declared math font, preserve equation semantics and verify Office Math separately from ordinary text or pictures.

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 inside the project against its declared layout; the project builder invokes 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. Under the confirmed ImageGen choice, use actual visuals from the selected template/theme to make a rough current-page layout for grouping, hierarchy and reading-order feedback, then implement the authorized page. Reuse confirmed preferences within their recorded scope. 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.

Once the user confirms a page mockup, reconstruct it faithfully. Preserve its content, figures, graphics and relationship-bearing shapes, including connectors and grouping boundaries. Make necessary quality repairs while retaining the accepted meaning, composition and relationships; do not silently simplify, omit elements or treat difficult objects as dispensable decoration.

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.

Apply the visual design boundary to every route: do not lay out report pages with HTML/DOM/CSS or convert such layouts through screenshots, printing or other formats. HTML may host a JavaScript visualization itself and its necessary runtime container; surrounding page text and layout use the permitted native/SVG route.

Create and build the source project

For every request using this Skill, read project workspace and use scripts/ppt_project.py to create or continue the actual project. This is required regardless of version-control, collaboration or portability needs. 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.

Before delivery, successfully build the current authorized page set from its retained inputs and keep that project with the generated PPTX. A standalone PPTX, nominal project folder or check success without a real build does not satisfy this requirement. Production fixes go back into source and are rebuilt; application edits on disposable test copies remain separate evidence.

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.

After completing every page, perform the full-page hierarchy check: inspect font sizes, families, weights, spacing and visual content groups across the entire rendered page. Check that the main message, sections, body and supporting details form a readable hierarchy, including across containers. Repair issues and re-render before calling the page complete; no-overflow checks or isolated component checks alone are insufficient.

Follow the confirmed post-revision review assignment. For independent review, use a reviewer who did not edit that portion and provide current source, necessary evidence and criteria without author self-assessment, expected verdicts or leading explanations. The reviewer judges the current version before comparing old findings; substantive later changes need the agreed review of their affected scope. Label main-Agent self-checks and skipped reviews accurately. See review inputs.

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.