admin/Templated-PPT-Master
1
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Require buildable projects, mockup fidelity and page hierarchy (0.9.3)

Browse Source
This commit is contained in:
Commilitia
2026-10-31 19:37:26 +08:00
parent e858fa130d
commit 25be7ebb86
10 changed files with 91 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files
SKILL.md
+12 -4
View File
@@ -2,7 +2,7 @@
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.9.2"
version: "0.9.3"
---
# PPT Template Workflow
@@ -11,6 +11,8 @@ For installation, upgrades and environment checks, read [INSTALL.md](INSTALL.md)
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](references/project-workspace.md) 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](references/production-rules.md) 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](references/content-handoff.md): 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.
@@ -46,24 +48,28 @@ Keep the user's working style above downstream defaults. For `interactive-page`,
If the manifest declares `page_library`, read [page examples](references/page-library.md). 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](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.
- **Native:** read [native authoring](references/native-authoring.md). 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](references/visual-design.md). 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](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.
Once the user confirms a page mockup, [reconstruct it faithfully](references/visual-design.md#approved-mockup-fidelity). 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](references/charts.md); for native tables, metrics, timelines and explicit linear flows read [components](references/components.md). 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](references/icon-production.md) regardless of whether drawn, generated or externally sourced.
Apply the [visual design boundary](references/visual-design.md#page-composition-and-html-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.
## Keep a portable source project
## Create and build the 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.
For every request using this Skill, read [project workspace](references/project-workspace.md) 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
@@ -76,6 +82,8 @@ Prepare useful page-library contributions as sanitized candidates with rationale
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.
After completing every page, perform the [full-page hierarchy check](references/visual-design.md#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](references/execution-and-review.md#review-after-revision).
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.