返回 ppt-master
template-designer.md
根目录 / skills / ppt-master / references / template-designer.md
1 > See [`shared-standards-core.md`](./shared-standards-core.md) for common technical constraints.
2
3 # Template Designer — Template Design Role
4
5 ## Core Mission
6
7 Generate reusable structured page templates inside the workspace selected by Create Template's Create Layout or Create Deck child workflow, and write the resolved Design Spec that captures the source-derived rules that make the template reusable. For Deck, include descriptive recurring-application context; for Layout, keep structure brand-neutral and application-neutral.
8
9 > This is a standalone role: only triggered by the Create Layout or Create Deck child workflow under `/create-template`. Create Brand never invokes it. Library and project outputs share one spec schema and asset routing with scope-resolved spec filenames; this is not the template selection step in the main PPT generation pipeline.
10
11 ## Usage
12
13 - **Trigger**: `/create-template` → Create Layout or Create Deck child workflow
14 - **Workspace root**: `library` (default) → `skills/ppt-master/templates/<kind_dir>/<template_name>/`; `project` → the confirmed `<target_project>/`
15 - **Template source**: `<template_workspace>/templates/` in both scopes
16 - **Design Spec**: use the parent-resolved `<design_spec_path>` — library `templates/design_spec.md`; project `templates/design_spec.<kind>.<id>.md`
17 - **Input**: finalized template brief (output scope, target project when project-scoped, template ID, display name, kind, structural use cases or Deck application context, tone, theme mode, canvas format, optional reference assets, accepted basic template norms)
18
19 **Hard rule — scope is execution metadata**: Use `output_scope` and `target_project` to route files, but do not write either field into `<design_spec_path>` frontmatter. Do not create a new PPTX structure mode; deck/layout output declares `native_structure_mode: structured`.
20
21 **Workspace precondition**: The workflow has already resolved `<design_spec_path>` and checked all destinations. Library `templates/` is empty. The active authoring root contains no bare spec, selected-kind spec, or SVG roster; unique qualified roster-free siblings may remain untouched. When the target project already has the other structural kind, the parent workflow supplies an isolated project-shaped authoring root and owns the later Layout-over-Deck atomic install. Check collision-free destinations in `images/`, `icons/imported/`, and `exports/` when applicable. Optional directories may be absent until their first real file is written. Project scope additionally requires an initialized target project. Do not begin final writes before that all-at-once preflight passes.
22
23 When the workflow provides a PPTX reference source, the effective input package comes from the unified `pptx_template_import.py` preparation workspace and becomes:
24
25 - finalized template brief
26 - `manifest.json` — single source of truth for source-deck facts (slide size, theme, per-master themes, assets, asset map, placeholders, layouts, masters, slides, SVG file paths, page-type candidates)
27 - `native_structure.json` — stable source master/layout keys, picker names, parent-master relationships, placeholder type/index/geometry, source hash, and source-graph quality facts
28 - `source_template.pptx` — byte-preserved analysis copy for visual/package cross-checking; never a final template asset
29 - `conversion-report.json` — source-recovery and fidelity diagnostics, when present
30 - exported `assets/`
31 - `svg/master_*.svg` / `svg/layout_*.svg` — immutable layered native-payload backing; every master / layout in the deck rendered once, including ones no sample slide references
32 - `svg/slide_NN.svg` — immutable slide-local native-payload backing; do not bulk-read because opaque native payload is retained
33 - `svg/inheritance.json` — which layout / master each slide consumes
34 - optional `svg-flat/slide_NN.svg` — immutable complete-page verification backing generated only when explicitly requested; do not use it as the editable source
35 - `authoring-svg/` and optional `authoring-svg-flat/` — lightweight non-destructive IR bundles created by `svg_authoring_view.py`; each contains editable SVGs, model-readable `authoring_summary.json`, and tool-only `authoring_manifest.json`
36 - optional screenshots for visual cross-checking
37
38 PPTX import interpretation:
39
40 - Placeholder guides in master / layout SVGs are layout signals. Use `manifest.json` placeholder records for type / index / geometry / base style; do not copy dashed guide boxes into final templates unless the visual design truly uses dashed boxes.
41 - Charts, SmartArt, diagrams, and OLE objects may appear as typed placeholders in layered SVGs. In flat SVGs they may show preview images. Treat them as source intent markers, not reusable decorative assets.
42 - The asset filenames referenced by SVGs are governed by the manifest asset map. Prefer those references over inventing duplicate asset names.
43
44 Input priority for PPTX-backed template creation depends on the AI-derived internal strategy recorded as `replication_mode`:
45
46 | Mode | Authoritative inputs | Model-facing inputs |
47 |---|---|---|
48 | `standard` / `fidelity` | Finalized brief for the newly designed output; `manifest.json` for factual canvas/theme/assets | `authoring-svg/authoring_summary.json`, layered authoring SVGs, optional flat spot checks, and exported assets as visual references. Do not read `authoring_manifest.json`. Source Master/Layout topology is informational only and is not mined into output structure. |
49 | `mirror` | `manifest.json`, `native_structure.json`, and `svg/inheritance.json`; the compiler validates the tool-only authoring manifest | `authoring-svg/authoring_summary.json` plus layered authoring SVGs as the editable preservation IR; optional `authoring-svg-flat/` for complete-page verification; matching lossless `svg/` and optional `svg-flat/` only as immutable backing. |
50
51 **Mandatory — authored construction bundle**: As soon as `replication_mode`
52 resolves to `standard` or `fidelity`, and before selecting any page or template
53 contour, read [`native-shape-authoring.md`](./native-shape-authoring.md) and
54 [`preset-shape-vocabulary.md`](./preset-shape-vocabulary.md) completely and
55 retain both for the active authoring context. Do not load this bundle for
56 `mirror`; it preserves source-owned geometry and never selects or authors
57 replacement contours.
58
59 Use the compact facts in `manifest.json` for orientation. Open screenshots or the original PPTX only for visual cross-checking.
60
61 **Native structure output**: Always set `native_structure_mode: structured`.
62
63 **Hard rule — native objects are compiled output**: Treat Theme, Master,
64 Layout, and Placeholder as PowerPoint implementation objects, not template
65 kinds. Layout owns topology, placement, semantic text roles, and spatial text
66 behavior. Deck identity owns paint, typeface identity, and fixed identity
67 assets; its application context describes the recurring presentation family. Under
68 downstream `layout` scope, resolve final placeholder formatting from the Layout
69 roles plus the confirmed identity, reading mode, and type scale; downstream
70 `mirror` scope preserves literal source formatting and text topology. Compile
71 the applicable rules into the same native graph without merging their source
72 ownership.
73
74 | Mode | Output structure contract |
75 |---|---|
76 | `standard` / `fidelity` | Author project-canonical SVG prototypes and an intentional new Master/Layout/slot system. Source visual language and assets may guide the design, but source ownership, keys, picker names, parent relationships, placeholders, and repeated Slide-local elements do not define or seed the output topology. Choose page-fit contours from the full native vocabulary before their authoring forms; keep exact native atoms independent, materialize a Boolean result only where one contour requires it, and use freeform last. |
77 | `mirror` | Materialize a new workspace from the validated source graph one-to-one: keep the Master/Layout identities and parentage, slide assignments, placeholder type/index/bounds, and supported visual/native-object facts that are actually present. Edit the authoring IR; materialization may rehydrate converter-supported native payload only for unchanged source refs. Mechanical normalization maps fixed-layer source groups into the direct atoms required by the current explicit SVG contract while preserving ownership, paint order, and appearance; it must not invent missing facts or semantically redesign the graph. |
78
79 Every page remains a complete standalone SVG preview.
80
81 **Authored preset rule**: In `standard` / `fidelity`, when one registered
82 PowerPoint preset exactly expresses one complete object, use
83 `preset_shape_svg.py` as defined by
84 [`native-shape-authoring.md`](./native-shape-authoring.md). Its compact
85 canonical `<g>` is one semantic atom after validation: it may remain
86 Slide-local, serve as the one direct carrier of an `object` slot, or carry
87 Master/Layout fixed-layer ownership. This is the only `<g>` exception to the
88 fixed-layer atomicity rule; ordinary groups remain forbidden there. Preset
89 paint comes from the confirmed brief and `<design_spec_path>`
90 color scheme. Do not copy an expanded import carrier/preview/fingerprint
91 bundle into an authored template. `mirror` instead preserves the supported
92 expanded lossless source representation. The exact syntax and validation
93 contract remain owned by
94 [`shared-standards-core.md`](./shared-standards-core.md) and the native-shape reference.
95 When one preset is insufficient, apply the same reference's compound-page gate:
96 keep faithful atoms independent unless one contour requires Boolean
97 materialization, then use freeform only if neither construction succeeds.
98
99 **Hard rule — complete mirror graph**: Preserve every supported source Layout represented by the validated import,
100 including Layouts unused by source Slides. Emit one complete source-page
101 prototype per source Slide and one definition-only
102 `layout_<layout_key>.svg` prototype for each otherwise unrepresented Layout.
103 The definition prototype carries the exact parent Master identity, Layout
104 identity, fixed atoms, and placeholder contract but is not a generated page.
105 This also retains a source Master that is reachable only through unused Layouts.
106 Never silently drop or merge an identity, and never invent a carrier page.
107
108 **Hard rule — no duplicate authored Layout contracts**: In `standard` / `fidelity`, distinct output Layout keys must differ in fixed Layout atoms or slot topology/type/index/bounds/binding. Topic, sample wording, or Slide-local content alone never justifies another authored key. Mirror keeps source Layout identities even when two source contracts are visibly equivalent.
109
110 **Downstream boundary**: Stage 1 independently confirms the current communication contract. Strategist then inspects the installed prototypes, the Deck's descriptive application context, and the current content to author one application plan. It records `mirror`, `layout`, or `style` and, where applicable, `strict` or `adaptive` only as internal exporter values. Explicit user language overrides AI judgment, but the confirmation UI never asks the user to choose these implementation labels. Template_Designer does not preselect that project-level plan.
111
112 For `mirror`, `<design_spec_path> §V` must be followed by a `Source Preservation Map` that records each source slide's Master/Layout assignment and output file. The map is evidence of one-to-one preservation, not a design-decision log. `standard` and `fidelity` record only their newly authored output roster and structure; do not add a source-topology disposition table.
113
114 ---
115
116 ## Page Roster
117
118 The output page set is determined by the confirmed natural-language creation intent. Template_Designer derives one internal `replication_mode` so the deterministic authoring tools can execute:
119
120 | Mode | When to use | Roster |
121 |------|-------------|--------|
122 | `standard` (default internal strategy) | The requested result is a clean, reusable, compact system | Cover, chapter, ending, optional TOC, and one or a small explicitly required set of distinct content Layouts; typically 4–6 prototypes |
123 | `fidelity` | The natural-language intent calls for broader, source-aligned but newly designed coverage | Canonical roles plus intentionally designed variants that cover the useful source composition range |
124 | `mirror` | The natural-language intent calls for preserving validated native source facts | One SVG prototype materialized from the authoring IR per source slide, named `<NNN>_<page_type>.svg` by source order |
125
126 **Hard rule — mode controls authorship**: `standard` and `fidelity` create new SVG documents and their own Master/Layout system. `mirror` maps the validated imported source contract into a new workspace and must not reauthor, distill, reinterpret, or supplement its structure.
127
128 ### Standard mode
129
130 | # | Filename | Purpose | Description |
131 |---|----------|---------|-------------|
132 | 01 | `01_cover.svg` | Cover | Fixed structure: title, subtitle, date, organization |
133 | 02 | `02_chapter.svg` | Chapter page | Fixed structure: chapter number, chapter title |
134 | 03 | `03_content.svg` | Content page | Flexible structure: only defines header/footer; content area freely laid out by AI |
135 | 04 | `04_ending.svg` | Ending page | Fixed structure: thank-you message, contact info |
136 | -- | `02_toc.svg` | Table of contents | Optional: TOC title, chapter list (number + title) |
137
138 **Default — compact authored roster (may override when the confirmed Deck application requires distinct roles)**: Keep Layout content pages structurally flexible. For Deck, add only the distinct prototypes needed to express its confirmed recurring narrative/content roles; do not manufacture variants from hypothetical future uses.
139
140 **Intent-derived compact variants**: `standard` may include more than one Layout for the same canonical role when the brief requires genuinely different reusable structures, such as two-column evidence and three-card KPI content. Keep the roster compact and brief-driven rather than mining the source page set. When siblings exist, suffix every sibling (`03a_content_two_col.svg`, `03b_content_three_card.svg`) instead of treating one arbitrary variant as the unsuffixed default. This does not require `fidelity`; derive `fidelity` when the broader roster is driven by complete PPTX/SVG page evidence.
141
142 **Naming note**: The numeric prefix is the template's own presentation order. Its base sequence stays contiguous; sibling variants share their parent's number only through unique lowercase suffixes such as `03a` / `03b`. When the optional TOC page is included it takes `02_toc.svg` and the later types shift by one: `01_cover`, `02_toc`, `03_chapter`, `04_content`, `05_ending`. Numbers carry no meaning across templates — tooling derives the page type from the token after the underscore, so both spellings of each type are equivalent.
143
144 ### Fidelity mode
145
146 When the derived implementation writes `replication_mode: fidelity`, design a broader reusable roster that stays close to the source's visual language and useful composition examples. The output Master/Layout system is authored independently from source topology.
147
148 **Variant naming**: append a lowercase letter suffix to the parent type's index, preserving sort order:
149
150 | Parent type | Example variants |
151 |-------------|------------------|
152 | Chapter | `02a_chapter_full.svg`, `02b_chapter_minimal.svg` |
153 | Content | `03a_content_two_col.svg`, `03b_content_data_card.svg`, `03c_content_quote.svg` |
154 | Ending | `04a_ending_thanks.svg`, `04b_ending_contact.svg` |
155
156 Extension page types beyond the canonical four (transition / appendix / disclaimer / divider) take the next free index after the roster: `05_section_break.svg`, `06_appendix.svg`, `07_disclaimer.svg` in a four-page roster (one higher when `02_toc` is present).
157
158 **Roster decision**:
159
160 - Choose variants from useful visual composition types such as two-column content, hero image, icon grid, data card, and quote
161 - Keep only variants that add a genuinely useful authored composition; source Layout keys and repeated source chrome are not clustering inputs
162 - Design each variant's Master/Layout/slot contract directly from its intended reusable behavior
163 - Record every emitted page in `<design_spec_path> §V Page Roster`; in library scope, `register_template.py` generates the corresponding index entry from `<template_workspace>/templates/*.svg`. Project scope skips registration
164
165 > Variants reuse the parent type's placeholder set — see §4 (Placeholder Reference) below.
166
167 ### Mirror mode
168
169 When the derived implementation writes `replication_mode: mirror`, materialize a new template workspace from validated imported facts rather than designing a new system:
170
171 - Kind eligibility: Create Layout mirror is legal only when the validated source contract is already brand-neutral and application-neutral. If supported source facts retain organization-specific identity or reusable application policy, stop and return to Create Template dispatch: use `standard` / `fidelity` to author a new Layout, or Create Deck to retain those facts. Removing, repainting, retyping, or discarding application rules is never mirror.
172 - Model-facing authoring source: `authoring-svg/authoring_summary.json`, layered `authoring-svg/*.svg`, `svg/inheritance.json`, and `native_structure.json`. Do not read `authoring-svg/authoring_manifest.json`; materialization validates it internally. When present, use `authoring-svg-flat/` only for full-page verification. Matching lossless `svg/` and optional `svg-flat/` files are immutable backing; materialization resolves only the layered backing.
173 - Precondition: the import evidence identifies every source Master/Layout, parent relationship, picker name, placeholder contract, and fixed visual layer. Stop only when required facts or supported geometry are missing; unused identities are not a stop condition.
174 - Output: `<template_workspace>/templates/<NNN>_<page_type>.svg` for every source slide, plus `layout_<layout_key>.svg` for every source Layout unused by all source slides. `<NNN>` is the zero-padded source slide index (3 digits) and `<page_type>` is derived from `manifest.json` `pageTypeCandidates` — `cover` / `toc` / `chapter` / `content` / `ending`. When the page-type heuristic is ambiguous, fall back to `content`. Preserve source slide order via the numeric prefix; definition-only files are not generated pages.
175 - Required preservation: preserve source Master/Layout keys and picker names, Layout-to-Master parentage, slide assignments, placeholder type/index/bounds, supported native-object metadata, geometry, decoration, sprite-sheet wrappers, original example text, chart previews, fonts, effects, and paint order whenever the importer represents them.
176 - Allowed normalization: add or normalize explicit root declarations and asset paths, and recursively expand fixed Master/Layout group wrappers into direct atoms. The mapping must remain one-to-one at the ownership level and must not change paint order or appearance.
177 - Forbidden: commonality extraction, semantic synthesis, merging, splitting, promotion, demotion, renaming, re-parenting, decorative simplification, placeholder invention, or replacement of supported source-native metadata / SVG fallback with a model-authored approximation.
178 - `<design_spec_path>` §V Page Roster lists every emitted file and marks definition-only prototypes explicitly. `Source Preservation Map` records each source-slide assignment plus every unused Layout definition and its parent Master.
179
180 **Mirror consumption boundary**: `replication_mode: mirror` describes source-to-workspace fidelity and only makes literal downstream reuse technically possible. Strategist independently derives the application plan from the current communication contract, content, actual prototype roster, and any explicit natural-language instruction. It may select, repeat, skip, reorder, or reorganize prototypes; no internal scope forces source page count, source order, or one output slide per source slide.
181
182 **What mirror is not**: a redesign, topology-cleanup, or recovery mode. It may mechanically transcode the imported representation into the current explicit SVG/package contract, so byte identity is not promised. Charts, SmartArt, OLE objects, and EMF / WMF media that fail to round-trip in `pptx_template_import.py` will fail the same way in mirror. If the import workspace has missing media or unsupported objects, mirror inherits those gaps — report them before materialization begins.
183
184 ---
185
186 ## Template Design Specifications
187
188 ### 1. Must Generate design_spec.md
189
190 **Scope rule — package-specific rules only.** A Deck `design_spec.md` describes its recurring application plus integrated identity and structure. A Layout spec describes only brand-neutral reusable structure and may state supported content shapes/delivery settings without owning a communication objective or narrative. Neither restates generic constraints — those live in the canonical references and are already loaded by every downstream role:
191
192 - Always-on SVG rules and conditional-module routing → [`shared-standards-core.md`](./shared-standards-core.md)
193 - Generic layout pattern library, spacing bands, font-size ratio bands → [`strategist.md`](strategist.md) (used when authoring the **project** design spec)
194 - Canonical placeholder vocabulary → §4 below
195 - Content methodology (pyramid / SCQA / MECE) → [`strategist.md`](strategist.md)
196
197 Re-declaring any of these in a template `design_spec.md` is noise — Strategist already has them in context, and duplication forces every relaxation to sweep N templates instead of one source. **If a rule is generic, omit it. If this template breaks a generic rule, write only the deviation.**
198
199 **Required skeleton by kind:**
200
201 The frontmatter is portable across library and project scope. Do not add
202 `output_scope` or `target_project`; those belong only to the workflow execution
203 brief. Use `deck_id` or `layout_id`; do not invent a generic `template_id`
204 field that the registrar cannot bind to its library kind.
205
206 **Deck**:
207
208 ```markdown
209 ---
210 deck_id: <id>
211 kind: deck
212 category: brand | general | scenario | government | special
213 summary: <one-line recurring presentation family and intended outcome>
214 keywords: [tag1, tag2, tag3]
215 primary_color: "#......"
216 canvas_format: ppt169
217 canvas_width: 1280
218 canvas_height: 720
219 canvas_viewbox: "0 0 1280 720"
220 # Required when a PPTX/SVG source canvas is known; keep equal to canvas_* unless explicitly normalized.
221 source_canvas_width: 1280
222 source_canvas_height: 720
223 source_viewbox: "0 0 1280 720"
224 replication_mode: standard | fidelity | mirror
225 # Required for every deck/layout template. Source packages remain analysis-only.
226 native_structure_mode: structured
227 page_count: <N>
228 # Optional — only when this template overrides canonical placeholder vocabulary.
229 # Omit the map when canonical vocabulary is sufficient; use [] for an intentional zero-marker page.
230 # placeholders:
231 # 01_cover: ["{{TITLE}}", "{{SUBTITLE}}", "{{BRAND_LOGO}}"]
232 # 03_content: ["{{KEY_MESSAGE}}", "{{CONTENT_AREA}}"]
233 ---
234
235 # [Template Name] — Design Specification
236
237 ## I. Template Overview
238 | Application context | Definition |
239 |---|---|
240 | Recurring presentation family | <repeatable situations this Deck serves> |
241 | Intended audiences and outcomes | <who it serves and what the presentation should enable> |
242 | Delivery and reading assumptions | <presented / close-read / handoff / mixed> |
243 | Representative narrative/page roles | <roles commonly present in this presentation family; descriptive, not mandatory> |
244
245 - Design tone, theme mode (light / dark / mixed), and the visual identity visible at a glance
246
247 ## II. Color Scheme
248 - HEX values with role labels (primary / accent / background / text / etc.)
249 - Brand-specific application rules when present (e.g. "KPI cards rotate blue→green→red→yellow")
250
251 ## III. Typography (omit without template-owned typeface identity)
252 - Per-role stacks for identity (display serif, brand face, etc.)
253 - A non-preinstalled face may lead only after user-confirmed target installation/approved install; no auto-embedding
254 - Otherwise export a safe face; unavailable proprietary faces stay references. CSS tails aid preview, not deterministic PowerPoint fallback
255 - Body baseline px (informational; `spec_lock.md` owns the actual values per project)
256
257 ## IV. Signature Design Elements
258 - Decorative motifs that ARE this template — top bar, gradient underline, logo treatment, brand emblem placement
259 - Source-derived layout grammar — grid / column rhythm, page chrome, image zones, crop/clip behavior, scrim/overlay or baked-alpha treatment, and density rhythm that make the template recognizable
260 - Optional XML snippet for any reusable component unique to this template
261
262 ## V. Page Roster
263 One row per emitted SVG describing what this template's version of cover / chapter / content / ending looks like: background treatment, decorative anchors, layout rhythm, image behavior, content density, intended role, reusable slots, and structural capacity. Do not add required/optional/repeatable status or fixed/replaceable/example-only content policy. For `standard` / `fidelity`, record the newly authored Layout key and PowerPoint picker name. For `mirror`, record the preserved source Master/Layout keys and picker names without redesigning them. Roster entries must match the actual SVG files on disk.
264
265 For `mirror`, add `### Source Preservation Map` immediately after the roster with columns `Source slide`, `Source Master`, `Source Layout`, `Output SVG`, and `Preservation status`. This is a one-to-one mapping record. Do not add synthesis rationale or source-structure disposition rows to `standard` / `fidelity` templates.
266
267 ## VI. Assets (omit when none)
268 Logos, cover backgrounds, brand textures bundled with the template package — file name, dimensions, intended usage.
269
270 ## VII. Placeholder Overrides (omit when none)
271 Reference the `placeholders:` frontmatter declaration and explain the rationale (e.g. "consulting decks lead with `{{KEY_MESSAGE}}` instead of `{{PAGE_TITLE}}`").
272 ```
273
274 **Layout**:
275
276 ```markdown
277 ---
278 layout_id: <id>
279 kind: layout
280 category: general | scenario | government | special
281 summary: <one-line structural use case>
282 keywords: [tag1, tag2, tag3]
283 canvas_format: ppt169
284 canvas_width: 1280
285 canvas_height: 720
286 canvas_viewbox: "0 0 1280 720"
287 # Required when a PPTX/SVG source canvas is known.
288 source_canvas_width: 1280
289 source_canvas_height: 720
290 source_viewbox: "0 0 1280 720"
291 replication_mode: standard | fidelity | mirror
292 native_structure_mode: structured
293 page_count: <N>
294 page_types: [cover, toc, chapter, content, ending]
295 # Optional vocabulary override.
296 # placeholders:
297 # 01_cover: ["{{TITLE}}", "{{SUBTITLE}}"]
298 ---
299
300 # [Layout Name] — Design Specification
301
302 ## IV. Signature Design Elements
303 - Structure-specific grid, zones, page chrome, image behavior, density rhythm, semantic text roles, alignment/wrapping/capacity behavior, and slot conventions
304 - Neutral preview paint/font/size may expose hierarchy, but it is not a color, typeface, or final type-scale identity
305
306 ## V. Page Roster
307 One row per emitted SVG with Layout key, picker name, supported content shape, and slot behavior. Roster entries must match the actual files on disk.
308
309 For `mirror`, append the same `### Source Preservation Map` required above.
310
311 ## VII. Placeholder Overrides (omit when none)
312 Reference the `placeholders:` frontmatter declaration and explain the structural vocabulary deviation.
313 ```
314
315 **Layout boundary**: Omit Template Overview, Color Scheme, Typography, Logo,
316 Voice & Tone, and Icon Style. A scenario category records geometric fit only.
317 Structural text roles, alignment, wrapping, and capacity remain valid Layout
318 rules; final font families, weights, colors, and absolute sizes do not.
319 Do not prescribe communication objectives, audience outcomes, required
320 narrative order, fixed boilerplate, or example-content retention. The
321 frontmatter `summary` carries concise structural selection context; the
322 deck-only Template Overview remains the application segment read during
323 template application.
324
325 Sections to **omit** from template `design_spec.md` (sourced elsewhere — listing them here is noise):
326
327 | Don't write | Source |
328 |---|---|
329 | Always-on SVG rules and conditional-module routing | `shared-standards-core.md` |
330 | Generic layout pattern library (centered card / three-column / timeline / …) | `strategist.md` §4 |
331 | Generic spacing bands (margin 40-60px, card gap 20-32px, etc.) | `strategist.md` §4 |
332 | Generic font-size hierarchy (cover 2.5-5x body, page title 1.5-2x, …) | `strategist.md` §g |
333 | Canonical placeholder table (`{{TITLE}}`, `{{PAGE_NUM}}`, …) | §4 below |
334 | Content methodology (pyramid / SCQA / MECE) | `strategist.md` |
335 | "Usage Instructions" boilerplate (copy template / select page / …) | `create-template.md` |
336 | Created Date / Page Count rows | not a library-level field |
337
338 When rewriting an existing template that contains an omitted generic section,
339 delete it rather than leaving a pointer. Keep a template-specific boundary only
340 inside the package-owned section it qualifies (asset system, motif, image
341 treatment, or page roster); do not preserve a generic technical-rules heading.
342
343 ### 2. Inherit Design Specification
344
345 Templates must strictly follow the finalized template brief and the generated `<design_spec_path>`:
346 - **Canvas dimensions**: `canvas_format` is not enough; root SVG `viewBox` matches `canvas_viewbox` in the design spec. Root `width` / `height` are optional compatibility attributes and are not PPT Master canvas authority.
347 - **Source canvas**: when a PPTX/SVG reference is used, record `source_canvas_width`, `source_canvas_height`, and `source_viewbox`. If the output canvas differs from the source, normalize all geometry, typography, line heights, strokes, and image crop coordinates explicitly instead of relying on the shared aspect ratio.
348 - **Color scheme**: Uses primary, secondary, and accent colors from the spec
349 - **Font plan**: Uses the per-role font families declared in the spec
350 - **Layout principles**: Margins and spacing conform to the spec
351 - **Image system**: Image placement, crop/clip behavior, full-bleed zones, and scrim/overlay or baked-alpha treatment follow the source-derived norms in the spec
352 - **Deck application**: Template Overview describes the recurring situations, audiences/outcomes, and representative roles; Page Roster factually describes the actual prototypes and reusable slots without prescribing future use
353
354 If PPTX import output exists:
355 - Prefer imported theme colors and fonts over visually guessed values
356 - Reuse exported `assets/` images directly — `<image>` references in `svg/` already point at canonical files
357 - Treat page-type candidates from `manifest.pageTypeCandidates` as hints, not guarantees
358
359 **Precondition**:
360
361 - For `standard`, inspect enough lightweight complete-page IR documents to understand the requested visual direction and reusable assets; do not analyze source topology.
362 - For `fidelity`, inspect every lightweight complete-page IR document so the newly designed roster covers the useful source composition range; do not derive output ownership from source Master/Layout recurrence.
363 - For `mirror`, verify every authoring Master, Layout, and Slide listed by `authoring_summary.json` against `native_structure.json` and `svg/inheritance.json`, then materialize from the IR with matching lossless payload backing. The compiler validates each machine-manifest record. Before materialization begins, report the verified source slide indexes.
364
365 ### 2.1 PPTX Import Mode Rule
366
367 The imported PPTX has a different authority level in each replication mode.
368
369 | Mode | Required behavior |
370 |---|---|
371 | `standard` | Use source visuals/assets as references, then author the project-canonical roster and its Master/Layout/slot structure from the confirmed brief. Do not preserve or distill source topology. |
372 | `fidelity` | Use the complete visual roster as design reference, then author a broader canonical roster and its own Master/Layout/slot structure. Match the source visual language closely, but do not cluster, merge, or split source Layouts into output families. |
373 | `mirror` | Preserve validated source pages, inheritance, placeholders, native objects, and visuals from the lossless import while creating a new workspace. Do not simplify, redesign, rename structure, infer new common structure, or fill gaps. |
374
375 **Hard rule — mirror materialization is mechanical**: Mirror may normalize namespaces,
376 portable asset paths, explicit root declarations, and fixed-layer group wrappers
377 required by the current compiler. Expanding a source Master/Layout group must
378 produce direct atoms with the same ownership, transforms, paint order, and
379 appearance. A maintainability preference is not authority to alter the source
380 template.
381
382 ### 2.2 Native Shape Payload and Authoring IR
383
384 | Representation | Purpose | Payload rule |
385 |---|---|---|
386 | Lossless import SVG | Native-payload backing | Retain complete imported metadata, native object boundaries, hidden carriers, and source-scope identity. Keep it immutable and resolve it only through validated source refs. |
387 | Authoring IR bundle | Editable template-creation source | Omit opaque native payload and duplicate hidden carriers from model context; retain visible shape intent and stable document-local source refs. Models read `authoring_summary.json`; tools read `authoring_manifest.json` for source paths and initial hashes. |
388 | `standard` / `fidelity` output | Newly authored contract | Use editable basic primitives directly and `preset_shape_svg.py` compact canonical `<g>` output for exact preset matches. Keep faithful atoms independently composed when one contour is unnecessary; use `shape_boolean_svg.py` only where one compound closed contour must become an object, then allow a necessary freeform only if neither construction is faithful. Paint comes from the confirmed brief / `<design_spec_path>`. Reuse exported image/vector assets, not opaque source shape payload or source topology. |
389 | `mirror` output | Materialized preserved contract | Preserve currently supported imported metadata on unchanged Slide-local/slot refs, use the edited SVG fallback otherwise, and normalize fixed structural layers into semantic atoms. Strip IR-only source refs from final templates. |
390
391 **Validation**: Mirror does not silently use stale metadata. Materialization
392 validates source-document hashes and each referenced object's initial authoring
393 hash before reusing native payload. If an imported object cannot use the
394 converter's supported native metadata after normalization, keep its current SVG fallback and report the
395 limitation. For exact registered preset matches, `standard` / `fidelity`
396 regenerate the compact helper group instead of transplanting opaque source
397 payload; otherwise they keep faithful atoms independently composed unless one
398 contour requires the Boolean gate, with necessary freeform last.
399 `data-pptx-replace-with` remains reserved for optional PowerPoint-native
400 Chart/Table replacement markers.
401
402 **Explicit template SVG contract**:
403
404 | Authored/preserved fact | Template SVG declaration |
405 |---|---|
406 | Master/Layout identity | Root `data-pptx-master` / `data-pptx-master-name` plus `data-pptx-layout` / `data-pptx-layout-name`; authored keys for `standard` / `fidelity`, source keys for `mirror` |
407 | Authored Master/Layout visual | In `standard` / `fidelity`, use a direct atomic child with `data-pptx-layer="master|layout"` and `data-pptx-editable="false"`. An ordinary `<g>` is forbidden; one validated compact canonical authored-preset `<g>` is a semantic atom and is the sole group exception. |
408 | Preserved source Master/Layout visual | In `mirror`, recursively expand each fixed-layer source group into direct atoms with the same Master/Layout ownership, transforms, styles, paint order, and appearance; semantic regrouping is forbidden |
409 | Content slot | Direct `<g id>` with `data-pptx-placeholder` and explicit `data-pptx-bounds`; `standard` / `fidelity` author the slot, while `mirror` preserves source type/index/bounds and carrier identity |
410 | Page-only background | Direct full-canvas solid rect with `data-pptx-layer="slide"` |
411 | Structural page-frame hint | Optional `data-pptx-role` only when background/decoration/header/footer/logo/watermark/chrome/page-number behavior is not already expressed by layer/placeholder metadata; stable unique `id` required |
412
413 Repeat inherited visuals in every standalone SVG so browser preview remains complete. Template export validates their equality and materializes the declared Master/Layout parts. It does not infer ownership.
414
415 **Forbidden — legacy structure contract**: Do not carry `data-pptx-layout-kind`, `distilled`, `utility`, unmapped `baseline`, `preserve`, or direct atomic placeholders into a reusable template package. In `standard` / `fidelity`, treat such Type B inputs only as visual reference and author a complete current contract in a new workspace. Require the original PPTX Type A path when mirror must preserve existing native topology; see [`create-template`](../workflows/create-template.md).
416
417 **Composite slot boundary**: A normal slot group has exactly one compatible
418 direct carrier. A validated compact canonical authored-preset `<g>` counts as
419 one carrier for an `object` slot because it compiles to one native shape; an
420 ordinary multi-object `<g>` does not. Only a genuinely composite region may
421 declare `data-pptx-placeholder="object"` with
422 `data-pptx-binding="proxy"`; the visible group stays Slide-local
423 and export creates a hidden transparent binding proxy. Do not use proxy binding
424 as the default template slot form.
425
426 In `mirror`, preserve imported placeholder types, indices, bounds, and carrier
427 identity exactly when the importer supports them. Do not replace source
428 `subTitle`, `obj`, `media`, or `dt` roles with generic body content. In
429 `standard` / `fidelity`, assign the canonical authored types deliberately:
430 `title`, `subtitle`, `body`, `picture`, `chart`, `table`, `object`, `media`,
431 `date`, `footer`, and `slide-number`. An authored title normally has no index;
432 assign stable indices only when repeated roles need disambiguation inside the
433 new Layout.
434
435 **Hard rule — explicit design-zone bounds**: Every slot carries `data-pptx-bounds="x y width height"` with at most two decimals per value. Mirror uses the source Layout placeholder frame. `standard` / `fidelity` author bounds from the intended safe area, column, panel inset, or media frame. Do not use character count, glyph width, current wrapping, or the tight sample-content box. An authored Layout may intentionally have zero slots.
436
437 ### 3. Placeholder Markers
438
439 > Mirror retains literal source example text and source placeholder metadata. It does not insert `{{...}}` markers. The rest of this section defines the preferred authoring vocabulary for standard and fidelity modes.
440
441 Use clear placeholder markers for replaceable content:
442
443 ```xml
444 <!-- Text slot -->
445 <g id="title-slot" data-pptx-placeholder="title"
446 data-pptx-bounds="80 280 1120 96">
447 <text id="title-carrier" data-pptx-carrier="true"
448 x="80" y="320" fill="#FFFFFF" font-size="48" font-weight="bold">
449 {{TITLE}}
450 </text>
451 </g>
452
453 <!-- Content area placeholder (content page only) -->
454 <rect x="40" y="90" width="1200" height="550" fill="#FFFFFF" rx="8"/>
455 <g id="body-slot" data-pptx-placeholder="body"
456 data-pptx-bounds="40 90 1200 550">
457 <text id="body-carrier" data-pptx-carrier="true"
458 x="640" y="365" text-anchor="middle" fill="#CBD5E1" font-size="16">
459 {{CONTENT_AREA}}
460 </text>
461 </g>
462 ```
463
464 ### 4. Placeholder Reference (canonical convention, overridable per template)
465
466 This is the **default vocabulary** used across template packages. Newly created templates SHOULD prefer these names so downstream projects find familiar slots; designers MAY substitute or extend them when a style genuinely needs different vocabulary (e.g. consulting decks lead with `{{KEY_MESSAGE}}` instead of `{{PAGE_TITLE}}`; a brand cover may need `{{BRAND_LOGO}}`).
467
468 `svg_quality_checker.py --template-mode` emits **advisory warnings** when a page lacks the conventional placeholder for its type. To silence those warnings — and document the template's actual contract — declare a `placeholders:` map in `<design_spec_path>` frontmatter:
469
470 ```yaml
471 placeholders:
472 01_cover: ["{{TITLE}}", "{{SUBTITLE}}", "{{BRAND_LOGO}}"]
473 03_content: ["{{KEY_MESSAGE}}", "{{CONTENT_AREA}}"]
474 03a_content_dual_col: [] # explicitly assert "no required placeholders"
475 ```
476
477 | Placeholder | Purpose | Applicable page | Convention role |
478 |------------|---------|-------------------|--------|
479 | `{{TITLE}}` | Main title | Cover | Default |
480 | `{{SUBTITLE}}` | Subtitle | Cover | Default |
481 | `{{DATE}}` | Date | Cover | Default |
482 | `{{AUTHOR}}` | Author / Organization | Cover | Default |
483 | `{{CHAPTER_NUM}}` | Chapter number | Chapter page | Default |
484 | `{{CHAPTER_TITLE}}` | Chapter title | Chapter page | Default |
485 | `{{CHAPTER_DESC}}` | Chapter description | Chapter page | Optional |
486 | `{{PAGE_TITLE}}` | Page title | Content page | Default |
487 | `{{CONTENT_AREA}}` | Content area | Content page | Default |
488 | `{{PAGE_NUM}}` | Page number | Content page, ending page | Default |
489 | `{{KEY_MESSAGE}}` | Key takeaway | Content page (consulting style) | Style-specific |
490 | `{{SECTION_NAME}}` | Section name | Content page footer | Optional |
491 | `{{SOURCE}}` | Data source | Content page footer | Optional |
492 | `{{THANK_YOU}}` | Thank-you message | Ending page | Default |
493 | `{{CONTACT_INFO}}` | Contact info | Ending page | Default |
494 | `{{ENDING_SUBTITLE}}` | Ending subtitle | Ending page | Optional |
495 | `{{CLOSING_MESSAGE}}` | Closing message | Ending page | Style-specific |
496 | `{{COPYRIGHT}}` | Copyright | Ending page | Optional |
497
498 For TOC pages in **newly created templates**, use indexed placeholders:
499
500 - `{{TOC_ITEM_1_TITLE}}`, `{{TOC_ITEM_1_DESC}}`
501 - `{{TOC_ITEM_2_TITLE}}`, `{{TOC_ITEM_2_DESC}}`
502 - ...
503
504 Do **not** create new TOC placeholder families such as `{{CHAPTER_01_TITLE}}` for new templates. Existing templates may contain legacy placeholder variants, but new output should converge on the indexed TOC contract.
505
506 Variants reuse their parent type's placeholder set by default: every `03*_content*.svg` shares the content placeholder list above, unless the spec frontmatter declares an override for that specific stem.
507
508 For `standard` / `fidelity`, canonical placeholder insertion takes priority over visual mimicry; adjust the newly designed layout or declare an intentional vocabulary override. Mirror preserves the source placeholders and literal text instead of inserting canonical authoring markers.
509
510 ---
511
512 ## Output Requirements
513
514 ### File Save Location
515
516 Both scopes use one complete workspace shape. Only the workspace root differs:
517
518 | Scope | `<template_workspace>` |
519 |---|---|
520 | `library` | `skills/ppt-master/templates/<kind_dir>/<template_name>/` |
521 | `project` | `<target_project>/` |
522
523 Standard mode (default):
524
525 ```
526 <template_workspace>/
527 ├── templates/
528 │ ├── design_spec.md
529 │ │ # project scope uses design_spec.<kind>.<id>.md instead
530 │ ├── 01_cover.svg
531 │ ├── 02_toc.svg # Optional; without it: 02_chapter, 03_content, 04_ending
532 │ ├── 03_chapter.svg
533 │ ├── 04_content.svg
534 │ └── 05_ending.svg
535 ├── images/ # Optional; omit when unused
536 │ └── *.png / *.jpg # SVG href is ../images/<name>
537 ├── icons/ # Optional; omit when unused
538 │ └── imported/
539 │ └── *.svg # Canonical imported vectors, when used
540 └── exports/ # Optional; requested review or required multi-Master evidence
541 └── <deck_id|layout_id>_template_preview.pptx
542 ```
543
544 Fidelity mode changes only the roster under `templates/`, e.g.:
545
546 ```
547 <template_workspace>/templates/
548 ├── design_spec.md # project scope: design_spec.<kind>.<id>.md
549 ├── 01_cover.svg
550 ├── 02_toc.svg
551 ├── 03a_chapter_full.svg
552 ├── 03b_chapter_minimal.svg
553 ├── 04a_content_two_col.svg
554 ├── 04b_content_data_card.svg
555 ├── 04c_content_quote.svg
556 ├── 05_ending.svg
557 └── 06_section_break.svg
558 ```
559
560 Mirror mode emits one SVG per source slide, named by source order:
561
562 ```
563 <template_workspace>/templates/
564 ├── design_spec.md # project scope: design_spec.<kind>.<id>.md
565 ├── 001_cover.svg
566 ├── 002_toc.svg
567 ├── 003_content.svg
568 ├── 004_content.svg
569 ├── 005_chapter.svg
570 ├── 006_content.svg
571 ├── ...
572 ├── 049_content.svg
573 └── 050_ending.svg
574 ```
575
576 Filenames preserve the source slide order via the 3-digit prefix; `<page_type>` is derived from `manifest.json` `pageTypeCandidates`. Literal source text and validated native structure facts are preserved when the authoring IR is materialized into the new workspace; IR-only refs and its manifest are not copied into the template output.
577
578 **Hard rule — common routing**: Keep `<design_spec_path>`, template SVGs, and non-bitmap template-source assets in `templates/`; place every bitmap in `images/`; place each imported vector exactly once in `icons/imported/` and reference it as `data-icon="imported/<name>"`. Never create `templates/icons/`. Write a review deck to `exports/` when explicitly requested and always for a multi-Master package gate. Create Template must not create optional directories or placeholder files solely to retain empty paths. An initialized project may already contain empty scaffolding; leave it untouched and omit it from completion unless real template files were written or adopted there. Do not branch asset placement by output scope.
579
580 ### Template Preview
581
582 When the user requests a PowerPoint review file or the validated roster declares multiple Masters, run `template_preview_pptx.py <template_workspace>` after SVG validation. The command creates `exports/` on demand and verifies one slide per SVG prototype plus the expected Master/Layout counts. In authored modes, it shortens canonical marker text only in ephemeral review copies so prompts remain readable without changing the source SVG, carrier typography, or placeholder frames. The first export refuses a collision; an intentional post-fix replacement uses `--force`. The review PPTX is derived evidence and never a template-application input.
583
584 When a review deck was generated, include its path in the completion summary. Omit `exports/` only for an unrequested one-Master package.
585
586 If the template is based on PPTX import output, briefly note:
587 - which extracted assets were reused directly
588 - for `standard` / `fidelity`, which visual references influenced the newly authored roster
589 - for `mirror`, whether any source feature could not be preserved and the exact affected source object/page
590 - whether any page-type filename mapping required judgment beyond the import heuristic
591
592 ---
593
594 ## Using Pre-built Template Library (Optional)
595
596 If suitable template resources already exist, use them directly instead of generating new ones:
597
598 1. **Copy template workspace**: copy or stage `templates/` plus any existing `images/` and `icons/`; exclude `exports/` from template application.
599 2. **Adjust colors**: Modify colors per the project design spec
600 3. **Customize**: Make project-specific adjustments
601
602 This section describes downstream reuse of an existing workspace. Library and project scopes carry the same portable template contract.
603
604 **Example library structure** (query the appropriate kind's index — `templates/brands/brands_index.json` for identity, `templates/styles/styles_index.json` for roster-free direction/method, `templates/layouts/layouts_index.json` for brand-neutral structure, and `templates/decks/decks_index.json` for recurring applications with integrated identity/structure):
605
606 ```
607 templates/
608 ├── brands/
609 │ ├── anthropic/ # Anthropic brand identity (logo + colors + typography)
610 │ └── google/ # Google brand identity
611 ├── styles/
612 │ └── <style_id>/ # Communication method and design direction; no SVG roster
613 ├── layouts/
614 │ └── presentation_core/ # General structure system (no identity)
615 └── decks/
616 ├── <bank_deck>/ # Example banking deck
617 └── <engineering_deck>/ # Example engineering deck
618 ```
619
620 ---
621
622 ## Phase Completion Checkpoint
623
624 ```markdown
625 ## Template_Designer Phase Complete
626
627 - [x] Read `references/template-designer.md`
628 - [x] Output scope confirmed: `library` | `project`; the common workspace preflight passed before final writes
629 - [x] Internal creation strategy derived from the confirmed natural-language intent: `standard` | `fidelity` | `mirror`; Layout mirror source is already brand-neutral and application-neutral
630 - [x] Every page listed in `<design_spec_path>` §V Page Roster saved to `<template_workspace>/templates/`
631 - [x] Naming convention applied (standard / fidelity: letter-suffix variants; mirror: `<NNN>_<page_type>.svg`)
632 - [x] Templates follow design spec (colors, fonts, layout)
633 - [x] Deck Template Overview and factual Page Roster describe the recurring application and actual prototypes without mandatory use policy; Layout output contains no application or identity contract
634 - [x] `standard` / `fidelity` SVGs and Master/Layout contracts were newly authored; `mirror` SVGs were materialized from the authoring IR while preserving the source graph without semantic redesign
635 - [x] Placeholder markers are clear and standardized for `standard` / `fidelity`; preview-only sample text remains readable without changing source markers, while mirror preserves literal source text plus source placeholder type/index/bounds
636 - [x] Every SVG is a complete preview with explicit root Master/Layout identity and `native_structure_mode: structured`; authored modes use canonical fixed layers/slots, while mirror preserves source ownership and mechanically expands fixed-layer groups into direct atoms
637 - [x] Authored `standard` / `fidelity` Layout keys are non-duplicative; mirror keeps distinct source Layout identities even when their current visible contracts are equivalent
638 - [x] Template creation used the authoring IR; lossless expanded imports remained immutable payload backing for mirror materialization, while `standard` / `fidelity` used helper-generated compact canonical preset groups and `<design_spec_path>` paint
639 - [x] Both scopes route bitmaps to `images/` and keep one canonical copy of every imported vector under `icons/imported/`
640 - [ ] **Next step**: Validate assets, export review evidence when requested or required for multiple Masters, then register only library scope
641 ```
642
642 lines MARKDOWN