返回 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 a concise `design_spec.md` 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 use one workspace shape; 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 - **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)
17
18 **Hard rule — scope is execution metadata**: Use `output_scope` and `target_project` to route files, but do not write either field into portable `design_spec.md` frontmatter. Do not create a new PPTX structure mode; deck/layout output declares `native_structure_mode: structured`.
19
20 **Workspace precondition**: The workflow has already resolved the selected root, confirmed an empty `<template_workspace>/templates/`, and checked collision-free destination filenames in `images/` and `icons/imported/`. Check `exports/` when review was requested or the confirmed roster contains multiple Masters. 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.
21
22 When the workflow provides a PPTX reference source, the effective input package comes from the unified `pptx_template_import.py` preparation workspace and becomes:
23
24 - finalized template brief
25 - `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)
26 - `native_structure.json` — stable source master/layout keys, picker names, parent-master relationships, placeholder type/index/geometry, source hash, and source-graph quality facts
27 - `source_template.pptx` — byte-preserved analysis copy for visual/package cross-checking; never a final template asset
28 - `conversion-report.json` — source-recovery and fidelity diagnostics, when present
29 - exported `assets/`
30 - `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
31 - `svg/slide_NN.svg` — immutable slide-local native-payload backing; do not bulk-read because opaque native payload is retained
32 - `svg/inheritance.json` — which layout / master each slide consumes
33 - optional `svg-flat/slide_NN.svg` — immutable complete-page verification backing generated only when explicitly requested; do not use it as the editable source
34 - `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`
35 - optional screenshots for visual cross-checking
36
37 PPTX import interpretation:
38
39 - 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.
40 - 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.
41 - The asset filenames referenced by SVGs are governed by the manifest asset map. Prefer those references over inventing duplicate asset names.
42
43 Input priority for PPTX-backed template creation depends on the AI-derived internal strategy recorded as `replication_mode`:
44
45 | Mode | Authoritative inputs | Model-facing inputs |
46 |---|---|---|
47 | `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. |
48 | `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. |
49
50 Use the compact facts in `manifest.json` for orientation. Open screenshots or the original PPTX only for visual cross-checking.
51
52 **Native structure output**: Always set `native_structure_mode: structured`.
53
54 **Hard rule — native objects are compiled output**: Treat Theme, Master,
55 Layout, and Placeholder as PowerPoint implementation objects, not template
56 kinds. Layout owns topology, placement, semantic text roles, and spatial text
57 behavior. Deck identity owns paint, typeface identity, and fixed identity
58 assets; its application context describes the recurring presentation family. Under
59 downstream `layout` scope, resolve final placeholder formatting from the Layout
60 roles plus the confirmed identity, reading mode, and type scale; downstream
61 `mirror` scope preserves literal source formatting and text topology. Compile
62 the applicable rules into the same native graph without merging their source
63 ownership.
64
65 | Mode | Output structure contract |
66 |---|---|
67 | `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. For every new contour, use an editable basic primitive, then an exact compact authored preset, then a Boolean result; use freeform only when those cannot express it faithfully. |
68 | `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. |
69
70 Every page remains a complete standalone SVG preview.
71
72 **Authored preset rule**: In `standard` / `fidelity`, when one registered
73 PowerPoint preset exactly expresses one complete object, use
74 `preset_shape_svg.py` as defined by
75 [`native-shape-authoring.md`](./native-shape-authoring.md). Its compact
76 canonical `<g>` is one semantic atom after validation: it may remain
77 Slide-local, serve as the one direct carrier of an `object` slot, or carry
78 Master/Layout fixed-layer ownership. This is the only `<g>` exception to the
79 fixed-layer atomicity rule; ordinary groups remain forbidden there. Preset
80 paint comes from the confirmed brief and this template's `design_spec.md`
81 color scheme. Do not copy an expanded import carrier/preview/fingerprint
82 bundle into an authored template. `mirror` instead preserves the supported
83 expanded lossless source representation. The exact syntax and validation
84 contract remain owned by
85 [`shared-standards-core.md`](./shared-standards-core.md) and the native-shape reference.
86 When one preset is insufficient, apply the same reference's Boolean gate before
87 hand-authoring a freeform.
88
89 **Hard rule — complete mirror graph**: Preserve every supported source Layout represented by the validated import,
90 including Layouts unused by source Slides. Emit one complete source-page
91 prototype per source Slide and one definition-only
92 `layout_<layout_key>.svg` prototype for each otherwise unrepresented Layout.
93 The definition prototype carries the exact parent Master identity, Layout
94 identity, fixed atoms, and placeholder contract but is not a generated page.
95 This also retains a source Master that is reachable only through unused Layouts.
96 Never silently drop or merge an identity, and never invent a carrier page.
97
98 **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.
99
100 **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.
101
102 For `mirror`, `design_spec.md §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.
103
104 ---
105
106 ## Page Roster
107
108 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:
109
110 | Mode | When to use | Roster |
111 |------|-------------|--------|
112 | `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 |
113 | `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 |
114 | `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 |
115
116 **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.
117
118 ### Standard mode
119
120 | # | Filename | Purpose | Description |
121 |---|----------|---------|-------------|
122 | 01 | `01_cover.svg` | Cover | Fixed structure: title, subtitle, date, organization |
123 | 02 | `02_chapter.svg` | Chapter page | Fixed structure: chapter number, chapter title |
124 | 03 | `03_content.svg` | Content page | Flexible structure: only defines header/footer; content area freely laid out by AI |
125 | 04 | `04_ending.svg` | Ending page | Fixed structure: thank-you message, contact info |
126 | -- | `02_toc.svg` | Table of contents | Optional: TOC title, chapter list (number + title) |
127
128 **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.
129
130 **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.
131
132 **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.
133
134 ### Fidelity mode
135
136 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.
137
138 **Variant naming**: append a lowercase letter suffix to the parent type's index, preserving sort order:
139
140 | Parent type | Example variants |
141 |-------------|------------------|
142 | Chapter | `02a_chapter_full.svg`, `02b_chapter_minimal.svg` |
143 | Content | `03a_content_two_col.svg`, `03b_content_data_card.svg`, `03c_content_quote.svg` |
144 | Ending | `04a_ending_thanks.svg`, `04b_ending_contact.svg` |
145
146 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).
147
148 **Roster decision**:
149
150 - Choose variants from useful visual composition types such as two-column content, hero image, icon grid, data card, and quote
151 - Keep only variants that add a genuinely useful authored composition; source Layout keys and repeated source chrome are not clustering inputs
152 - Design each variant's Master/Layout/slot contract directly from its intended reusable behavior
153 - Record every emitted page in `design_spec.md §V Page Roster`; in library scope, `register_template.py` generates the corresponding index entry from `<template_workspace>/templates/*.svg`. Project scope skips registration
154
155 > Variants reuse the parent type's placeholder set — see §4 (Placeholder Reference) below.
156
157 ### Mirror mode
158
159 When the derived implementation writes `replication_mode: mirror`, materialize a new template workspace from validated imported facts rather than designing a new system:
160
161 - 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.
162 - 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.
163 - 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.
164 - 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.
165 - 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.
166 - 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.
167 - 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.
168 - `design_spec.md` §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.
169
170 **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.
171
172 **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.
173
174 ---
175
176 ## Template Design Specifications
177
178 ### 1. Must Generate design_spec.md
179
180 **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:
181
182 - Always-on SVG rules and conditional-module routing → [`shared-standards-core.md`](./shared-standards-core.md)
183 - Generic layout pattern library, spacing bands, font-size ratio bands → [`strategist.md`](strategist.md) (used when authoring the **project** design spec)
184 - Canonical placeholder vocabulary → §4 below
185 - Content methodology (pyramid / SCQA / MECE) → [`strategist.md`](strategist.md)
186
187 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.**
188
189 **Required skeleton by kind:**
190
191 The frontmatter is portable across library and project scope. Do not add
192 `output_scope` or `target_project`; those belong only to the workflow execution
193 brief. Use `deck_id` or `layout_id`; do not invent a generic `template_id`
194 field that the registrar cannot bind to its library kind.
195
196 **Deck**:
197
198 ```markdown
199 ---
200 deck_id: <id>
201 kind: deck
202 category: brand | general | scenario | government | special
203 summary: <one-line recurring presentation family and intended outcome>
204 keywords: [tag1, tag2, tag3]
205 primary_color: "#......"
206 canvas_format: ppt169
207 canvas_width: 1280
208 canvas_height: 720
209 canvas_viewbox: "0 0 1280 720"
210 # Required when a PPTX/SVG source canvas is known; keep equal to canvas_* unless explicitly normalized.
211 source_canvas_width: 1280
212 source_canvas_height: 720
213 source_viewbox: "0 0 1280 720"
214 replication_mode: standard | fidelity | mirror
215 # Required for every deck/layout template. Source packages remain analysis-only.
216 native_structure_mode: structured
217 page_count: <N>
218 # Optional — only when this template overrides canonical placeholder vocabulary.
219 # Omit the map when canonical vocabulary is sufficient; use [] for an intentional zero-marker page.
220 # placeholders:
221 # 01_cover: ["{{TITLE}}", "{{SUBTITLE}}", "{{BRAND_LOGO}}"]
222 # 03_content: ["{{KEY_MESSAGE}}", "{{CONTENT_AREA}}"]
223 ---
224
225 # [Template Name] — Design Specification
226
227 ## I. Template Overview
228 | Application context | Definition |
229 |---|---|
230 | Recurring presentation family | <repeatable situations this Deck serves> |
231 | Intended audiences and outcomes | <who it serves and what the presentation should enable> |
232 | Delivery and reading assumptions | <presented / close-read / handoff / mixed> |
233 | Representative narrative/page roles | <roles commonly present in this presentation family; descriptive, not mandatory> |
234
235 - Design tone, theme mode (light / dark / mixed), and the visual identity visible at a glance
236
237 ## II. Color Scheme
238 - HEX values with role labels (primary / accent / background / text / etc.)
239 - Brand-specific application rules when present (e.g. "KPI cards rotate blue→green→red→yellow")
240
241 ## III. Typography (omit without template-owned typeface identity)
242 - Per-role stacks for identity (display serif, brand face, etc.)
243 - A non-preinstalled face may lead only after user-confirmed target installation/approved install; no auto-embedding
244 - Otherwise export a safe face; unavailable proprietary faces stay references. CSS tails aid preview, not deterministic PowerPoint fallback
245 - Body baseline px (informational; `spec_lock.md` owns the actual values per project)
246
247 ## IV. Signature Design Elements
248 - Decorative motifs that ARE this template — top bar, gradient underline, logo treatment, brand emblem placement
249 - 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
250 - Optional XML snippet for any reusable component unique to this template
251
252 ## V. Page Roster
253 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.
254
255 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.
256
257 ## VI. Assets (omit when none)
258 Logos, cover backgrounds, brand textures bundled with the template package — file name, dimensions, intended usage.
259
260 ## VII. Placeholder Overrides (omit when none)
261 Reference the `placeholders:` frontmatter declaration and explain the rationale (e.g. "consulting decks lead with `{{KEY_MESSAGE}}` instead of `{{PAGE_TITLE}}`").
262 ```
263
264 **Layout**:
265
266 ```markdown
267 ---
268 layout_id: <id>
269 kind: layout
270 category: general | scenario | government | special
271 summary: <one-line structural use case>
272 keywords: [tag1, tag2, tag3]
273 canvas_format: ppt169
274 canvas_width: 1280
275 canvas_height: 720
276 canvas_viewbox: "0 0 1280 720"
277 # Required when a PPTX/SVG source canvas is known.
278 source_canvas_width: 1280
279 source_canvas_height: 720
280 source_viewbox: "0 0 1280 720"
281 replication_mode: standard | fidelity | mirror
282 native_structure_mode: structured
283 page_count: <N>
284 page_types: [cover, toc, chapter, content, ending]
285 # Optional vocabulary override.
286 # placeholders:
287 # 01_cover: ["{{TITLE}}", "{{SUBTITLE}}"]
288 ---
289
290 # [Layout Name] — Design Specification
291
292 ## IV. Signature Design Elements
293 - Structure-specific grid, zones, page chrome, image behavior, density rhythm, semantic text roles, alignment/wrapping/capacity behavior, and slot conventions
294 - Neutral preview paint/font/size may expose hierarchy, but it is not a color, typeface, or final type-scale identity
295
296 ## V. Page Roster
297 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.
298
299 For `mirror`, append the same `### Source Preservation Map` required above.
300
301 ## VII. Placeholder Overrides (omit when none)
302 Reference the `placeholders:` frontmatter declaration and explain the structural vocabulary deviation.
303 ```
304
305 **Layout boundary**: Omit Template Overview, Color Scheme, Typography, Logo,
306 Voice & Tone, and Icon Style. A scenario category records geometric fit only.
307 Structural text roles, alignment, wrapping, and capacity remain valid Layout
308 rules; final font families, weights, colors, and absolute sizes do not.
309 Do not prescribe communication objectives, audience outcomes, required
310 narrative order, fixed boilerplate, or example-content retention. The
311 frontmatter `summary` carries concise structural selection context; the
312 deck-only Template Overview remains the application segment used during
313 fusion.
314
315 Sections to **omit** from template `design_spec.md` (sourced elsewhere — listing them here is noise):
316
317 | Don't write | Source |
318 |---|---|
319 | Always-on SVG rules and conditional-module routing | `shared-standards-core.md` |
320 | Generic layout pattern library (centered card / three-column / timeline / …) | `strategist.md` §4 |
321 | Generic spacing bands (margin 40-60px, card gap 20-32px, etc.) | `strategist.md` §4 |
322 | Generic font-size hierarchy (cover 2.5-5x body, page title 1.5-2x, …) | `strategist.md` §g |
323 | Canonical placeholder table (`{{TITLE}}`, `{{PAGE_NUM}}`, …) | §4 below |
324 | Content methodology (pyramid / SCQA / MECE) | `strategist.md` |
325 | "Usage Instructions" boilerplate (copy template / select page / …) | `create-template.md` |
326 | Created Date / Page Count rows | not a library-level field |
327
328 When rewriting an existing template that contains an omitted generic section,
329 delete it rather than leaving a pointer. Keep a template-specific boundary only
330 inside the package-owned section it qualifies (asset system, motif, image
331 treatment, or page roster); do not preserve a generic technical-rules heading.
332
333 ### 2. Inherit Design Specification
334
335 Templates must strictly follow the finalized template brief and the generated `design_spec.md`:
336 - **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.
337 - **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.
338 - **Color scheme**: Uses primary, secondary, and accent colors from the spec
339 - **Font plan**: Uses the per-role font families declared in the spec
340 - **Layout principles**: Margins and spacing conform to the spec
341 - **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
342 - **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
343
344 If PPTX import output exists:
345 - Prefer imported theme colors and fonts over visually guessed values
346 - Reuse exported `assets/` images directly — `<image>` references in `svg/` already point at canonical files
347 - Treat page-type candidates from `manifest.pageTypeCandidates` as hints, not guarantees
348
349 **Precondition**:
350
351 - For `standard`, inspect enough lightweight complete-page IR documents to understand the requested visual direction and reusable assets; do not analyze source topology.
352 - 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.
353 - 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.
354
355 ### 2.1 PPTX Import Mode Rule
356
357 The imported PPTX has a different authority level in each replication mode.
358
359 | Mode | Required behavior |
360 |---|---|
361 | `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. |
362 | `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. |
363 | `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. |
364
365 **Hard rule — mirror materialization is mechanical**: Mirror may normalize namespaces,
366 portable asset paths, explicit root declarations, and fixed-layer group wrappers
367 required by the current compiler. Expanding a source Master/Layout group must
368 produce direct atoms with the same ownership, transforms, paint order, and
369 appearance. A maintainability preference is not authority to alter the source
370 template.
371
372 ### 2.2 Native Shape Payload and Authoring IR
373
374 | Representation | Purpose | Payload rule |
375 |---|---|---|
376 | 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. |
377 | 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. |
378 | `standard` / `fidelity` output | Newly authored contract | Use editable basic primitives directly, `preset_shape_svg.py` compact canonical `<g>` output for exact preset matches, and `shape_boolean_svg.py` for compound closed contours before allowing a necessary freeform. Paint comes from the confirmed brief / `design_spec.md`. Reuse exported image/vector assets, not opaque source shape payload or source topology. |
379 | `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. |
380
381 **Validation**: Mirror does not silently use stale metadata. Materialization
382 validates source-document hashes and each referenced object's initial authoring
383 hash before reusing native payload. If an imported object cannot use the
384 converter's supported native metadata after normalization, keep its current SVG fallback and report the
385 limitation. For exact registered preset matches, `standard` / `fidelity`
386 regenerate the compact helper group instead of transplanting opaque source
387 payload; otherwise they apply the Boolean/freeform fallback gate above.
388 `data-pptx-replace-with` remains reserved for optional PowerPoint-native
389 Chart/Table replacement markers.
390
391 **Explicit template SVG contract**:
392
393 | Authored/preserved fact | Template SVG declaration |
394 |---|---|
395 | 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` |
396 | 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. |
397 | 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 |
398 | 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 |
399 | Page-only background | Direct full-canvas solid rect with `data-pptx-layer="slide"` |
400 | 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 |
401
402 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.
403
404 **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).
405
406 **Composite slot boundary**: A normal slot group has exactly one compatible
407 direct carrier. A validated compact canonical authored-preset `<g>` counts as
408 one carrier for an `object` slot because it compiles to one native shape; an
409 ordinary multi-object `<g>` does not. Only a genuinely composite region may
410 declare `data-pptx-placeholder="object"` with
411 `data-pptx-binding="proxy"`; the visible group stays Slide-local
412 and export creates a hidden transparent binding proxy. Do not use proxy binding
413 as the default template slot form.
414
415 In `mirror`, preserve imported placeholder types, indices, bounds, and carrier
416 identity exactly when the importer supports them. Do not replace source
417 `subTitle`, `obj`, `media`, or `dt` roles with generic body content. In
418 `standard` / `fidelity`, assign the canonical authored types deliberately:
419 `title`, `subtitle`, `body`, `picture`, `chart`, `table`, `object`, `media`,
420 `date`, `footer`, and `slide-number`. An authored title normally has no index;
421 assign stable indices only when repeated roles need disambiguation inside the
422 new Layout.
423
424 **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.
425
426 ### 3. Placeholder Markers
427
428 > 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.
429
430 Use clear placeholder markers for replaceable content:
431
432 ```xml
433 <!-- Text slot -->
434 <g id="title-slot" data-pptx-placeholder="title"
435 data-pptx-bounds="80 280 1120 96">
436 <text id="title-carrier" data-pptx-carrier="true"
437 x="80" y="320" fill="#FFFFFF" font-size="48" font-weight="bold">
438 {{TITLE}}
439 </text>
440 </g>
441
442 <!-- Content area placeholder (content page only) -->
443 <rect x="40" y="90" width="1200" height="550" fill="#FFFFFF" rx="8"/>
444 <g id="body-slot" data-pptx-placeholder="body"
445 data-pptx-bounds="40 90 1200 550">
446 <text id="body-carrier" data-pptx-carrier="true"
447 x="640" y="365" text-anchor="middle" fill="#CBD5E1" font-size="16">
448 {{CONTENT_AREA}}
449 </text>
450 </g>
451 ```
452
453 ### 4. Placeholder Reference (canonical convention, overridable per template)
454
455 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}}`).
456
457 `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.md` frontmatter:
458
459 ```yaml
460 placeholders:
461 01_cover: ["{{TITLE}}", "{{SUBTITLE}}", "{{BRAND_LOGO}}"]
462 03_content: ["{{KEY_MESSAGE}}", "{{CONTENT_AREA}}"]
463 03a_content_dual_col: [] # explicitly assert "no required placeholders"
464 ```
465
466 | Placeholder | Purpose | Applicable page | Convention role |
467 |------------|---------|-------------------|--------|
468 | `{{TITLE}}` | Main title | Cover | Default |
469 | `{{SUBTITLE}}` | Subtitle | Cover | Default |
470 | `{{DATE}}` | Date | Cover | Default |
471 | `{{AUTHOR}}` | Author / Organization | Cover | Default |
472 | `{{CHAPTER_NUM}}` | Chapter number | Chapter page | Default |
473 | `{{CHAPTER_TITLE}}` | Chapter title | Chapter page | Default |
474 | `{{CHAPTER_DESC}}` | Chapter description | Chapter page | Optional |
475 | `{{PAGE_TITLE}}` | Page title | Content page | Default |
476 | `{{CONTENT_AREA}}` | Content area | Content page | Default |
477 | `{{PAGE_NUM}}` | Page number | Content page, ending page | Default |
478 | `{{KEY_MESSAGE}}` | Key takeaway | Content page (consulting style) | Style-specific |
479 | `{{SECTION_NAME}}` | Section name | Content page footer | Optional |
480 | `{{SOURCE}}` | Data source | Content page footer | Optional |
481 | `{{THANK_YOU}}` | Thank-you message | Ending page | Default |
482 | `{{CONTACT_INFO}}` | Contact info | Ending page | Default |
483 | `{{ENDING_SUBTITLE}}` | Ending subtitle | Ending page | Optional |
484 | `{{CLOSING_MESSAGE}}` | Closing message | Ending page | Style-specific |
485 | `{{COPYRIGHT}}` | Copyright | Ending page | Optional |
486
487 For TOC pages in **newly created templates**, use indexed placeholders:
488
489 - `{{TOC_ITEM_1_TITLE}}`, `{{TOC_ITEM_1_DESC}}`
490 - `{{TOC_ITEM_2_TITLE}}`, `{{TOC_ITEM_2_DESC}}`
491 - ...
492
493 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.
494
495 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.
496
497 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.
498
499 ---
500
501 ## Output Requirements
502
503 ### File Save Location
504
505 Both scopes use one complete workspace shape. Only the workspace root differs:
506
507 | Scope | `<template_workspace>` |
508 |---|---|
509 | `library` | `skills/ppt-master/templates/<kind_dir>/<template_name>/` |
510 | `project` | `<target_project>/` |
511
512 Standard mode (default):
513
514 ```
515 <template_workspace>/
516 ├── templates/
517 │ ├── design_spec.md
518 │ ├── 01_cover.svg
519 │ ├── 02_toc.svg # Optional; without it: 02_chapter, 03_content, 04_ending
520 │ ├── 03_chapter.svg
521 │ ├── 04_content.svg
522 │ └── 05_ending.svg
523 ├── images/ # Optional; omit when unused
524 │ └── *.png / *.jpg # SVG href is ../images/<name>
525 ├── icons/ # Optional; omit when unused
526 │ └── imported/
527 │ └── *.svg # Canonical imported vectors, when used
528 └── exports/ # Optional; requested review or required multi-Master evidence
529 └── <deck_id|layout_id>_template_preview.pptx
530 ```
531
532 Fidelity mode changes only the roster under `templates/`, e.g.:
533
534 ```
535 <template_workspace>/templates/
536 ├── design_spec.md
537 ├── 01_cover.svg
538 ├── 02_toc.svg
539 ├── 03a_chapter_full.svg
540 ├── 03b_chapter_minimal.svg
541 ├── 04a_content_two_col.svg
542 ├── 04b_content_data_card.svg
543 ├── 04c_content_quote.svg
544 ├── 05_ending.svg
545 └── 06_section_break.svg
546 ```
547
548 Mirror mode emits one SVG per source slide, named by source order:
549
550 ```
551 <template_workspace>/templates/
552 ├── design_spec.md
553 ├── 001_cover.svg
554 ├── 002_toc.svg
555 ├── 003_content.svg
556 ├── 004_content.svg
557 ├── 005_chapter.svg
558 ├── 006_content.svg
559 ├── ...
560 ├── 049_content.svg
561 └── 050_ending.svg
562 ```
563
564 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.
565
566 **Hard rule — common routing**: Keep `design_spec.md`, 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.
567
568 ### Template Preview
569
570 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.
571
572 When a review deck was generated, include its path in the completion summary. Omit `exports/` only for an unrequested one-Master package.
573
574 If the template is based on PPTX import output, briefly note:
575 - which extracted assets were reused directly
576 - for `standard` / `fidelity`, which visual references influenced the newly authored roster
577 - for `mirror`, whether any source feature could not be preserved and the exact affected source object/page
578 - whether any page-type filename mapping required judgment beyond the import heuristic
579
580 ---
581
582 ## Using Pre-built Template Library (Optional)
583
584 If suitable template resources already exist, use them directly instead of generating new ones:
585
586 1. **Copy template workspace**: copy or stage `templates/` plus any existing `images/` and `icons/`; exclude `exports/` from template application.
587 2. **Adjust colors**: Modify colors per the project design spec
588 3. **Customize**: Make project-specific adjustments
589
590 This section describes downstream reuse of an existing workspace. Library and project scopes carry the same portable template contract.
591
592 **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):
593
594 ```
595 templates/
596 ├── brands/
597 │ ├── anthropic/ # Anthropic brand identity (logo + colors + typography)
598 │ └── google/ # Google brand identity
599 ├── styles/
600 │ └── <style_id>/ # Communication method and design direction; no SVG roster
601 ├── layouts/
602 │ └── presentation_core/ # General structure system (no identity)
603 └── decks/
604 ├── <bank_deck>/ # Example banking deck
605 └── <engineering_deck>/ # Example engineering deck
606 ```
607
608 ---
609
610 ## Phase Completion Checkpoint
611
612 ```markdown
613 ## Template_Designer Phase Complete
614
615 - [x] Read `references/template-designer.md`
616 - [x] Output scope confirmed: `library` | `project`; the common workspace preflight passed before final writes
617 - [x] Internal creation strategy derived from the confirmed natural-language intent: `standard` | `fidelity` | `mirror`; Layout mirror source is already brand-neutral and application-neutral
618 - [x] Every page listed in `design_spec.md §V Page Roster` saved to `<template_workspace>/templates/`
619 - [x] Naming convention applied (standard / fidelity: letter-suffix variants; mirror: `<NNN>_<page_type>.svg`)
620 - [x] Templates follow design spec (colors, fonts, layout)
621 - [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
622 - [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
623 - [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
624 - [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
625 - [x] Authored `standard` / `fidelity` Layout keys are non-duplicative; mirror keeps distinct source Layout identities even when their current visible contracts are equivalent
626 - [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.md` paint
627 - [x] Both scopes route bitmaps to `images/` and keep one canonical copy of every imported vector under `icons/imported/`
628 - [ ] **Next step**: Validate assets, export review evidence when requested or required for multiple Masters, then register only library scope
629 ```
630
630 lines MARKDOWN