Require buildable projects, mockup fidelity and page hierarchy (0.9.3)
This commit is contained in:
@@ -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.
|
||||
|
||||
@@ -1,5 +1,11 @@
|
||||
# 版本变化
|
||||
|
||||
## 0.9.3
|
||||
|
||||
本地源码补充三项强制要求（C24—C26）：用户要求使用本Skill时必须用工程工具创建可构建项目或继续有效工程，单页任务同样适用，最终PPTX经真实工程入口构建，禁止手拼或给成品补空工程；用户确认小样后尽量忠实重建，必要质量修复保留其内容、图形及关系形状，不擅自删减；每页完成后从整页字号、字体、字重、间距与内容视觉分组检查层次，修复源、重建并查看当前画面。
|
||||
|
||||
工程接口、原生制作／重建、视觉设计、应用检查、执行复核与中文用法同步，移除“需要迁移或版本管理时才建工程”的可选表述及无工程直接导出的生产示例。不增加人工审批或固定审阅管线；模板数值、生产脚本、上游编译器、结构Skill和冻结发行包保持。本版尚未打包、提交、推送或安装，当前受管制作版本仍为0.9.2。
|
||||
|
||||
## 0.9.2
|
||||
|
||||
本地源码修订。对外部模板声明的 `slide-number` 占位符，按真实导出顺序初始化缓存，并验证每页均为原生 `slidenum` 字段、不是静态数字；复制版式的固定字段载体以兼容旧完整页面源，补齐字段唯一ID。可移动工程准备器同步携带该包装模块；上游280份编译器源保持。
|
||||
|
||||
@@ -2,6 +2,14 @@
|
||||
|
||||
安装与升级见 [INSTALL.md](INSTALL.md)。开始任务时提供内容、用途、template 来源和 theme；沿用已确认选择。一次激活一个 template 和其中一个 theme，页面再选择 layout。没有模板来源时 Agent 会询问，不会猜一个全局默认模板。
|
||||
|
||||
使用本Skill制作时，以下三项为必做要求：
|
||||
|
||||
1. 必须用Skill工程工具创建可构建项目，或继续已有有效工程；单页任务也适用。保留真实构建入口和输入，交付PPTX须通过工程构建生成，禁止绕过Skill手拼PPT或给成品补空工程。
|
||||
2. 用户确认小样后尽量忠实重建，保留其内容、图形及表示关系的形状，包括连线、箭头和分组边界。修复排版与可读性问题时不得擅自删减这些元素。
|
||||
3. 每页完成后检查全页字号、字体、字重、间距和内容视觉分组的组合效果，确认层次清楚；发现问题后修复源、重建并查看当前画面，不以“不溢出”代替层次检查。
|
||||
|
||||
具体见[工程接口](references/project-workspace.md)、[小样保真](references/visual-design.md#approved-mockup-fidelity)及[全页层次检查](references/visual-design.md#full-page-hierarchy-check)。
|
||||
|
||||
可以直接这样请求：
|
||||
|
||||
```text
|
||||
@@ -74,18 +82,19 @@ Agent 读取导出的调色板、字体、网格、素材 paint 契约、结构
|
||||
|
||||
含数学内容时读取[数学制作](references/mathematics.md)，声明专用数学字体。`math_component.py`与原生导出包装器支持结构化表达式的Office Math输出；字体、字号角色和颜色由template或显式工程样式提供。它不是通用LaTeX解析器；源SVG的线性兼容文字也不等于复杂公式预览。目标应用的渲染和实际公式编辑分别验证。
|
||||
|
||||
选定模板后先按下节初始化并配置工程，把当前获准页面及输入加入其中。最终导出走工程入口，由builder调用Skill原生编译器：
|
||||
|
||||
```sh
|
||||
"$PPT_PYTHON" "$PPT_SKILL/scripts/native_export.py" \
|
||||
--manifest /path/to/template/manifest.json --theme THEME \
|
||||
--source /path/to/project/pages/page.svg --source-root /path/to/project \
|
||||
--output /path/to/project/exports/review.pptx
|
||||
"$PPT_PYTHON" /path/to/project/tools/ppt_project.py lock --project /path/to/project
|
||||
"$PPT_PYTHON" /path/to/project/tools/ppt_project.py check --project /path/to/project
|
||||
"$PPT_PYTHON" /path/to/project/tools/ppt_project.py build --project /path/to/project
|
||||
```
|
||||
|
||||
输出文件保护既有内容，修订时使用新路径。原生页面保留 Master／Layout／占位符；图表保留数据缓存和内嵌工作簿，表格保留单元格。图标按 SVG＋paint 的 palette／fixed／structural 通道处理。图表和表格示例位于 `assets/components/`，用法见[图表](references/charts.md)和[基础组件](references/components.md)。
|
||||
构建校验输入锁并生成当前PPTX，失败时保留旧产物；不要靠已有导出物或单独调用底层编译器绕过工程。原生页面保留 Master／Layout／占位符；图表保留数据缓存和内嵌工作簿，表格保留单元格。图标按 SVG＋paint 的 palette／fixed／structural 通道处理。图表和表格示例位于 `assets/components/`，用法见[图表](references/charts.md)和[基础组件](references/components.md)。
|
||||
|
||||
## 工程和协作
|
||||
|
||||
需要可重建工程时，按[工程接口](references/project-workspace.md)执行 `ppt_project.py init`，为已定稿 SVG 准备 `prepare_native_project.py`，添加页面、讲稿及显式数据绑定，再 `lock`／`check`／`build`／`pack`。初始化只是骨架，不能把空工程当作完成的 PPT。
|
||||
每次使用本Skill都按[工程接口](references/project-workspace.md)执行 `ppt_project.py init` 或继续已有有效工程，为原生SVG路线准备 `prepare_native_project.py`，添加当前获准页面、讲稿及显式数据绑定，再 `lock`／`check`／`build`。交付时保留工程；需要源码包时再 `pack`。初始化只是骨架，只有当前输入经真实builder成功构建后才满足可构建项目要求。
|
||||
|
||||
协作时负责人固定页 ID、页序、风格和共用资源，参与者只修改分配的页面目录；负责人串行整合共享内容和锁。详见[页面分工](references/page-collaboration.md)。
|
||||
|
||||
|
||||
@@ -25,6 +25,8 @@ A user's later change affects the stated scope; revise the same arrangement and
|
||||
|
||||
## Review after revision
|
||||
|
||||
The mandatory project build, approved-sample fidelity and full-page hierarchy checks apply regardless of whether specialist review is selected. Every page must be retained in its buildable project, reconstructed without unauthorized element loss and checked as a whole for sizes, families, weights, spacing and visual grouping. These are production requirements, not an additional review assignment or approval round; follow [mockup fidelity and page checks](visual-design.md#approved-mockup-fidelity).
|
||||
|
||||
By default, the agreed post-revision review uses a fresh-context Agent who did not participate in editing that portion. Reuse the once-confirmed assignment and budget. If the user explicitly selected main-Agent checking or skipped this review, follow and label that choice; do not describe it as independent review.
|
||||
|
||||
Provide current deliverable source and preview as relevant, confirmed report/section/page goals, audience knowledge, criteria, original evidence and sufficient prior content to verify dependencies. Include precise premises, symbol meanings, conditions and source locations needed for the current use. Do not make the reviewer assume a preceding block has already explained them. A missing item in the review input is not proof that the whole report lacks it; allow source lookup, and distinguish missing evidence from an input gap.
|
||||
|
||||
@@ -2,9 +2,11 @@
|
||||
|
||||
Read the selected external template's specification, style, theme and relevant layout first. The bundled compiler accepts the native SVG workspace convention: `templates/roster.json` maps every manifest layout ID to one SVG; each source SVG declares `data-pptx-master`, `data-pptx-layout` and friendly names. Layout and master objects use their declared `data-pptx-layer`. Placeholder groups carry `data-pptx-placeholder`, a stable `data-pptx-idx`, and `data-pptx-bounds`.
|
||||
|
||||
Create or continue the [mandatory buildable Skill project](project-workspace.md) before producing the page. Keep its selected template, page SVGs, notes, assets and real builder together; even a one-slide request must produce the PPTX through that project's build entrypoint, not a hand-assembled file or standalone export with no retained project.
|
||||
|
||||
Start the current page from its selected layout source. Retain inheritance metadata, inherited objects and placeholder indices. Fill the declared placeholder carrier; put independent content objects in the intended slide layer. Do not paint opaque slide-local copies over the master logo or layout watermarks. When a template supplies a custom composition generator, inspect it and use its declared content interface rather than approximating its source geometry.
|
||||
|
||||
Use the template's discrete typography, grid, fixed content region and spacing. Resolve overflow by choosing a suitable layout, shortening content or dividing the page according to the user's workflow. Do not infer ad hoc font sizes and alignment guides from mockup pixels. Keep text as text, simple panels and connectors as geometry, and exact image exceptions as independent assets. Tables, charts and formulas must retain their required native object type; a collection of lines/text or a formula picture does not automatically qualify.
|
||||
Use the template's discrete typography, grid, fixed content region and spacing. Resolve overflow by choosing a suitable layout, or by shortening content/dividing the page within the user's authorized content scope. For an approved mockup, preserve its content, graphics and relationship-bearing shapes under [mockup fidelity](visual-design.md#approved-mockup-fidelity); necessary quality repair does not permit silently dropping elements. Do not infer ad hoc font sizes and alignment guides from mockup pixels. Keep text as text, simple panels and connectors as geometry, and exact image exceptions as independent assets. Tables, charts and formulas must retain their required native object type; a collection of lines/text or a formula picture does not automatically qualify.
|
||||
|
||||
Apply [text and container rules](text-and-containers.md) before authoring: prefer one native frame per paragraph, use a unified logical block for any necessary fragments, distinguish text functions by size/weight/color and instantiate repeated containers through a shared renderer. Inspect actual native paragraph structure after export; positional SVG spans can otherwise be split by the compiler.
|
||||
|
||||
@@ -12,20 +14,19 @@ Before emitting paragraph rows, check punctuation at both line edges and prohibi
|
||||
|
||||
Keep separate paragraphs separated by the template's fixed paragraph gap, retaining their normal internal line height. Spacing values and applicable relationships belong to the shared recipe; content callers cannot adjust them. Check exact fixed padding/gaps and actual glyph/edge clearance at normal scale. Use [text-block/spacing helpers](text-and-containers.md#spacing-and-paragraph-separation) for supported content. Explicit math markers use the [Office Math wrapper](mathematics.md), not the upstream table/chart marker kinds.
|
||||
|
||||
## Current-page export
|
||||
## Current-page project build
|
||||
|
||||
The installer provides Python 3.12+ and [runtime requirements](../runtime/requirements.txt). Metadata-only selection and project commands use Python 3.10+ without third-party packages.
|
||||
|
||||
Follow [project initialization and builder preparation](project-workspace.md#初始化与作者工作流), add the current authorized pages and their inputs, then build through the project. Source edits and quality repairs must be included in the locks before the next build:
|
||||
|
||||
```sh
|
||||
python3 /path/to/skill/scripts/native_export.py \
|
||||
--manifest /path/to/separate-template/manifest.json \
|
||||
--theme chosen-theme \
|
||||
--source /path/to/current-page.svg \
|
||||
--output /path/to/new-review.pptx \
|
||||
--notes /path/to/notes.json
|
||||
python3 /path/to/report/tools/ppt_project.py lock --project /path/to/report
|
||||
python3 /path/to/report/tools/ppt_project.py check --project /path/to/report
|
||||
python3 /path/to/report/tools/ppt_project.py build --project /path/to/report
|
||||
```
|
||||
|
||||
`--source` may repeat to assemble explicitly authorized, already authored pages in order. It does not create or design additional pages. Source filename stems must be unique. `--notes` is optional JSON mapping source stems to complete speaker-notes strings; unknown stems are rejected.
|
||||
The project builder calls `native_export.py` as its low-level compiler, or imports its `export` function. That interface retains `--manifest`, `--theme`, repeatable `--source`, `--output` and optional `--notes`; it is not a projectless production shortcut. It may assemble only explicitly authorized, already authored pages in order. Source filename stems must be unique. `--notes` maps source stems to complete speaker-notes strings; unknown stems are rejected.
|
||||
|
||||
The exporter consumes released v2 manifests and retains all native layout definitions, even for a single visible page. It requires a complete layout roster, unique layout names, declared `page_title`/`body` family roles and sizes, and the twelve PowerPoint theme color indices. Optional `style.language` supplies the presentation's BCP-47 language tag. Without it, the exporter preserves the compiler's legacy language metadata behavior; record the deck language in the project when it matters.
|
||||
|
||||
@@ -33,6 +34,8 @@ Page SVG viewBox and layout ID must match the selected template. Source assets a
|
||||
|
||||
The exporter embeds images in temporary source copies, preserving canonical source bytes. It runs the bundled attribution guard, serial compiler and declared-font preservation context, then applies the external palette/theme fonts without overwriting resolved run weights, and verifies slide/Layout/Master links, placeholders and supplied notes. Authors/renderers must apply their selected role's actual size, weight and color to the source; family identity alone does not select a text function. Existing output is protected, including a concurrent writer appearing during compilation. A failed build does not replace old output.
|
||||
|
||||
Before marking each page complete, perform the [full-page hierarchy check](visual-design.md#full-page-hierarchy-check) on its current render, covering font sizes/families/weights, spacing and visual content groups across the entire page. Compare with any approved sample, repair the source and rebuild/reinspect as needed; a successful compile is not this visual check.
|
||||
|
||||
## Template authors and review prototypes
|
||||
|
||||
Keep proposed styles and mockups outside the final template workspace until the user's design review allows formal construction. A proposal manifest cannot be consumed as a released production template. After approval, author the common style, independent themes, roster and native SVG layout definitions together; compare each theme against the same geometry and slot contract.
|
||||
|
||||
@@ -2,6 +2,8 @@
|
||||
|
||||
Treat the current visual page as a design reference with explicit source fidelity requirements. Determine the background and asset boundaries before writing native text over it; otherwise old text and newly editable text can coexist invisibly in a background picture.
|
||||
|
||||
Work inside the mandatory [buildable Skill project](project-workspace.md), including for one page. After the user confirms a sample, apply [approved-mockup fidelity](visual-design.md#approved-mockup-fidelity): retain its content, graphics and relationship-bearing shapes. Necessary quality repairs do not authorize omitting text, figures, diagram nodes, connectors or grouping boundaries.
|
||||
|
||||
Inventory the page: canvas, fixed UI, text levels, content groups, foreground images/icons, simple geometry/connectors, tables/charts, formulas, decorative patterns and intended layout slots. Keep every text value, evidence value and source asset tied to the user-provided content. Record each object's target type and source.
|
||||
|
||||
## Background and materials
|
||||
@@ -20,4 +22,4 @@ Use actual data for native charts; if source values are unavailable, preserve th
|
||||
|
||||
Preserve crop, aspect ratio and source meaning for image objects. Independently editable text over an unchanged full-page screenshot is not a reconstructed page. Keep repeated UI in inherited layers, rather than covering it with copied slide objects.
|
||||
|
||||
Compile the current SVG through [native export](native-authoring.md), then compare the actual rendered page with the accepted design at full size and a normal presentation view. Check hierarchy, density, line breaks, safe margins, alignment, clipping, asset identity and reading order. Native object checks establish object type and inheritance; they do not prove appearance. Complete the requested application checks before claiming editability acceptance.
|
||||
Build the current SVG through the project's declared builder using [native export](native-authoring.md), then compare the actual rendered page with the accepted design and element inventory at full size and a normal presentation view. Complete the [full-page hierarchy check](visual-design.md#full-page-hierarchy-check), including all font sizes, families, weights, spacing and content groups. Check density, line breaks, safe margins, alignment, clipping, asset identity and reading order. Native object checks establish object type and inheritance; they do not prove appearance. Complete the requested application checks before claiming editability acceptance.
|
||||
|
||||
@@ -4,12 +4,16 @@ Use the host's supported application UI tool, such as CUA, for PowerPoint operat
|
||||
|
||||
Open the current generated file, verify the visible filename and page thumbnails, and inspect whether PowerPoint shows a repair/recovery warning. Work on task-owned copies and preserve the user's unrelated open presentations. Do not dismiss a repair prompt as successful opening; retain the diagnostic and repair the authored source.
|
||||
|
||||
Use the current output of the mandatory [project build](project-workspace.md). Production corrections must be represented in project sources and rebuilt; edits made only in an application test copy do not become the deliverable. When the page follows an approved sample, compare it with that reference and its element inventory, preserving the accepted content and relationship-bearing shapes during repairs.
|
||||
|
||||
For rendered evidence, export this file to PDF through PowerPoint's own export dialog using the intended quality setting and a task-owned destination. Check the export exists and belongs to the current file, render its pages and inspect the images. Compare page geometry, text wrapping, typography, images, transparent edges, alignment and separators. Confirm actual PDF font identities when font rendering is disputed; a declared PowerPoint face alone does not prove which font the application rendered.
|
||||
|
||||
Use the [text/container review](text-and-containers.md#review-before-delivery): paragraph frame or justified logical-block fallback, no substantive statements in small muted notes, visible size/weight/color hierarchy within containers, one shared internal layout implementation per type/variant, compliant punctuation/singleton handling on every paragraph line, exact template-owned spacing and visible fixed paragraph gaps. Reject caller spacing overrides. Check actual glyphs/edges and visual rows, not only boxes, authored breaks or XML paragraphs. Review content/source and native objects as well as the render. A screenshot cannot prove a shared renderer or unified text source; grouping cannot prove native paragraph flow. Test fragment reflow in the application only when that editing behavior is part of the requested evidence.
|
||||
|
||||
For equations, inspect `mc:Choice/a14:m` and OMML structures separately from compatibility fallback text. Verify the declared math family on runs and operator/control properties, missing glyphs, fraction/radical/script/limit placement and clearance from adjacent prose. Actual equation editing requires selecting and changing the equation in a disposable copy; XML or a correctly shaped picture cannot establish that evidence. See [math checks](mathematics.md#verification).
|
||||
|
||||
Every completed page also requires the [full-page hierarchy check](visual-design.md#full-page-hierarchy-check): sizes, families, weights, spacing and visual grouping across the whole rendered page. Component checks, a successful export or absence of overlap do not replace it. Repair issues and inspect the updated render; report application/projection evidence at its actual level.
|
||||
|
||||
Opening and exporting are distinct from actual editing. When editing evidence is requested, use a disposable task-owned copy: select a representative text/shape/placeholder, change it through the UI, save or export, and verify the resulting independent object/content change. Check an appropriate inherited object separately if template behavior is in scope. Do not alter the authoritative source project or a user's finished original merely to demonstrate editing.
|
||||
|
||||
Report the evidence actually obtained: source/reference validation, native structure and object types, current-page rendering, PowerPoint opening, actual object editing, or projection readability. A successful export cannot establish every later level. If the host application or UI capability is unavailable, deliver the validated source and PPTX with that specific unresolved application check.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Production rules
|
||||
|
||||
These rules apply across templates and authoring routes. **Required** rules protect content, provenance, implementation claims, rebuildable inputs and the explicit text/container constraints below. **Recommended** methods can change for a content reason; record the reason and relevant validation. Template parameters remain external. Follow explicit user instructions and settled authorization; these rules add no approval gate. C16–C23 are requirements, including where C04–C06 offer broader design recommendations.
|
||||
These rules apply across templates and authoring routes. **Required** rules protect content, provenance, implementation claims, rebuildable inputs and the explicit text/container constraints below. **Recommended** methods can change for a content reason; record the reason and relevant validation. Template parameters remain external. Follow explicit user instructions and settled authorization; these rules add no approval gate. C16–C26 are requirements, including where C04–C06 offer broader design recommendations.
|
||||
|
||||
## Understand and compose
|
||||
|
||||
@@ -41,3 +41,9 @@ These rules apply across templates and authoring routes. **Required** rules prot
|
||||
- **C23 · Required:** mathematical content uses an explicitly declared mathematical font and preserves symbols, operators, scripts, fractions and grouping. Keep ordinary prose in its own text role. Use native Office Math when native equations are required; ordinary Unicode text, linear compatibility text and formula images are different object types. Verify the declared math font and the actual equation structure/rendering; do not silently substitute the prose font or claim equation editability from its appearance. See [mathematics](mathematics.md).
|
||||
|
||||
Technical helpers enforce supported inputs, path safety, object consistency and capacity. They do not infer paragraph identity, explanation importance or semantic text roles, and do not automatically enforce every text/container rule across arbitrary source files. The paragraph helper checks the lines supplied to it and reflows supported plain text; it does not intercept arbitrary SVG or PowerPoint reflow. Inspect source and current native/rendered output; export success alone is insufficient.
|
||||
|
||||
## Buildable project, approved mockups and full-page hierarchy
|
||||
|
||||
- **C24 · Required:** when the user requests this Skill, create a buildable project with its project tools, or continue a valid existing Skill project. This includes one-slide requests and revisions, regardless of whether Git collaboration or relocation is requested. Retain the real builder, selected template/compiler, sources, content, data, assets, notes and environment; generate the delivered PPTX through the declared project build. Do not bypass the Skill with a one-off PPTX packager, manually stitch XML/ZIP or assemble the final deck by hand and backfill a nominal project. An empty skeleton, cached export or metadata-only check is insufficient: the current authorized page set must build successfully from its inputs. See [project workspace](project-workspace.md).
|
||||
- **C25 · Required:** after the user confirms a mockup, reconstruct it as faithfully as possible, including its content, figures, graphics, grouping and relationship-bearing shapes. Preserve nodes, connectors, arrows, braces, enclosures, labels and other accepted elements; do not silently omit or simplify them because they are difficult to rebuild or seem expendable. Make necessary quality repairs to typography, wrapping, spacing, alignment, contrast, clipping and collisions while retaining the accepted content, composition and relationship semantics. A removal or substantive change needs the user's instruction; do not treat general quality repair as permission to reduce the sample. See [approved-mockup fidelity](visual-design.md#approved-mockup-fidelity).
|
||||
- **C26 · Required:** after every page is completed, inspect the entire current rendered page for hierarchy from font size, font family, font weight, spacing and visual content grouping. Cover all text roles and the relationships across containers, not just isolated boxes. Confirm that the main message, sections, body and supporting detail are distinguishable and groups reflect the intended meaning. Repair failures and re-render before reporting the page complete. No clipping/overlap, a successful compile or a few differently styled objects alone does not establish hierarchy. See [full-page hierarchy check](visual-design.md#full-page-hierarchy-check).
|
||||
|
||||
@@ -4,6 +4,8 @@
|
||||
|
||||
工程把正文、页面源、数据、素材、模板源、必要工具和依赖说明放在同一目录。Git 可追踪这些输入；设备相关绝对路径、缓存和导出物在运行时重建。一次工程固定一个 template 版本和一个 theme，页面顺序由 `pages` 数组表达，重排页面无需更换页面 ID。
|
||||
|
||||
用户要求使用本Skill时，必须使用本工程工具创建可构建项目，或继续使用已有的有效工程；单页、小样重建和修改任务也适用，不以需要Git协作或跨设备迁移为前提。选定template／theme后先初始化工程，再在其中维护页面源和真实builder。禁止绕过Skill编译器手拼PPT、临时拼接PPTX／XML／ZIP，或给已手拼的成品补一个空工程。交付PPTX必须由声明的工程入口从当前输入成功构建，并保留对应工程。
|
||||
|
||||
## 初始化与作者工作流
|
||||
|
||||
解析和工程管理要求 Python 3.10+，只用标准库；实际 builder 的依赖由工程自行声明。消费方明确逐页制作时，保留 `interactive-page`，不要因建立工程而自动批量创作。
|
||||
@@ -26,6 +28,8 @@ python3 /path/to/skill/scripts/ppt_project.py init \
|
||||
|
||||
该通用 builder 读取各页已完成的 SVG 和 Markdown 讲稿；`content.json`／`data` 仍是锁定作者输入，不会自动绑定到 SVG。需要数据驱动生成的消费方应提供自己的明确绑定或预处理步骤。
|
||||
|
||||
自定义预处理／builder仍须通过本Skill的相应编译路线生成最终PPTX，并声明真实输入，不能成为手拼成品的旁路。空骨架、`build_ready: false`、仅通过`check`或已有导出物都不算完成可构建项目；必须对当前获准页面实际执行`build`成功。若所选路线或环境暂时无法构建，完成可独立进行的源工作并说明具体缺口，不用手拼结果冒充工程交付。生产修复回写源后重建，PowerPoint内的临时编辑测试在独立副本中进行。
|
||||
|
||||
```sh
|
||||
python3 tools/ppt_project.py lock --project .
|
||||
python3 tools/ppt_project.py check --project .
|
||||
|
||||
@@ -14,6 +14,16 @@ Record confirmed feedback in existing project/page notes or review material: the
|
||||
|
||||
The template/shared recipe owns final geometry, typography, fixed spacing and UI. Rough positions in the draft cannot override those contracts. Rebuild the actual page with supported native objects and check its reading order, capacity and visual evidence associations. Draft feedback does not establish final native rendering, editing or projection acceptance. Follow [review after revision](execution-and-review.md#review-after-revision) for the agreed independent check of substantive changes.
|
||||
|
||||
## Approved-mockup fidelity
|
||||
|
||||
An approved current-page mockup becomes the reconstruction reference. Rebuild it as faithfully as possible: preserve the accepted content, figure/image identities, graphics, relative arrangement, proportions, grouping, emphasis and relationships within the selected template's contracts. The draft's roughness permits necessary quality repair; it does not make its accepted elements optional.
|
||||
|
||||
Before reconstruction, inventory the accepted text and visual elements in existing page source/notes, including diagram nodes, links, arrows, braces, enclosures, legend items and labels. A shape that conveys grouping, containment, comparison, direction or a dependency is content. Do not drop it, replace it with an unrelated symbol or call it disposable decoration because native reconstruction is inconvenient. Preserve other accepted graphics too; an allowed picture exception must retain the element and disclose its object type.
|
||||
|
||||
Repair typography defects, verified-text spelling, wrapping, contrast, alignment, spacing, clipping and collisions as needed. Keep substantive text, values, groups and relationship meanings intact; do not solve a quality problem by removing an accepted paragraph, figure, graph element or connection. Use the declared template fonts, discrete sizes and shared geometry rather than tracing raster artifacts. If preserving the accepted content would require a substantive redesign or omission, present that specific change for the user's decision; ordinary quality repairs need no repeated approval.
|
||||
|
||||
Compare the new full-page render with the approved sample and its inventory. Check for missing elements, changed endpoints, lost group boundaries and altered emphasis as well as appearance. Keep the accepted reference and relevant repairs in the project; do not replace the baseline with a later simplified draft without user instruction. Follow the agreed review assignment without creating a new review pipeline.
|
||||
|
||||
## Page composition and HTML boundary
|
||||
|
||||
Every title, text, formula, label, visualization and meaningful decorative group must serve the page task and, through it, the section and report goals. Choose their arrangement from the current information relationship. Pure text can serve a short question, quotation or conclusion; a picture or icon needs a useful role. Do not mechanically reuse website hero sections, selling cards or dashboards as report layouts. The page's main meaning must be readable without scrolling, hovering or clicking.
|
||||
@@ -39,6 +49,22 @@ Use generated text only as visual guidance. Native source text comes from verifi
|
||||
|
||||
Native paragraph lines must satisfy [punctuation and singleton rules](text-and-containers.md#paragraph-line-breaking-rules). Do not preserve a mockup's forbidden line-head/tail punctuation or a row containing only one character with optional punctuation; reflow the complete paragraph within the declared layout.
|
||||
|
||||
## Full-page hierarchy check
|
||||
|
||||
After completing each page, inspect its actual current render as a whole at a fitted full-page view and normal presentation scale. This check is required even for a single page or an authorized batch, and for both original authoring and mockup reconstruction. Inspect all visible text roles, including labels, chart text, captions, navigation and mathematical text, and the relationships between content containers.
|
||||
|
||||
| Dimension | Check across the whole page |
|
||||
|---|---|
|
||||
| Font size | Main title/message, section headings, body and supporting details are distinguishable and readable; no essential explanation is demoted to tiny text. Use the declared role sizes. |
|
||||
| Font family | Each role uses its declared family, including math/monospace where relevant; substitutions and inconsistent families do not disrupt the hierarchy. |
|
||||
| Font weight | Declared title/heading/body weights are realized correctly; emphasis helps the reader distinguish roles without inventing undeclared bold styles. |
|
||||
| Spacing | Line spacing, paragraph gaps, internal padding and distances between groups follow the shared recipe and visibly separate their intended levels. Check actual glyph/edge clearance. |
|
||||
| Visual content groups | Proximity, alignment, containers, headings and meaningful connectors group related material and separate different groups, including across columns and boxes. The groups match the accepted content relationships. |
|
||||
|
||||
Judge their combined effect: can the reader identify the main message, then the sections, explanations and supporting details in the intended order? Merely assigning several font sizes, passing a bounding-box check or avoiding overlap is not a pass. Uniform styling or equal gaps can flatten the page even when every object is individually legible.
|
||||
|
||||
Repair the source and shared recipes as needed, preserve the approved elements, rebuild and inspect the new render before calling the page complete. Recheck affected pages when a shared recipe changes. Record meaningful findings/repairs briefly in existing page notes or review material; no new scoring schema or specialist review is required. Application editing and projection evidence remain separate under [PowerPoint checks](powerpoint-checks.md).
|
||||
|
||||
## Material generation and transparent assets
|
||||
|
||||
For new bitmap illustrations, photos, textures or image edits, use the selected host image-generation capability. Request a transparent background when the final asset needs transparency. Preserve transparency on edits unless the user asks to change it. Use reference-image paths when all targets have paths, otherwise the smallest supported recent-image set that includes every target; do not silently omit a required target.
|
||||
|
||||
Reference in New Issue
Block a user