create-template.md - ppt-master

create-template.md

1	---
2	description: Create Template entry workflow and shared contract for the Create Brand, Create Style, Create Layout, and Create Deck sub-workflows.
3	---
4
5	# Create Template Workflow
6
7	> Fixed entry name: user-facing template creation always enters Create Template. This workflow selects exactly one child workflow — [`create-brand.md`](./create-template/create-brand.md), [`create-style.md`](./create-template/create-style.md), [`create-layout.md`](./create-template/create-layout.md), or [`create-deck.md`](./create-template/create-deck.md) — and owns their shared execution contract.
8	>
9	> Role invoked for Create Layout/Create Deck: [Template_Designer](../references/template-designer.md)
10
11	Create one reusable template workspace under either the global template library or `projects/` from one or more reference channels or a direct user brief, then dispatch to exactly one child workflow.
12
13	Default — library scope: Write `skills/ppt-master/templates/<kind_dir>/<template_id>/` and register it in the matching discovery index.
14
15	Project scope: Write the same portable workspace routing at `<project>/` and do not register any global index. That project root stays an ordinary referenceable workspace root, and its `templates/` may accumulate one Brand, Style, Layout, and Deck over separate runs. When Layout and Deck coexist, Layout owns the active SVG roster; Deck retains identity and reusable application context.
16
17	Hard rule — one workspace routing contract: Output scope changes the workspace parent, Design Spec filename placement, and index registration—not the spec schema or asset routes. Both scopes use required `templates/`, optional `images/` / `icons/`, and optional on-demand `exports/`, with the same relative asset references and validation command. Create Template must not create an optional directory or placeholder file solely to retain an empty path. An initialized project may already contain empty `images/`, `icons/`, or `exports/` scaffolding; leave it untouched, do not count it as template output, and omit the path from completion unless this workflow wrote or adopted a real file there. Do not maintain a library-only self-contained-flat package branch or a project-only thin-bundle branch.
18
19	> Boundary against template-fill and in-place structure edits: Create Template does not fill content into a PPTX, add Master/Layout structure to an existing PPTX/SVG, or directly output the user's final generated deck. It authors a separate reusable workspace; an optional PPTX is review evidence only. To generate a deck, return the workspace root as an exact candidate to [`generate-pptx`](./generate-pptx.md) Step 3, confirm it with Stage 1, then author new SVG pages from the installed state. A project-scoped workspace selected for its own project is consumed in place after that confirmation.
20
21	> Boundary against page-image reconstruction: screenshots and page visuals
22	> in this route are evidence for reusable rules and prototypes. When the user
23	> instead wants each supplied page image reconstructed into one final editable
24	> slide, use the Codex-supported [`image-to-pptx.md`](./profiles/image-to-pptx.md);
25	> do not turn a final-deck request into a template workspace.
26
27	## Child Workflow Dispatch
28
29	Create Template is the fixed user-facing entry and common contract. It selects one child workflow, then that child owns the kind-specific lifecycle. Do not execute two children for one workspace or blend their schemas.
30
31	\| Child workflow \| Select when \| Library-scope output \| Exclusive responsibility \|
32	\|---\|---\|---\|---\|
33	\| [`Create Brand`](./create-template/create-brand.md) \| Reuse identity only: colors, typography, logo, voice, and icon style \| `templates/brands/<brand_id>/` \| Identity analysis and identity-only `design_spec.md`; no SVG roster \|
34	\| [`Create Style`](./create-template/create-style.md) \| Reuse a communication method and visual direction without identity truth or page prototypes \| `templates/styles/<style_id>/` \| Method, page-role vocabulary, evidence/data expression, visual defaults, image/icon direction, and advisory review focus; no SVG roster \|
35	\| [`Create Layout`](./create-template/create-layout.md) \| Reuse a brand-neutral structural skeleton without a recurring communication application \| `templates/layouts/<layout_id>/` \| Canvas, page grammar, semantic text roles, Master/Layout/slot contract, and SVG roster; no brand identity or application contract \|
36	\| [`Create Deck`](./create-template/create-deck.md) \| Reuse a branded structural system or a recurring presentation application \| `templates/decks/<deck_id>/` \| Descriptive application context, integrated identity/structure, and SVG roster \|
37
38	Select Create Brand only for identity-only intent. Select Create Style when the portable value is a communication method, evidence discipline, and visual direction but there is no official identity, page geometry, or prototype roster to retain. Select Create Layout only when identity remains downstream-selectable and the reusable artifact does not prescribe communication objectives, audience outcomes, a required narrative sequence, or scenario-specific starting content. Select Create Deck when structure carries brand identity or reusable application semantics. A complete source PPTX alone does not determine the kind: classify only the stable rules worth reusing. Ask one discriminator question only when the user's requested reusable artifact is genuinely ambiguous; once selected, enter that child workflow and do not repeat route selection inside its confirmation gate.
39
40	See [`templates/README.md`](../templates/README.md) for the shared kind and
41	workspace model. Downstream template application and installation remain owned by
42	[`generate-pptx.md`](./generate-pptx.md) Step 3.
43
44	## Output scope — library (default) vs project
45
46	Output scope is a shared Create Template execution choice, not a new template kind or PPTX structure mode. Surface it in the Step 2 brief; do not invent a CLI flag or persist `output_scope` / `target_project` into portable `design_spec.md` frontmatter.
47
48	\| Scope \| `<template_workspace>` \| `<design_spec_path>` \| Registration \|
49	\|---\|---\|---\|---\|
50	\| `library` (default) \| `skills/ppt-master/templates/<kind_dir>/<template_id>/` \| `<template_workspace>/templates/design_spec.md` \| Run `register_template.py` against the matching global index \|
51	\| `project` \| `<target_project>/` \| `<template_workspace>/templates/design_spec.<kind>.<id>.md` \| Do not update any global index \|
52
53	Design Spec naming: follow [`templates/README.md`](../templates/README.md): `library` writes `templates/design_spec.md`; `project` writes `templates/design_spec.<kind>.<id>.md`, whose kind/id MUST equal frontmatter `kind`/`<kind>_id`. One project root carries at most one spec per kind and later contributes every exposed kind.
54
55	Both scopes write this contract:
56
57	```text
58	<template_workspace>/
59	├── templates/ # library: design_spec.md; project: one qualified spec per kind plus the effective Layout-or-Deck SVG roster
60	├── images/ # optional; every bitmap; SVG href is ../images/<name>
61	├── icons/
62	│ └── imported/ # optional; one canonical copy of imported vector assets
63	└── exports/ # conditional; required package evidence for multi-Master templates
64	```
65
66	Create Style narrows its contribution to the resolved `<design_spec_path>`. It
67	does not write or adopt images, icons, native payloads, or review exports;
68	pre-existing empty project scaffolding remains untouched and is not Style
69	output.
70
71	The review PPTX is derived evidence, not a source template asset. Create `exports/` only when a review deck is requested or the template declares more than one Master; multi-Master templates require the package-level gate in Step 6. Brand/Layout/Deck application reads `templates/` plus any package-owned `images/` and `icons/`; Style reads only its resolved Design Spec. No kind copies or consumes `exports/`. Library `exports/` directories are Git-ignored.
72
73	For `project`, `target_project` is required and must be an existing project initialized by `project_manager.py init`. Before the first final-output write, run one complete preflight. Apply the same collision checks to a library workspace; the only difference is that its root is under the global kind directory:
74
75	1. Resolve `<template_workspace>` from the confirmed scope and confirm its required `templates/` destination plus any needed `images/` / `icons/` destinations.
76	2. For `library`, confirm `<template_workspace>/templates/` is empty. For `project`, reject a bare `design_spec.md`, any existing spec of the selected kind, or any invalid qualified-name set. All distinct kinds may coexist. Resolve active structure before writing: Layout when present, otherwise Deck. Adding Deck beside Layout leaves the Layout roster untouched; adding Layout beside Deck atomically replaces the active Deck structural payload only after the new Layout passes isolated validation.
77	3. Resolve every final bitmap and extracted-vector filename, then confirm none would overwrite an existing file in `images/` or `icons/imported/`. Check the review-PPTX destination when preview export was requested or a multi-Master template was confirmed.
78
79	Any failed check aborts before writing the Design Spec, SVGs, images, icons, or the review PPTX. A library source remains empty-before-write; a project source preserves every non-conflicting sibling kind and replaces only a lower-priority Deck structural payload when a validated Layout takes ownership. Never overwrite an unrelated name conflict. Temporary analysis and structural-transition workspaces remain allowed because they are not final outputs.
80
81	## Process Overview
82
83	```
84	Reference Bundle Intake & Analysis -> Fact-Based Brief Proposal -> User Confirmation Gate -> Preflight + Invoke Selected Child -> Validate Child Output -> [Structured Review PPTX: optional for one Master, required for multi-Master] -> [Register Library Index] -> Output
85	```
86
87	The first three steps derive the brief from facts, not guesses. No final template directory may be created and no template SVG / `design_spec.md` may be written until `[TEMPLATE_BRIEF_CONFIRMED]` is emitted in Step 3. Reference-analysis intermediates produced by `pptx_template_import.py` (typically under `/tmp/pptx_template_import/`) are explicitly not subject to this gate — they are temporary workspaces feeding Step 2.
88
89	After dispatch, the selected child workflow executes these shared steps with its kind fixed. Child-owned fields and validation rules come from that workflow; Create Template supplies the common mechanics and never reopens the child selection.
90
91	---
92
93	## Step 1: Reference Bundle Intake & Analysis
94
95	Run every applicable input branch for the reference bundle the user supplied. A bundle may contain one source, several files of one type, multiple source types, direct text in the conversation, or no external file. This step produces analysis artefacts only — it does not create the final template directory, write `design_spec.md`, or touch any template index. When Create Brand or Create Style was selected, follow that child workflow's analysis rules and do not run page-topology analysis merely because the reference is a PPTX/PDF.
96
97	### Input source taxonomy
98
99	The rows are evidence channels, not mutually exclusive routes. Run every matching row and retain source-level provenance. The internal-strategy column applies to Create Layout/Create Deck. Create Brand uses the same reference formats for identity evidence, while Create Style extracts portable method and direction; neither has a replication strategy, SVG roster, or native-structure path.
100
101	\| Type \| What the user supplied \| Tool / read path \| Internal strategies supported by the evidence \|
102	\|------\|-------------------------\|------------------\|-----------------------------------------------\|
103	\| A `.pptx` reference \| A `.pptx` file path \| `pptx_template_import.py` → `manifest.json` + `native_structure.json` + `source_template.pptx` + layered SVGs + `assets/`; flat verification SVGs are opt-in \| `standard` / `fidelity` / `mirror` \|
104	\| B Existing SVG assets \| `projects/<x>/svg_output/`, a current template workspace root, a legacy flat template root, or a loose `.svg` folder \| Normalize the source directory, create an editable authoring IR bundle with `svg_authoring_view.py`, then use its page SVGs; also read companion `design_spec.md` / `spec_lock.md` when present \| `standard` / `fidelity`; `mirror` only when the source already carries a complete explicit Master/Layout/placeholder/native-object contract \|
105	\| C Image / visual references \| PNG/JPG/WebP images, screenshots, moodboards, PDF page visuals, or a visual-reference folder \| `ls` + `Read` each supplied visual or PDF (multimodal recognition) \| `standard` only by itself \|
106	\| D Text / document / website / asset references \| Direct conversation text, pasted requirements, Markdown/TXT, DOCX/PDF/HTML/URL, brand/design manuals, or supplied logo/icon/font assets \| Use direct text as-is; read plain text/Markdown; convert supported documents/URLs with `source_to_md.py` into a temporary analysis workspace; inventory explicit assets \| `standard` only by itself \|
107	\| E No reference material \| A template request with no external source and no substantive brief yet \| Skip analysis; collect every required value in Steps 2–3 \| `standard` only \|
108
109	Roster-free child boundary: Create Brand and Create Style do not enter the
110	structured import/materialization path below. Their child workflows may inspect
111	PPTX/PDF pages, extracted text, screenshots, or other sources as evidence, but
112	they do not preserve or derive canvas, page count/order, Master/Layout identity,
113	placeholder geometry, or an SVG roster. Create Brand extracts identity truth;
114	Create Style extracts only portable communication method and visual defaults.
115	The Type A/Type B authoring-IR and `standard` / `fidelity` / `mirror` mechanics
116	below are Create Layout/Create Deck concerns.
117
118	\| Bundle rule \| Behavior \|
119	\|---\|---\|
120	\| Combine channels \| `standard` may use every confirmed visual, textual, documentary, web, and asset source together. Do not force the user to choose one source type. \|
121	\| Derive the execution strategy \| The AI translates the user's natural-language intent plus source evidence into an internal strategy. `fidelity` requires Type A or B page evidence. `mirror` requires Type A or a complete current Type B structure contract. Type C/D/E evidence may supplement an eligible bundle but never creates native topology. Do not ask the user to choose these implementation labels. \|
122	\| Preserve provenance \| Keep facts, explicit user decisions, and AI suggestions distinct. Surface contradictions in Step 2 instead of resolving them silently. \|
123	\| Protect mirror \| Supplemental text, images, websites, or assets may explain the source but cannot alter a confirmed `mirror` graph or visuals. Use `standard` / `fidelity` when the user wants those inputs to change the resulting system. \|
124
125	Type A is the canonical mirror path: `manifest.json`, `native_structure.json`, layered lossless `svg/`, and inheritance facts describe the native structure that still exists in the PPTX package. Optional `svg-flat/` files are complete-page verification views, never structure authority. In `standard` / `fidelity`, imported facts and visuals do not define output topology.
126
127	Type B source normalization: when the supplied root exposes any `templates/` Design Spec, use `<input>/templates/` as the SVG/spec source and resolve its workspace assets from sibling `<input>/images/` and `<input>/icons/`. Otherwise, use the supplied directory itself as the legacy-flat/loose SVG source. Directory flatness is not a semantic-structure signal.
128
129	Type B is supported with caveats:
130
131	- mirror on type B — require a complete current explicit source contract. Preserve page count/order, literal visuals, root Master/Layout identities, slot metadata, supported native-object metadata, and source ownership in the new workspace. Page type for `<NNN>_<page_type>.svg` is read from the source filename when it follows the PPT Master naming convention (`01_cover.svg` → `cover`, `03a_content_two_col.svg` → `content`); fall back to `content` otherwise. A loose visual-only SVG folder has no native structure to preserve and cannot use mirror.
132	- fidelity on type B — inspect the complete page roster as visual reference, then design a broader new roster and its own Master/Layout/slot system. Existing keys, families, and repeated source chrome are not output-topology inputs.
133	- legacy or unstructured type B — old `baseline` / `preserve` / `layout_strategy: distill` / `data-pptx-layout-kind` / direct-atomic-placeholder inputs, and SVGs with no root Master identity, are visual/contextual reference for `standard` / `fidelity` only. Author a new current contract in the output workspace. Use the original PPTX Type A path when existing native Master/Layout facts must be mirrored; do not mutate the SVG source or claim topology recovery from incomplete metadata.
134	- selected free-design subset on type B — ingest only the explicitly named pages as visual reference, then author a new current structured contract in the output workspace. Do not scan or copy the whole `svg_output/` directory or silently turn unselected pages into template variants.
135
136	Internal creation-strategy boundary: `standard`, `fidelity`, and `mirror` are implementation labels derived after understanding the request; they are not user-facing creation modes. `standard` and `fidelity` author a new SVG roster and a new Master/Layout/slot system from the requested result. `mirror` preserves native facts that actually exist in a PPTX package or complete current Type B contract. Mirror may mechanically normalize transport representation for the current compiler, including fixed-layer group expansion, but it never infers missing historical intent or modifies the input. Because mirror preserves supported visual and application facts, Create Layout may use it only when the source contract already satisfies the Layout boundary: brand-neutral and application-neutral. A source outside that boundary must be re-authored internally or retained as a Deck. The strategy creates a template workspace, not a downstream generated deck; future decks are authored anew and do not inherit the source page count/order requirement.
137
138	### 1A. `.pptx` reference
139
140	Run the unified preparation helper:
141
142	```bash
143	python3 skills/ppt-master/scripts/pptx_template_import.py "<reference_template.pptx>"
144	```
145
146	This produces, in one workspace:
147
148	- `manifest.json` — single source of truth: slide size, theme colors, fonts, per-master theme summaries, asset inventory, placeholder metadata, SVG file paths, per-slide / per-layout / per-master metadata (including source-owned inherited-shape visibility), page-type candidates
149	- `native_structure.json` — analysis contract: stable master/layout keys, layout picker names, placeholder type/index/geometry, inherited-shape visibility, source hash, and source-graph quality facts
150	- `source_template.pptx` — byte-preserved analysis copy for visual/package cross-checking; it is not copied into the final template package
151	- `assets/` — extracted reusable image assets; `manifest.json` owns the asset-name mapping and SVG `href` values reuse that mapping
152	- `conversion-report.json` — source-recovery and fidelity diagnostics; retain it for audit because these warnings are not duplicated in the structural manifests
153	- `svg/` — primary view (layered template view):
154	- `svg/master_*.svg` — every slide master in the deck rendered once, including masters that no sample slide currently uses (template packages routinely ship more masters than the visible samples reference)
155	- `svg/layout_.svg` — every slide layout in the deck rendered once (its own contribution; master shapes do not* repeat here)
156	- `svg/slide_NN.svg` — each slide's own shapes and slide-local background; master / layout shapes and backgrounds are not inlined here
157	- `svg/inheritance.json` — which Layout/Master each Slide consumes plus source-owned `showInheritedShapes` / `showMasterShapes` booleans; Layout shapes follow the Slide's `showInheritedShapes`, while Master shapes require that value and the referenced Layout's `showMasterShapes`; backgrounds remain independent
158	- `svg-flat/` — optional verification view (only with `--inheritance-mode both`; one self-contained SVG per slide):
159	- `svg-flat/slide_NN.svg` — effective Master/Layout contributions permitted by the source visibility flags plus Slide-local content, painted into one SVG so opening any slide on its own shows the full page like PowerPoint would. Background inheritance remains independent. Use this for previews / screenshot pipelines / "what does the slide actually look like" sanity checks.
160	- The default `--inheritance-mode layered` emits only the canonical layered view. Pass `both` when a separate complete-page verification tree is worth the storage cost, or `flat` for round-trip use cases (legacy: `svg/` becomes self-contained slides without the master/layout/inheritance files).
161	- The importer does not generate a duplicate narrative summary or persistent SVG-size CSV. Read compact facts from `manifest.json`; run ad hoc size measurements outside the canonical workspace when needed.
162
163	Import fidelity rules:
164
165	- Placeholder metadata is recorded in `manifest.json`; master / layout SVGs show lightweight dashed guides with labels only in `svg/`, not in `svg-flat/`.
166	- Charts, SmartArt, diagrams, and OLE objects are typed placeholders in `svg/`. In `svg-flat/`, they use a preview image with a small badge when one exists; otherwise they stay visible as placeholders. Tables are converted to real SVG.
167	- Missing media and external linked images fail the import. EMF / WMF Office vector media are converted to PNG previews when supported by the local toolchain; otherwise the import fails.
168
169	It is an analysis aid, not a final direct template conversion.
170
171	Lossless payload backing + editable authoring IR:
172
173	Keep `<import_workspace>/svg/` unchanged as lossless native-payload backing. If the optional `<import_workspace>/svg-flat/` verification tree was requested, keep it unchanged too. Before the Template_Designer reads or edits any imported page SVG, create the canonical non-destructive authoring IR bundle:
174
175	```bash
176	python3 skills/ppt-master/scripts/svg_authoring_view.py "<import_workspace>/svg" -o "<import_workspace>/authoring-svg" --projection-kind layered
177	```
178
179	Only when the import explicitly used `--inheritance-mode both`, create the optional complete-page verification IR:
180
181	```bash
182	python3 skills/ppt-master/scripts/svg_authoring_view.py "<import_workspace>/svg-flat" -o "<import_workspace>/authoring-svg-flat" --projection-kind flat
183	```
184
185	Each bundle contains editable SVGs, a model-readable `authoring_summary.json`, and a tool-only `authoring_manifest.json`. The projection removes opaque text payload, duplicate hidden geometry carriers, and import-only identity attributes while keeping visible shape intent, compact preset/frame metadata, structure markers, logical ids, valid asset references, and a reserved `data-pptx-source-ref` on each imported logical object. Model-facing `data-pptx-frame` values and safe transform page coordinates use at most two decimals; normalized crop ratios, path geometry, transform linear coefficients, and the immutable lossless source retain their required precision. The summary lists the current SVG roster plus per-file canvas, size, text, image, vector, placeholder, and source-ref counts. The machine manifest records relative source files, document hashes, source paths, and initial authoring-subtree hashes; it does not duplicate opaque payload and MUST NOT enter model context. Source refs are unique within one document and are interpreted by tools together with that document's manifest record.
186
187	In-place vector and picture normalization refreshes the summary automatically.
188	After any other direct IR edit, refresh it before the next analysis pass:
189
190	```bash
191	python3 skills/ppt-master/scripts/svg_authoring_view.py "<import_workspace>/authoring-svg" --refresh-summary
192	```
193
194	`authoring-svg/` is the canonical editable IR for template creation. The lossless trees are read only by materialization when an unchanged referenced object needs supported native payload or fallback evidence. Do not edit or copy the lossless SVGs directly. The IR is not a finished template directory and must be materialized into the active authoring workspace's validated `templates/*.svg` before preview or export.
195
196	For a Type A `mirror`, final materialization is owned by
197	`mirror_template_materialize.py`; never assemble the structured output by
198	copying lossless SVGs or `svg-flat/` pages into `templates/`. The command runs
199	only after the confirmed IR edits and vector-readability pass described below.
200	`standard` / `fidelity` remain newly authored Template_Designer output and do
201	not use this compiler.
202
203	Vector illustration readability pass:
204
205	Factor large decorative vector groups out of the lightweight IR documents so the model-facing SVGs stay readable while export remains native shapes. Never run this in place on the lossless import SVGs:
206
207	```bash
208	# layered view — primary read surface and canonical extracted-vector inventory
209	python3 skills/ppt-master/scripts/extract_svg_assets.py "<import_workspace>/authoring-svg" --icons-dir "<import_workspace>/icons" --icon-namespace imported --inplace --id-prefix layered --min-decoration-bytes 3000 --clean-stale
210
211	# optional flat verification view — run only when authoring-svg-flat/ exists;
212	# reuse matching layered assets so only genuinely flat-only vectors create files
213	python3 skills/ppt-master/scripts/extract_svg_assets.py "<import_workspace>/authoring-svg-flat" --icons-dir "<import_workspace>/icons" --icon-namespace imported --reuse-inventory "<import_workspace>/authoring-svg_vector_asset_inventory.json" --inplace --id-prefix flat --min-decoration-bytes 3000 --clean-stale
214	```
215
216	The authoring SVGs in `<import_workspace>/authoring-svg/` and, when requested, `<import_workspace>/authoring-svg-flat/` are rewritten in place with compact `<use data-icon="imported/..."/>` placeholders. Each in-place extraction refreshes that bundle's `authoring_summary.json` automatically. Extracted assets have one canonical copy under `<import_workspace>/icons/imported/`; never duplicate them under `templates/icons/`. The root `icons/` directory remains a namespace container and must not contain rewritten page SVGs or inventories. The inventory is written beside the processed IR directory and records every preserved `data-pptx-source-ref`; re-inlining an asset therefore re-establishes the referenced object mapping before materialization. The existing icon embedding path re-inlines the extracted assets before final export, preserving multi-color artwork and non-square viewBox geometry as native SVG shapes. Text-bearing groups are never extracted; text must stay readable/editable in the working SVG. Extraction triggers on either many drawable elements or a large pure-vector XML block, so long single-path illustrations are factored out too. Pure-vector decoration runs inside text-bearing groups use a lower size threshold, allowing card borders and decorative paths to be extracted without hiding text. Referenced defs (`gradient` / `pattern` / `filter` / `clipPath` / `marker`) are copied into each asset and namespaced so the asset is self-contained after re-inline. If both layered and flat views are processed into the same icon namespace, keep distinct `--id-prefix` values to avoid asset ID collisions. `--clean-stale` removes only stale generated assets for the current SVG filenames and prefix inside the selected namespace; it is safe in this import workspace but should not be used against a shared hand-curated icon directory without a specific prefix.
217
218	The layered pass owns the canonical extracted-vector pool. Each new asset records a source fingerprint before generated ID namespacing. The flat pass MUST consume the layered inventory through `--reuse-inventory`: an exact fingerprint match writes only a `<use>` reference to the existing layered asset, while an unmatched flat-only subtree may create one new asset under the `flat` prefix. Do not independently extract the two views into parallel asset sets. With `--clean-stale`, a rerun also removes obsolete generated `flat_*` duplicates while retaining every reused layered reference.
219
220	Explicit complex-SVG picture normalization (optional; `standard` / `fidelity` only):
221
222	When one imported native group is deliberately being retained as one complex
223	SVG picture rather than rebuilt as editable paths, select its exact id in the
224	layered authoring IR and normalize it explicitly:
225
226	```bash
227	python3 skills/ppt-master/scripts/extract_svg_pictures.py \
228	"<import_workspace>/authoring-svg/<layered_svg_file>.svg" \
229	--select "<group_id>" \
230	--resource-root "<import_workspace>" \
231	--images-dir "<import_workspace>/picture-assets" \
232	--inplace
233	```
234
235	Repeat `--select` for multiple independent sibling groups. The tool uses an
236	imported `data-pptx-frame` when present; otherwise it measures the target with
237	Playwright, or accepts `--bounds ID=x,y,width,height`. It creates a tight,
238	self-contained SVG under `picture-assets/`, embeds reachable local resources,
239	and replaces the group at the same z-order with one `<image>`. If the object is
240	chosen for a final Master or Layout, copy that asset into the project image
241	pool and author the final fixed atom as a direct `<image>` with
242	`data-pptx-layer="master\|layout"`; export then creates one `p:pic`.
243	Nested targets are allowed only below metadata-only grouping wrappers. If an
244	ancestor carries a transform, style, clip, opacity, or other visual attribute,
245	select that outer group so the effect is not applied twice.
246
247	This is a semantic representation decision, not an import heuristic. Never run
248	it automatically, never select groups by repetition, and never use it to infer
249	Master/Layout ownership. Do not apply it to placeholders, individual imported
250	native shapes, native table/chart fallbacks, icon placeholders, or compact
251	authored presets. `mirror` must keep the source native group/picture identity
252	and therefore must not use this normalization. The original lossless `svg/`
253	tree remains unchanged and authoritative. Any optional `svg-flat/` tree remains
254	unchanged but is verification-only.
255
256	`extract_svg_assets.py` remains a different operation: it factors vectors out
257	for model readability and re-inlines them as native shapes before export. It
258	does not turn those vectors into a picture.
259
260	Read order during analysis:
261
262	\| Mode \| Required read set \|
263	\|---\|---\|
264	\| `standard` / `fidelity` \| `manifest.json`, exported assets, `svg/inheritance.json`, `authoring-svg/authoring_summary.json`, and every cleaned layered IR document (`authoring-svg/master_.svg` / `layout_.svg` / `slide_NN.svg`). Do not read `authoring_manifest.json`; it is compiler-only. The layered IR is the complete read surface: it covers Layouts unused by any sample slide (invisible in `svg-flat/` yet still template vocabulary), and per-page composition follows from `inheritance.json`. Cleaned flat pages are optional composition spot checks, not a required second pass over the same shapes. Source topology remains non-binding; the two modes differ in output design (`fidelity` designs a broader roster covering the useful visual range), not in read coverage. \|
265	\| `mirror` \| `manifest.json`, `native_structure.json`, `svg/inheritance.json`, `authoring-svg/authoring_summary.json`, and every cleaned layered Master/Layout/Slide IR document. Do not read `authoring_manifest.json`; `mirror_template_materialize.py` loads and validates it internally. The layered `authoring-svg/` tree is the sole editable and materialization input. Cleaned `authoring-svg-flat/` slides are optional visual composition checks only; never edit or feed them into template materialization. Materialization may resolve unchanged refs against the matching lossless backing without placing opaque payload in model context. \|
266
267	Use the compact facts in `manifest.json` for orientation. Use screenshots or the original PPTX only for visual cross-checking. Do not bulk-read opaque lossless payload into model context.
268
269	Interpretation rule (carries forward into Steps 2 and 4):
270
271	- `manifest.json` is the source of truth for facts about the source deck: slide size, theme colors, fonts, background inheritance, reusable asset inventory, declared source layout/master structure, and slide reuse relationships. It dictates which source facts mirror may preserve during materialization, but not `standard` / `fidelity` output topology.
272	- `authoring_summary.json` is the model-facing index for the current authoring SVG roster and readability statistics. Regenerate it after direct IR edits before analysis.
273	- `authoring_manifest.json` is machine-only provenance. Do not open or quote it in model context; the mirror compiler validates it internally against the edited IR and immutable backing.
274	- `native_structure.json` is the source of truth for source PowerPoint identity: stable layout keys, picker names, parent masters, placeholder types/indices, and the source-package hash. Mirror preserves those facts one-to-one. `standard` / `fidelity` do not mine them into the new structure.
275	- `manifest.json`, `native_structure.json`, and `svg/inheritance.json` intentionally overlap only at contract boundaries so materialization can cross-check source identity, graph ownership, and visibility; do not collapse them into a cache or substitute one for another
276	- exported `assets/` are the canonical reusable image pool — `<image>` references in `svg/` already point at these files directly
277	- exported `icons/imported/.svg` files are the canonical reusable vector illustration pool, but they are not* part of the default read set. Use `authoring_summary.json` `icon_refs` and the cleaned SVGs first. Query `*_vector_asset_inventory.json` by an exact asset id only when source-ref or fingerprint detail is required; do not load the complete inventory into model context. Open a specific imported SVG only when that asset affects the current design decision.
278	- cleaned layered authoring SVGs are the mirror editing and verification surface; they expose source ownership without requiring the model to read opaque payload. Do not use them to promote, demote, merge, or split source structure.
279	- cleaned complete-page IR documents are optional composition spot checks for authored modes and verification views for mirror. They never replace the layered editable IR or immutable payload backing.
280	- screenshots remain useful for judging composition and style, but should not override extracted factual metadata unless the import result is clearly incomplete
281
282	Mirror complete-graph gate: compare every `native_structure.json` Layout
283	and Master with the layered `authoring_summary.json` roster before offering `mirror`.
284	Every source Layout—including one unused by all source slides—must have a
285	layered IR document and matching payload backing from which a reusable
286	definition SVG can be materialized. Every source Master must own at least one retained Layout. Missing IR documents
287	or ambiguous parentage are blocking; unused identities themselves are supported
288	and must not be dropped. The compiler performs the exact source-ref and hash
289	checks from `authoring_manifest.json`.
290
291	### Basic norm extraction (mandatory when reference content exists)
292
293	Before composing Step 2, extract the template's reusable norms from the previous content. These norms are not generic design advice; they are the source deck's observable operating rules, and they must flow into `design_spec.md`.
294
295	This table applies to Create Layout/Create Deck. Create Brand extracts only the
296	identity subset defined by its child workflow. Create Style instead extracts
297	argument flow, page-message/evidence discipline, open page-role vocabulary,
298	data-expression rules, composition/density rhythm, visual defaults, and
299	image/icon direction. It must discard source-specific audience, objective,
300	page order/count, page mappings, canvas, and native structure.
301
302	\| Norm area \| Extract from \| Record as \|
303	\|---\|---\|---\|
304	\| Canvas / page geometry \| `manifest.json` slide size, SVG `width` / `height` / `viewBox` \| `[fact]` canvas format, pixel dimensions, source `viewBox`, and aspect ratio \|
305	\| Identity system \| theme colors, font usage, logo / emblem assets, recurring backgrounds \| `[fact]` when imported; `[suggested]` only for visual estimates \|
306	\| Layout grammar \| masters / layouts, repeated chrome, margins, columns, card grids, section dividers \| Template-specific rules, not generic spacing boilerplate \|
307	\| Image system \| image crops/clips, scrim/overlay treatments, baked-alpha treatments, full-bleed zones, hero-image placement, mosaic rules, captions \| Template-specific image-placement rules with source examples \|
308	\| Density rhythm \| title scale, content block count, whitespace balance, dense vs. breathing pages \| Page-type guidance for Strategist / Executor \|
309	\| Page roster semantics \| cover / TOC / chapter / content / ending variants and their intended content slots \| `design_spec.md §V Page Roster` rows \|
310	\| Asset policy \| source images / icons / textures that are part of the template vs. sample-only content \| `design_spec.md §VI Assets` or omit sample-only assets \|
311	\| Native PowerPoint structure \| `native_structure.json` plus inheritance facts \| Mirror maps the validated source graph one-to-one into a new workspace. Standard/fidelity author an independent output graph and do not distill source common structure. \|
312
313	Distinguish observed facts from template rules: "`slide_07` uses a left photo crop" is a fact; "content pages may use a left photo rail for location / product / case-study pages" is the reusable rule.
314
315	Read gate:
316
317	- `standard` / `fidelity`: read `authoring_summary.json`, every layered IR Master, Layout, and Slide, and the inheritance map; flat pages are optional spot checks
318	- `mirror`: read `authoring_summary.json`, verify and report every layered IR Master, Layout, and Slide plus the inheritance map, and leave `authoring_manifest.json` to the compiler
319
320	Do not treat authoring IR documents as final template assets. `standard` / `fidelity` author new SVGs from the confirmed brief and IR references. Mirror edits the IR and materializes it with lossless native-payload backing.
321
322	> Mirror-mode materialization path — use `native_structure.json` and `svg/inheritance.json` as model-readable structural authority. The cleaned layered IR is the editable source, `authoring_summary.json` is its model-facing index, and lossless layered SVGs are immutable payload backing; optional flat SVGs are verification-only. `mirror_template_materialize.py` consumes the machine manifest internally. Preserve only the roster, appearance, ownership, placeholders, converter-supported native metadata, and available SVG fallbacks that are actually present and validated; do not synthesize missing facts or a different graph.
323
324	### 1B. Existing SVG assets
325
326	First resolve the Type B source directory using the rule above. Create a non-destructive authoring IR bundle in a throwaway analysis workspace, then run the same vector readability pass only on that IR. Do not rewrite the user's original source directory in place.
327
328	```bash
329	python3 skills/ppt-master/scripts/svg_authoring_view.py "<normalized_svg_source>" -o "<svg_analysis_workspace>/authoring-svg" --projection-kind generic
330	python3 skills/ppt-master/scripts/extract_svg_assets.py "<svg_analysis_workspace>/authoring-svg" --icons-dir "<svg_analysis_workspace>/icons" --icon-namespace imported --inplace --id-prefix source --min-decoration-bytes 3000 --clean-stale
331	```
332
333	If the source contains one deliberately selected complex subtree that should
334	remain a single SVG picture, apply the explicit normalization above only to the
335	analysis IR. Set `--resource-root` to the narrowest workspace directory
336	that contains both the IR and every local dependency referenced by the
337	selected group. This does not authorize automatic group selection or mutation
338	of the user's original SVG directory.
339
340	Then read `authoring-svg/authoring_summary.json`, `ls` the analysis workspace,
341	and read every cleaned `authoring-svg/*.svg` to extract:
342
343	- canvas size (`viewBox` on the root `<svg>`)
344	- recurring colors (`fill` / `stroke` values; identify the dominant 2–4 hex codes as candidate theme colors)
345	- fonts (`font-family` attributes on `<text>`)
346	- placeholder usage (existing `{{...}}` strings, if any)
347	- structural decoration (recurring `<rect>` bars, `<path>` motifs, embedded `<image>` references)
348
349	Use `authoring_summary.json` `icon_refs` before opening individual
350	`<svg_analysis_workspace>/icons/imported/*.svg`. Query the generated
351	`*_vector_asset_inventory.json` by exact asset id only when provenance,
352	source-ref, or fingerprint detail is required. Do not bulk-read the inventory
353	or extracted vectors unless a specific asset affects a design decision or is
354	selected for mirror preservation.
355
356	If a `design_spec.md` or `spec_lock.md` accompanies the SVGs, read it too. In mirror it is part of the source contract and must agree with the SVG identities; in `standard` / `fidelity` it is visual/contextual reference only. Record the equivalent of a `manifest.json`'s factual fields in analysis notes so Step 2 can label them `[fact]`.
357
358	### 1C. Image / visual references
359
360	`ls` the folder (or single file) and `Read` each image / PDF page. Extract what's visible:
361
362	- rough theme colors (eyeball the dominant 2–4 hues; do NOT report exact HEX as fact)
363	- page count (count the supplied images as an approximate slide count)
364	- dominant typography style (sans / serif / display) — never report a font name
365	- decorative motifs and composition rhythm
366
367	Be explicit in Step 2 that exact HEX values, font names, and placeholder structure are estimates from visual inspection (`[suggested]`), never `[fact]`.
368
369	### 1D. Text, document, website, and asset references
370
371	Direct text in the conversation is already a valid input; do not require the user to save it as a file. Read Markdown/TXT directly. Convert supported document or website inputs into a temporary analysis workspace so the reference file or final template workspace is not modified:
372
373	```bash
374	python3 skills/ppt-master/scripts/source_to_md.py "<file_or_URL_or_dir>" -o "<text_analysis_workspace>"
375	```
376
377	Inventory explicitly supplied logo, icon, font, and other brand/design assets. Raster assets also enter the Type C visual pass; readable SVG assets may additionally enter Type B when they are page/template SVGs. Do not infer asset licensing, official status, or native PowerPoint structure from filenames alone.
378
379	Extract only what the source actually states:
380
381	- Identity rules: colors, typography, logo usage, voice, icon style, and explicit exclusions.
382	- Style method: argument flow, evidence discipline, reusable page-role vocabulary, information hierarchy, composition/density rhythm, visual defaults, image/icon direction, and optional review focus. Do not retain the source's audience, objective, page sequence, page count, or page-specific resource choices as Style rules.
383	- Structure rules: canvas, page types, grids, zones, placeholders, density, image behavior, and requested variants.
384	- Deck application: recurring situations, intended audiences/outcomes, delivery or reading assumptions, representative narrative/page roles, examples, and negative requirements. Do not convert these observations into mandatory future-use policy.
385
386	Treat an explicit value authored by the user as `[decision]` regardless of carrier: direct chat, pasted text, or a user-written Markdown/TXT/DOCX/PDF brief all retain user authorship. Merely arriving in a file does not make a statement a fact. Treat a statement as `[fact]` only when it is independently traceable to an identified external authority such as an official manual/site, or when it is machine-observable file/package metadata such as dimensions, hashes, or existing PPTX structure. Any interpretation of vague prose remains `[suggested]` and must pass the Step 3 confirmation gate. Text and asset evidence never supplies Master/Layout topology by itself.
387
388	### 1E. No reference material
389
390	Skip the analysis. Step 2 will list every Required item as `[decision]`; nothing is fact-derivable from a non-existent source. Create Brand may emit an incomplete empty skeleton only under its explicit child-workflow rule. Create Style, Create Layout, and Create Deck still require the shared confirmation gate before authoring their workspace.
391
392	---
393
394	## Step 2: Fact-Based Brief Proposal
395
396	Compose one concise natural-language proposal that states the template the AI intends to create, labelling each material value's provenance:
397
398	- `[fact]` — independently traceable external authority or machine-observable source metadata (e.g. theme color from `manifest.json`, image dimensions, or an identified official manual); a user-authored brief file is not a fact merely because it is a file
399	- `[suggested]` — AI-inferred from analysis or context (e.g. tone summary, applicable scenarios; visually estimated values from type C)
400	- `[decision]` — an explicit user-authored instruction, including exact values supplied in conversation, pasted text, or a user-written brief file (e.g. a template name, a preservation requirement, a palette, or a layout rule)
401	- `[derived]` — an internal execution value the AI derives from the request and evidence so tools can run deterministically; it is recorded for provenance but never presented as a choice the user must understand
402
403	Language adaptation rule: write the Step 2 proposal in the user's language and describe the intended result in ordinary language. Technical IDs may appear only in a compact implementation note when they are useful for audit or correction; do not require the user to understand them.
404
405	Natural-language planning rule: present one recommended creation plan, not a menu of template modes, fidelity levels, or content-policy checklists. Translate requests such as “原样还原”, “提取成可复用母版和版式”, “保留风格但重新设计”, or any equivalent prose directly into the plan. Ask a follow-up only when a missing decision would materially change the artifact and cannot be inferred safely. The user may correct any sentence in the proposal.
406
407	\| Field \| Must show \|
408	\|---\|---\|
409	\| Output scope \| Recommended `library` (default) plus `project`; explain that both use the same spec schema and asset routing, while parent path, spec filename placement, and global registration differ \|
410	\| Target project \| Required only for `project`; show the exact initialized project workspace path, not a project nickname \|
411	\| Selected child workflow \| Echo the already-dispatched Create Brand, Create Style, Create Layout, or Create Deck workflow; do not reopen kind selection inside the brief \|
412	\| Method and direction \| Create Style only. Summarize the portable communication method, evidence discipline, page-role vocabulary, information design, visual defaults, image/icon direction, and advisory review focus. Do not include a current audience/outcome, page order/count, canvas, or prototype plan. \|
413	\| Category \| Create Layout/Create Deck only. State the one discovery category inferred from the intended artifact. For Layout, a scenario category records geometric fit only and never grants application ownership. \|
414	\| Application context \| Create Deck only. Summarize the recurring presentation family, likely audiences/outcomes, delivery/reading assumptions, and representative page roles. This is descriptive selection context, not a rule saying which template pages or visible content future projects must keep. \|
415	\| Theme direction \| Create Layout/Create Deck only. Describe the intended light/dark/mixed behavior in plain language. Create Brand records identity colors instead and does not own a page theme mode. \|
416	\| Canvas \| Create Layout/Create Deck only. State the recommended canvas with exact pixel size and `viewBox`; do not enumerate same-ratio alternatives unless the user asks or the evidence is genuinely ambiguous. \|
417	\| Creation plan \| Create Layout/Create Deck only. Describe what will be preserved, what will be rebuilt, how broad the prototype roster will be, and how native structure will be handled. The AI derives the internal `replication_mode` from this prose after confirmation; never ask the user to select `standard`, `fidelity`, or `mirror`. \|
418	\| Native structure plan \| Create Layout/Create Deck only. State the planned Master/Layout/slot result. For newly authored output, show the planned Master families and reject one-Master-per-Layout organization or equivalent duplicate Masters. For literal preservation, summarize the exact supported source facts that will be mapped into the new workspace. \|
419	\| Asset bundling \| Create Brand/Create Layout/Create Deck only. Recommend included assets, plus excluded candidate assets with a one-line reason when reference assets exist. Create Style records textual provenance only and writes no asset payload. \|
420
421	Items to surface:
422
423	\| Item \| Required \| Provenance by evidence channel \|
424	\|------\|----------\|--------------------------\|
425	\| Output scope \| Yes \| `[decision]` — `library` (default, globally reusable and indexed) or `project` (qualified Design Spec under one initialized shared project root) \|
426	\| Target project \| Yes for `project`; N/A for `library` \| `[decision]` — explicit path to the initialized target workspace; validate it during the Step 4 preflight \|
427	\| New template ID \| Yes \| `[decision]` when supplied; otherwise propose a filesystem-safe ASCII slug as `[suggested]`. In library scope it also becomes the matching index key \|
428	\| Template display name \| Yes \| `[decision]` when supplied; otherwise `[suggested]`, often from `manifest.json.source.name` for type A \|
429	\| Category \| Create Layout/Create Deck only \| `[decision]` when explicit; otherwise `[derived]` for indexing — Create Deck: `brand` / `general` / `scenario` / `government` / `special`; Create Layout: `general` / `scenario` / `government` / `special` \|
430	\| Applicable scenarios \| Yes \| Create Brand: identity use cases. Create Style: broad best-fit discovery context only, without binding a target audience, outcome, or recurring application. Create Layout: content shapes and delivery settings its geometry can support, without communication or narrative ownership. Create Deck: recurring presentation situations inside the application contract. `[suggested]` from analysis unless explicitly authored or externally sourced; user confirms. \|
431	\| Application context and representative page roles \| Create Deck only \| `[decision]` when supplied explicitly; otherwise `[suggested]` from recurring source patterns. Describe the source and intended family without assigning required/optional/repeatable status or fixed/replaceable/example-only policy. \|
432	\| Identity, method, or structural summary \| Yes \| Create Brand/Create Deck: identity tone. Create Style: communication method and visual-default summary. Create Layout: structural use case and density/rhythm summary only. \|
433	\| Communication method and evidence discipline \| Create Style only \| `[decision]` when explicit; otherwise `[suggested]` from repeated source behavior. State argument flow, message/evidence discipline, page-role vocabulary, and data-expression rules without fixing a page sequence. \|
434	\| Visual-system defaults \| Create Style only \| `[decision]` when explicit; otherwise `[suggested]` from evidence. Palette, typography, mode, and visual-style values remain overrideable seeds, never Brand identity truth or direct final Stage-2 locks. \|
435	\| Review focus \| Create Style only \| `[decision]` when explicit; otherwise `[suggested]`. These checks apply only if the user separately enables visual review; the Style cannot trigger that stage. \|
436	\| Theme mode \| Create Layout/Create Deck only \| A: `[fact]` from `manifest.json` background colors. B: `[fact]` from SVG `fill`. C: `[suggested]` from visual estimate. D: `[fact]` from an independently identified external authority, `[decision]` from user-authored text in any carrier, otherwise `[suggested]`. E: `[decision]`. \|
437	\| Canvas format and dimensions \| Create Layout/Create Deck only \| A/B: `[fact]` from slide size or SVG `width` / `height` / `viewBox`; show `canvas_format`, `canvas_width`, `canvas_height`, `canvas_viewbox`, and `source_viewbox`. C: `[suggested]` from image aspect ratio. D: `[fact]` from an independently identified external authority or `[decision]` from user-authored text in any carrier when specified. E: `[decision]`, default `ppt169` (`1280x720`, `0 0 1280 720`). \|
438	\| Internal creation strategy \| Create Layout/Create Deck only \| `[derived]` from the confirmed natural-language plan and evidence. `standard` is the compact authored implementation, `fidelity` requires A/B page evidence for broader source-aligned coverage, and `mirror` requires A or B with a complete explicit structure contract for literal materialization. Create Layout mirror additionally requires a brand-neutral and application-neutral source. Persist `replication_mode` for tools, not as a user-facing mode. \|
439	\| Native structure facts \| Create Layout/Create Deck with Type A or structured Type B \| `[fact]` from `native_structure.json` / source SVG contract: master/layout counts, parentage, page assignments, placeholder identities, and multi-master status. Mirror preserves these validated facts in the new workspace; authored modes do not use them as output topology. \|
440	\| Structure ownership plan \| Create Layout/Create Deck only \| `[derived]` from the requested result. Authored output creates new Master/Layout ownership, including the reusable-family reason for every additional Master; literal preservation maps source ownership without synthesis. Every Master must own at least one emitted Layout and every Layout must have at least one emitted prototype. \|
441	\| Reference treatment \| Create Layout/Create Deck when a reference exists \| `[derived]` per page from the user's prose: closely reproduce geometry/decoration where requested, otherwise adapt the reference into the newly authored system. Literal materialization preserves supported source facts mechanically. \|
442	\| Basic template norms \| Yes when reference exists \| Create Brand uses the identity fields and provenance rules from its child workflow. Create Style uses portable method, page-role, evidence/data, composition/density, visual-default, and image/icon rules while discarding project-specific context. Create Layout/Create Deck use `[fact]` / `[suggested]` layout grammar, image system, density rhythm, page roster semantics, and asset policy from Step 1. \|
443	\| Reference source \| Optional \| already known if Step 1 ran \|
444	\| Theme color \| Create Brand/Create Deck only \| A: `[fact]` from theme XML. B: `[fact]` from dominant SVG `fill`. C: `[suggested]` from visual estimate (HEX is approximate). D: `[fact]` from an independently identified external authority, `[decision]` from user-authored text in any carrier, otherwise `[suggested]`. E: `[decision]`. Create Layout may use neutral preview paint but stores no identity color. \|
445	\| Fonts \| Create Brand/Create Deck only \| A: `[fact]` from `manifest.json`. B: `[fact]` from SVG `font-family`. C: font family is not derivable — use `[decision]` if the user supplies one. D: `[fact]` from an independently identified external authority or `[decision]` from user-authored text in any carrier. E: `[decision]` when a custom stack is wanted. Create Layout stores no typeface identity or final type scale; its structural text roles, alignment, wrapping, and capacity remain part of page grammar. \|
446	\| Design style \| Required for Create Style; optional otherwise \| `[decision]` when explicit; otherwise `[suggested]` from analysis. For Style this is an overrideable visual-direction seed, not an exact lookup token or identity lock. \|
447	\| Assets list \| Optional for Create Brand/Create Layout/Create Deck; N/A for Create Style \| A: `[fact]` from `assets/` listing; user picks which to bundle. B/C/D: retain each file's source and let the user confirm adoption. E: none. Style may cite the reference textually but never adopts an asset. \|
448	\| Keywords \| Create Style/Create Layout/Create Deck only \| `[suggested]` from analysis (3–5 short tags); user confirms. Create Brand has no keywords field or keyword index payload. \|
449
450	When the bundle includes Type A for Create Layout/Create Deck, also include in this message:
451
452	- the exact authoring-manifest documents required by the derived internal strategy and verified during Step 1
453	- a one-line summary of the source Master/Layout structure
454	- the source structure facts, including master/layout counts, multi-master status, and reason codes; state in plain language whether they will be preserved or used only as design evidence
455
456	The user replies with corrections, additions, or "all good".
457
458	> Persist the portable brief into `<design_spec_path>`. In Step 4, declare a YAML frontmatter block with the child-specific ID key (`brand_id`, `style_id`, `deck_id`, or `layout_id`) and only fields owned by that child. Create Brand follows its identity schema. Create Style persists only `style_id`, `kind`, `summary`, and `keywords`; its method and direction live in the required body sections, and it writes no canvas, category, identity, application, replication, native-structure, page-count, or roster fields. Create Layout/Create Deck persist the confirmed portable fields (`kind`, `category`, `summary`, `keywords`, `primary_color` for deck, `page_types` for layout, `canvas_format`, `canvas_width`, `canvas_height`, `canvas_viewbox`, `source_viewbox`, `replication_mode`, `native_structure_mode`, etc.). `replication_mode` is the AI-derived implementation record, not a user selection. A Deck writes descriptive application context in Template Overview and factual prototype descriptions in Page Roster rather than duplicating that prose into frontmatter. Do not persist a generic `template_id` field: it is the parent workflow's cross-kind name, not a registrar schema key. Do not persist the execution-only `output_scope` or `target_project` fields. In library scope, `register_template.py` reads this frontmatter in Step 7 so the brief flows directly into the index without the AI re-deriving it from prose.
459
460	---
461
462	## Step 3: User Confirmation Gate
463
464	MANDATORY interactive gate — this step BLOCKS Steps 4 onward.
465
466	1. Echo back the finalized brief (post-corrections) in a single message
467	2. Emit the marker `[TEMPLATE_BRIEF_CONFIRMED]` on its own line
468
469	Skipping this gate — including silently inferring values from reference files, direct text, an opened IDE file, or prior conversation — is a route violation. Even if the user already supplied a PPTX, image, website, document, asset bundle, or complete written brief, you MUST still surface Step 2 with provenance labels and obtain explicit confirmation here. The reference bundle informs the brief; it does not substitute for it.
470
471	Required outcome of Step 3 (all must be true before emitting `[TEMPLATE_BRIEF_CONFIRMED]`):
472
473	- [ ] User has been shown every Required item in Step 2 with provenance labels
474	- [ ] The user saw one concise natural-language creation plan rather than a mode menu or content-policy checklist
475	- [ ] User-facing language describes the intended result; internal enum IDs are absent or confined to an audit note
476	- [ ] User has replied with corrections or explicit acceptance of the proposed result
477	- [ ] Output scope is confirmed; both scopes use the same spec schema and asset routing with their resolved Design Spec names, while `project` includes an explicit initialized target-project path
478	- [ ] For Create Layout/Create Deck, the canvas format is fixed before SVG generation
479	- [ ] For Create Layout/Create Deck, the AI-derived internal strategy is consistent with the bundle evidence (`fidelity` requires A/B page evidence; `mirror` requires A or structured B; C/D/E channels alone permit only `standard`); Create Layout mirror evidence is already brand-neutral and application-neutral
480	- [ ] Every supplied visual, textual, documentary, web, and asset channel has been analyzed or explicitly excluded; mixed-input conflicts are surfaced rather than silently resolved
481	- [ ] For Create Layout/Create Deck mirror, the source graph and supported geometry are complete; every source Layout absent from the source-slide roster is planned as a definition-only prototype, and any genuinely missing/unsupported facts were reported; Create Layout mirror contains no retained brand identity or reusable application policy
482	- [ ] Child-specific norms from prior content have been surfaced and accepted, or explicitly marked N/A when no reference exists: identity/provenance for Create Brand; communication/evidence/visual-direction behavior for Create Style; layout/image/density/asset behavior for Create Layout/Create Deck
483	- [ ] For Create Style, the portable communication method, open page-role vocabulary, evidence/data rules, visual defaults, image/icon direction, and advisory review focus are confirmed; project-specific audience/outcome/page sequence and all identity/structure fields remain N/A
484	- [ ] For Create Layout/Create Deck, the plan makes structure ownership explicit: authored output creates a new structure without source-topology distillation; literal materialization maps validated source ownership one-to-one into a new workspace
485	- [ ] For Create Deck, the recurring presentation family, intended audiences/outcomes, and representative page roles are understood without turning them into mandatory page/content policies; for Create Layout, no application contract or brand identity has leaked into the structure brief
486	- [ ] For Create Brand, all required identity fields from its child workflow are confirmed and canvas/replication/native-structure fields remain N/A
487	- [ ] For `library`, metadata is complete enough to register into the relevant index; for `project`, the same portable template metadata is complete and no global registration is planned
488	- [ ] Marker `[TEMPLATE_BRIEF_CONFIRMED]` emitted on its own line after the echoed brief
489
490	Step 4 MUST NOT run until `[TEMPLATE_BRIEF_CONFIRMED]` has been emitted in the current conversation.
491
492	---
493
494	## Step 4: Preflight Output + Invoke the Selected Child
495
496	> Precondition: `[TEMPLATE_BRIEF_CONFIRMED]` was emitted in Step 3. If not, return to Step 3.
497
498	Select the final target from the confirmed output scope:
499
500	```bash
501	# library scope (default)
502	template_workspace="skills/ppt-master/templates/<kind_dir>/<template_id>"
503
504	# project scope
505	template_workspace="<target_project>"
506
507	# identical in both scopes; create optional roots only when writing an asset
508	mkdir -p "$template_workspace/templates"
509	```
510
511	Normally `<authoring_workspace>` equals `<template_workspace>`. When the project
512	already has the other structural kind, use an isolated project-shaped root
513	through validation and preview. Its `<design_spec_path>` is temporary;
514	`<installed_design_spec_path>` is the final table path. Create its `templates/`
515	only after preflight.
516
517	\| Scope \| Workspace target \| Required action before generation \|
518	\|---\|---\|---\|
519	\| `library` \| `skills/ppt-master/templates/<kind_dir>/<template_id>/` \| Resolve `<design_spec_path>` to `templates/design_spec.md`; run the common workspace preflight; the directory name matches the final template ID used in the relevant index \|
520	\| `project` \| `<target_project>/` \| Resolve the final spec destination to `templates/design_spec.<kind>.<id>.md`; run the project coexistence preflight. Author directly unless Layout/Deck precedence requires isolated validation before atomic install \|
521
522	The preflight is atomic at the Create Template parent level: settle every output filename and check all destinations before generation. Pass the active `<design_spec_path>` to the selected child. For a project structural transition, validate in the isolated root, then install its spec at `<installed_design_spec_path>` and its assets atomically: Layout replaces the Deck roster; Deck beside Layout installs no structural payload. Delete staging only after the final project root passes.
523
524	Create Brand branch: continue in [`create-brand.md`](./create-template/create-brand.md) §3 with the confirmed identity brief and resolved `<template_workspace>` / `<design_spec_path>`. Then return to the Create Brand branch in Step 5. Do not invoke Template_Designer, create SVGs, or apply the Create Layout/Create Deck-only material below.
525
526	Create Style branch: continue in [`create-style.md`](./create-template/create-style.md) §3 with the confirmed method/direction brief and resolved `<template_workspace>` / `<design_spec_path>`. Then return to the Create Style branch in Step 5. Do not invoke Template_Designer, create SVGs, retain source page topology, or apply the Create Layout/Create Deck-only material below.
527
528	Create Layout/Create Deck branch: continue in the selected child workflow, switch to the Template_Designer role, and generate per role definition. Bind the role's `<template_workspace>` to `<authoring_workspace>` and pass `<design_spec_path>`, the finalized brief from Step 3, and the Step-1 analysis bundle with accepted norms.
529
530	Mandatory — authored construction bundle: Immediately after the confirmed
531	creation strategy resolves to `standard` or `fidelity`, and before
532	Template_Designer selects any page or template contour, read
533	[`native-shape-authoring.md`](../references/native-shape-authoring.md) and
534	[`preset-shape-vocabulary.md`](../references/preset-shape-vocabulary.md)
535	completely and retain both for the active authoring context. Do not load this
536	bundle for `mirror`; it preserves source-owned geometry and does not select or
537	author replacement contours.
538
539	When the bundle includes Type A, pass the following internal package to the role:
540
541	- finalized brief from Step 3
542	- `manifest.json`
543	- `native_structure.json` and `source_template.pptx`
544	- `conversion-report.json` when source-recovery diagnostics exist
545	- exported `assets/`
546	- `_vector_asset_inventory.json`, when the vector readability pass extracted assets, as an exact-id query surface only; do not load it or `icons/imported/.svg` wholesale
547	- `authoring-svg/authoring_summary.json` and editable layered IR documents; keep `authoring_manifest.json` bundled for compiler use but do not load it into the role context; optional `authoring-svg-flat/` is a visual cross-check only and never a template materialization input
548	- for `mirror` only, matching immutable `svg/` payload backing plus `svg/inheritance.json`; immutable `svg-flat/` remains an optional visual cross-check
549	- optional screenshots, if available
550
551	When the bundle includes Type B, pass `authoring_summary.json`, the cleaned SVG file list from the analysis workspace, `_vector_asset_inventory.json` as an exact-id query surface if extraction ran, any companion `design_spec.md` / `spec_lock.md`, and the analysis notes. Do not bulk-read the inventory or extracted vectors; open individual `icons/imported/.svg` files only when needed.
552	When the bundle includes Type C, pass the image file list and the visual analysis notes.
553	When the bundle includes Type D, pass the direct text, converted document/website outputs, traceable source list, explicit asset inventory, and analysis notes.
554	For Type E, pass only the finalized brief.
555	For a mixed reference bundle, pass the union of the applicable packages while keeping each fact's source and every unresolved conflict explicit.
556
557	The role interprets the package according to the AI-derived internal creation strategy recorded as `replication_mode`:
558
559	\| Mode \| Final SVG authority \| Structure behavior \|
560	\|---\|---\|---\|
561	\| `standard` / `fidelity` \| Newly authored SVGs based on the confirmed brief and visual references \| Design an intentional new Master/Layout/slot system. Source topology is neither preserved nor distilled into the output. \|
562	\| `mirror` \| Editable `authoring-svg/` IR plus native-structure facts and lossless payload backing \| Materialize source pages, Master/Layout identities and parentage, placeholder identity/bounds, ownership, and supported native-object metadata one-to-one in the new workspace. Materialization resolves unchanged source refs; it does not copy the lossless tree as the editable source. \|
563
564	For Type A `mirror`, materialize the reviewed layered IR into a workspace with
565	no existing roster, using the deterministic compiler:
566
567	```bash
568	python3 skills/ppt-master/scripts/mirror_template_materialize.py \
569	"<import_workspace>" "<authoring_workspace>"
570	```
571
572	Destination `templates/` may be absent/empty or hold unique qualified
573	Brand/Style specs; a Layout-over-Deck stage may also hold one qualified Deck
574	spec without its roster. A bare spec, Layout spec, active roster, or other
575	payload blocks materialization. Before atomic publication, the command verifies
576	the layered manifest/source refs, lossless SVG/source-PPTX hashes, complete
577	native/inheritance graph, and vector inventory. It emits source-ordered page
578	SVGs, unused-Layout definition
579	SVGs, `icons/imported/`, referenced `images/` / `templates/assets/`, and one
580	deduplicated `templates/native_payloads.json.gz` store when supported native
581	payload or repeated restoration metadata exists. It also writes
582	`templates/template_execution_manifest.json` with schema
583	`ppt-master.template-execution-manifest.v1`, a compact tool-readable prototype
584	roster and grouped source-import warning summary. Each prototype points to one
585	`templates/template_execution/*.text-slots.json` sidecar with schema
586	`ppt-master.template-text-slots.v2-min`. Each slot contains only `selector`,
587	`role`, `current_text`, `text_segments`, and `tspan_count`; the complete
588	prototype remains authoritative. The manifest and sidecars are deterministic
589	tool diagnostics; page-context does not inject or require them, and models do
590	not read them during page authoring. Validators/export own attribute and
591	topology checks. Template SVGs and imported
592	vectors keep content-hash payload references plus short
593	`data-pptx-native-ref` attribute-record ids. Structural Master/Layout,
594	placeholder, layer, and editable-object fields remain inline. The command does
595	not create the Design Spec. Template_Designer writes `<design_spec_path>` from
596	the confirmed brief and the materialized roster before Step 5. A rerun targets
597	a workspace with no roster rather than overwriting a partially reviewed one.
598
599	Hard rule — mode-specific authorship: `standard` and `fidelity` author new
600	project-canonical SVG documents. When one registered PowerPoint preset exactly
601	expresses one complete object, they use the compact canonical
602	`<g>` emitted by `preset_shape_svg.py`, following
603	[`native-shape-authoring.md`](../references/native-shape-authoring.md); its
604	paint comes from the confirmed brief and `<design_spec_path>`. After
605	inserting the complete helper group, add only the registered structural
606	attributes required by its Master/Layout or object-slot role; geometry and
607	paint changes require a new helper render. When actual `standard` / `fidelity`
608	construction needs a Boolean result over supported shape/text operands, Template_Designer
609	decides whether to use `shape_boolean_svg.py` under
610	[`native-shape-authoring.md`](../references/native-shape-authoring.md) §6; a
611	brief/reference suggestion does not lock the operation. `mirror` preserves the expanded
612	lossless source contract in a new workspace and may only normalize transport details required by
613	the current compiler. Mirror never performs commonality
614	extraction, semantic synthesis, merge/split, promotion/demotion, renaming, or
615	re-parenting.
616
617	Hard rule — multi-Master package boundary: More than one Master is valid only when `mirror` preserves an existing source graph in the new workspace or an authored template intentionally defines distinct reusable design families. `standard` / `fidelity` must not create one Master per Layout or duplicate equivalent Masters merely for organization. Every declared Master must own at least one emitted Layout, and every declared Layout must be selected by at least one prototype SVG so the complete graph can be compiled and verified.
618
619	\| Package concern \| Requirement \|
620	\|---\|---\|
621	\| Theme ownership \| Every registered Slide Master receives its own Theme part. Two Masters must never resolve to the same `ppt/theme/themeN.xml`. Theme cloning is exporter-owned; do not author or bundle Theme XML in the template workspace. \|
622	\| Creation identity \| Any generated `p14:creationId` on Slides, Layouts, or Masters is a valid unsigned 32-bit value and unique across those parts. Cloned structural parts always receive fresh values. \|
623	\| Numeric registration \| Master and Layout registration IDs are valid and unique in their owning lists; Layout numeric IDs are unique across the complete package, including across different Masters. \|
624	\| Relationship graph \| The presentation registers the exact Master and Slide rosters; each Master registers exactly its owned Layouts; each Layout targets exactly one declared Master; each Slide targets exactly its declared Layout. \|
625
626	SVG authors own the semantic roster, parentage, picker names, direct atoms, and slots. The exporter owns OOXML part cloning, Theme isolation, relationship registration, and package identity. Do not encode package repair workarounds in individual template SVGs.
627
628	Do not package `native_structure.json` or `source_template.pptx` as template inputs. In `standard` / `fidelity`, author Master/Layout direct semantic atoms and bounded slot groups deliberately from the intended reusable behavior. A validated compact canonical authored-preset `<g>` compiles to one native shape and therefore counts as one semantic atom; it may own a Master/Layout fixed layer or serve as the one direct carrier of an `object` slot. Ordinary groups are not structural atoms or single-object carriers. In `mirror`, edit the layered authoring IR and use inheritance/native facts to preserve source ownership; the lossless trees remain payload backing. Recursively expand fixed Master/Layout group wrappers only because the structured contract requires semantic atoms; preserve transforms, styles, paint order, and appearance, and never flatten or regroup by semantic judgment.
629
630	`<design_spec_path> §V` records the newly authored roster for `standard` / `fidelity`. For `mirror`, add the `Source Preservation Map` required by [template-designer.md](../references/template-designer.md), with one row per source slide and its preserved Master/Layout assignment. Do not add a synthesis-decision table.
631
632	Native-shape metadata boundary: The authoring IR removes opaque payload
633	from model context while retaining stable source refs. `standard` / `fidelity`
634	use helper-generated compact canonical preset groups and project SVG/assets
635	rather than copied source payload. `mirror` materialization rehydrates only
636	native metadata already supported by the converter when a referenced
637	Slide-local/slot object's initial authoring hash still matches. Fixed layers are normalized to semantic atoms;
638	unsupported or edited objects keep the current SVG fallback and are reported
639	rather than silently replaced by stale metadata. Do not reproduce the preset
640	syntax here; its single authority is
641	[`shared-standards-core.md`](../references/shared-standards-core.md), with selection and
642	usage guidance in the native-shape reference.
643
644	Downstream, Strategist inspects the installed workspace and current content, then derives an internal application plan. The plan may use the full roster or a subset, repeat or reorder prototypes, and choose literal reuse, structural reuse, or visual-reference-only behavior. For exporter compatibility it records `template_reuse_scope` and, when structured, `template_adherence`; these are machine execution values, not user choices. `page_layouts` selects one complete authoring prototype per generated page, `pptx_masters` / `pptx_layouts` declare unique reusable definitions, and `page_pptx_layouts` assigns generated pages. No internal value forces a future generated deck to keep the source page count or order.
645
646	Apply the confirmed natural-language intent to authored output: in `standard` / `fidelity`, reproduce reference geometry and decoration where the request calls for close preservation, and adapt compositions where it calls for a reusable redesign. Mirror preserves every supported source visual represented by the validated IR and does not use this authored-page distinction.
647
648	Sprite-sheet preservation (do NOT simplify away): PPTX-exported assets are often sprite sheets — a single tall/large image referenced from multiple slides, each cropping a different region via nested `<svg ... viewBox="...">` wrappers around `<image width="1" height="1">`. This nesting is load-bearing geometry, not redundant structure. When rebuilding, preserve the exact `viewBox` crop and the outer `<svg>` placement for every image; do not flatten to a single `<image>` with direct `x/y/width/height`. Verify by sampling: if any asset's pixel dimensions don't match the on-page display aspect, it is a sprite and the wrapper must stay.
649
650	Mirror materialization contract (type A or B): when the derived implementation writes `replication_mode: mirror`, the Template_Designer role:
651
652	1. Materializes one output SVG per source page in `<authoring_workspace>/templates/`. Edit and normalize the matching `authoring-svg/` IR document, then run `mirror_template_materialize.py`; the compiler consumes the tool-only authoring manifest together with native structure facts and immutable payload backing. Do not hand-copy or independently rebuild its graph. Preserve the source Master/Layout keys and picker names, Layout parentage, slide assignment, placeholder type/index/bounds, inherited-shape visibility, ownership, paint order, and supported native metadata that are present and validated. Mechanical namespace, root-declaration, asset-path, and fixed-layer group normalization is allowed only when source ownership and appearance remain unchanged.
653	- Type A model-facing source: `<import_workspace>/authoring-svg/authoring_summary.json` plus the editable SVGs; `<import_workspace>/svg/`, `svg/inheritance.json`, and `native_structure.json` provide payload and structural backing. The compiler alone reads `<import_workspace>/authoring-svg/authoring_manifest.json`. Optional `<import_workspace>/svg-flat/` is verification-only.
654	- Type B model-facing source: `<svg_analysis_workspace>/authoring-svg/authoring_summary.json` plus its editable SVGs; the complete explicit source SVG contract is immutable backing
655	- For every source Layout unused by all source slides, additionally materialize one definition-only SVG named `layout_<layout_key>.svg` from its layered authoring IR document and payload backing. It carries the exact root identity, fixed atoms, and placeholder contract but is not a generated page assignment. Use source placeholder prompts/carriers; do not invent business content. This definition SVG lets downstream export register the Layout and any otherwise-unused parent Master without retaining an internal carrier slide.
656	2. Renames each file using the source-order-first convention `<NNN>_<page_type>.svg`, where `<NNN>` is the source-order index zero-padded to 3 digits and `<page_type>` is typically `cover` / `toc` / `chapter` / `content` / `ending` (fall back to `content` when the type cannot be confidently classified). Examples: `001_cover.svg`, `002_toc.svg`, `003_content.svg`, ..., `050_ending.svg`.
657	- Type A: derive `<page_type>` from `manifest.json.pageTypeCandidates`
658	- Type B: derive `<page_type>` from the source filename when it follows the PPT Master convention (`01_cover.svg` → `cover`, `03a_content_two_col.svg` → `content`); otherwise infer from page content or fall back to `content`
659	3. Routes bundled assets through the common workspace contract and rewrites every `<image href="...">` consistently. Keep stable source asset identity in mirror; do not rename, merge, or replace assets by semantic judgment.
660	- Type A: assets come from `<import_workspace>/assets/`
661	- Type B: resolve relative paths in source `<image href="...">` against the source SVG location and copy each unique asset; if the source already follows PPT Master conventions (assets co-located with SVGs in the same directory), copy the whole asset set and then rewrite paths
662	- Both scopes: write bitmaps to `<authoring_workspace>/images/`, point SVG references at `../images/<name>`, and keep non-bitmap template-source assets under `<authoring_workspace>/templates/`.
663	4. Copies imported vector assets once to `<authoring_workspace>/icons/imported/` and rewrites their placeholders to `<use data-icon="imported/<name>"/>`. Never place a second copy under `templates/icons/`. Other explicitly adopted icon-library references keep their existing library namespace. Do not inline these assets manually in the template working SVGs; template validation, preview, and final export all resolve icons from the workspace-root `icons/` directory.
664	5. Writes `<design_spec_path>` per [template-designer.md](../references/template-designer.md) §1. The §V Page Roster remains a factual prototype index; explicit SVG metadata is the native Master/Layout contract. `replication_mode: mirror` records how the workspace was created and only makes literal downstream reuse technically possible; it never selects that behavior or forces a 1:1 slide sequence.
665
666	Mirror mode does not simplify the visual target or synthesize layer ownership. The sprite-sheet preservation rule applies because crop wrappers carry visible geometry; preserve those wrappers and their source scope faithfully.
667
668	Expected outputs from this step (full spec → [template-designer.md](../references/template-designer.md)):
669
670	1. `<design_spec_path>` — package-specific rules only. A deck writes a descriptive Template Overview, Color Scheme, Signature Design Elements, and factual Page Roster; Typography / Assets / Placeholder Overrides are conditional. A layout writes only structure-owned Signature Design Elements and Page Roster; its frontmatter `summary` carries concise selection context, and it omits the deck-only Template Overview plus every identity section. The Page Roster must match the actual SVG files on disk and must not prescribe which pages or sample content a future project keeps. Declare portable brief frontmatter; `register_template.py` consumes it only in library scope. Do not restate generic SVG constraints, layout pattern libraries, font-size ratio bands, the canonical placeholder table, or content methodology — those are sourced from `shared-standards-core.md` / `pptx-structure-interface.md` / `strategist.md` and are already in the downstream reader's context. Full scope rule and skeleton: [template-designer.md §1](../references/template-designer.md#1-must-generate-design_specmd).
671	2. Page roster — see [Page Roster](../references/template-designer.md#page-roster) for `standard` / `fidelity` / `mirror` mode rosters, variant naming, and TOC handling
672	3. Placeholder vocabulary — pages should adopt the conventional names (`{{TITLE}}`, `{{CONTENT_AREA}}`, ...) when they fit. Full reference: [Placeholder Reference](../references/template-designer.md#4-placeholder-reference-canonical-convention-overridable-per-template). When a template style legitimately needs different vocabulary (consulting → `{{KEY_MESSAGE}}`, branded cover → `{{BRAND_LOGO}}`), declare a `placeholders:` block in `<design_spec_path>` frontmatter so the registrar and quality checker treat it as the template's authoritative contract. Avoid one-off indexed families such as `{{CHAPTER_01_TITLE}}` — use the indexed TOC pattern instead.
673	- `{{...}}` placeholders are the authoring vocabulary used to generate final slide content. Each emitted SVG also carries the native structure contract: root Master/Layout key/name, direct atomic Master/Layout elements, and direct slot `<g>` elements with explicit design-zone bounds plus exactly one compatible carrier. A validated compact canonical authored-preset `<g>` counts as one semantic atom or one `object` carrier; ordinary groups do not. Composite regions use only the explicit `object` + `proxy` downgrade. Minimal structural `data-pptx-role` hints are added only when specialized metadata cannot express required behavior. Both strict and adaptive downstream set `mode: structured` and require complete `page_layouts`, `page_pptx_layouts`, `pptx_masters`, and `pptx_layouts` from planning onward.
674	4. Template assets (optional) — both scopes apply the same `templates/` / `images/` / root `icons/imported/` routing defined above
675
676	Hard rule — placeholder examples are executable defaults: In authored
677	`standard` / `fidelity` templates, a carrier is not a floating review label. It
678	becomes the prototype Slide placeholder, while
679	`data-pptx-bounds` becomes the reusable Layout frame.
680
681	\| Concern \| Requirement \|
682	\|---\|---\|
683	\| Full editable frame \| `data-pptx-bounds` describes the complete intended text, picture, chart, table, or object box. Never derive it from the sample text's glyph bounds or leave it as a one-line tight box. \|
684	\| Generic text entry \| General `body` and text-carried `object` slots begin at the upper-left, use left paragraph alignment, and wrap inside the full frame. Title/subtitle alignment follows the authored composition. \|
685	\| Centered exceptions \| Center alignment is reserved for semantically short focal content such as KPI values, short process nodes, hero statements, and compact takeaways. Record a template-wide exception in `<design_spec_path> §IV` when it is part of the layout grammar. \|
686	\| Review Slide binding \| `template_preview_pptx.py` sizes each authored Slide carrier to the same complete frame as its registered Layout placeholder. A review deck whose Slide carrier is only the prompt text's tight box fails Step 6. \|
687	\| Review prompt legibility \| For `standard` / `fidelity`, the preview exporter substitutes concise sample text only in ephemeral review SVGs so long canonical markers such as `{{CHAPTER_NUM}}` or `{{PAGE_NUM}}` do not wrap. The source SVG markers, carrier font sizes, slot metadata, and Layout frames remain unchanged. \|
688	\| Mirror boundary \| `mirror` preserves source Slide carrier geometry exactly in the tool-side native record referenced by its text carrier and keeps `data-pptx-bounds` as the reusable Layout default. Do not normalize one to the other when the source intentionally overrides that frame. \|
689
690	---
691
692	## Step 5: Validate Template Assets
693
694	Create Brand branch: run the child workflow's §4 checklist and the shared project-safe validator below in both scopes. It detects `kind: brand`, validates the identity-only frontmatter/sections/colors/provenance/asset references, and does not require an SVG roster or touch a global index. Any failure blocks completion.
695
696	```bash
697	python3 skills/ppt-master/scripts/svg_quality_checker.py "<template_workspace>/templates" --template-mode
698	```
699
700	In `library` scope, additionally run the registrar dry-run so `brand_id` is checked against the library directory/index key:
701
702	```bash
703	python3 skills/ppt-master/scripts/register_template.py <brand_id> --kind brand --dry-run
704	```
705
706	After Create Brand validation passes, skip the Create Layout/Create Deck-only remainder of this step and all of Step 6; continue at Step 7.
707
708	Create Style branch: run the child workflow's §4 semantic checklist, then
709	the shared validator in both scopes. The validator detects `kind: style` and
710	mechanically enforces the frontmatter, section/field shape, conditional custom
711	and fallback values, portable ID, and one-file roster-free package boundary.
712	The child checklist remains authoritative for semantic scope and provenance.
713
714	```bash
715	python3 skills/ppt-master/scripts/svg_quality_checker.py "<template_workspace>/templates" --template-mode
716	```
717
718	In `library` scope, additionally run the registrar dry-run so `style_id` is
719	checked against the library directory/index key:
720
721	```bash
722	python3 skills/ppt-master/scripts/register_template.py <style_id> --kind style --dry-run
723	```
724
725	After Create Style validation passes, skip the Create Layout/Create Deck-only
726	remainder of this step and all of Step 6; continue at Step 7. Review Focus is
727	advisory content only and never activates the Generate visual-review stage.
728
729	Create Layout/Create Deck branch: set `<template_source>` to the active authoring root's `templates/`. This is `<template_workspace>/templates/` normally and the isolated project-shaped staging root during a structural precedence transition.
730
731	```bash
732	ls -la "<template_source>"
733	ls -la "<authoring_workspace>/images" "<authoring_workspace>/icons"
734	```
735
736	Compact safe page-space metadata and transform coordinates, then run SVG
737	validation on the template directory. Keep canonical authored-preset and native
738	record frames unchanged:
739
740	```bash
741	python3 skills/ppt-master/scripts/compact_svg_coordinates.py "<template_source>" --inplace --keep-native-frames
742	python3 skills/ppt-master/scripts/svg_quality_checker.py "<template_source>" --template-mode --format <canvas_format>
743	```
744
745	`--template-mode` makes the checker:
746
747	- glob `*.svg` in the template directory directly (templates do not live under `svg_output/`)
748	- skip `spec_lock.md` drift checks (templates do not ship a spec_lock)
749	- enforce roster ↔ resolved Design Spec consistency as errors (orphan files / missing files break the template contract and, in library scope, the target kind's index)
750	- emit advisory warnings when a page lacks a conventional placeholder — these are hints, not failures. Declare a `placeholders:` block in `<design_spec_path>` frontmatter to silence them when your template intentionally uses a different vocabulary
751	- require every SVG root to declare one output Master and Layout; zero-slot Layouts are valid
752	- reject ordinary Master/Layout `<g>` elements, nested structure markers, missing slot bounds, and carrier-bound slots without exactly one compatible carrier; a validated compact canonical authored-preset `<g>` is the sole fixed-layer group exception and may be one `object` carrier
753	- validate cross-page Master equality plus same-key Layout atom/slot equality
754	- warn when distinct Layout keys have identical static framing/slot contracts. Resolve this for `standard` / `fidelity`; mirror may retain the distinct source identities and records that fact in its Source Preservation Map
755
756	This checker validates the authoring contract, not the compiled OOXML package. Theme ownership, package IDs, and registered part relationships are verified by `template_preview_pptx.py` in Step 6.
757
758	Checklist:
759
760	- [ ] `<design_spec_path>` follows the kind-specific package skeleton: deck = descriptive Overview / Color / Signature / Page Roster plus conditional sections; layout = structure-owned Signature / Page Roster with no Overview, application contract, or identity sections. Generic constraints (SVG rules, pattern libraries, ratio bands, canonical placeholder table) are NOT restated. The source-derived basic norms are present as template-specific layout / image / density / asset rules, not generic advice. Deck Overview identifies recurring situations, audiences/outcomes, delivery assumptions, and representative narrative/page roles; §V Page Roster factually describes every emitted prototype without required/optional/repeatable or fixed/replaceable/example-only policy
761	- [ ] Every page declared in `<design_spec_path> §V Page Roster` exists as an SVG file in the template directory (and vice versa — no orphan files)
762	- [ ] Variant filenames follow the letter-suffix convention (e.g. `03a_content_two_col.svg`); variants typically reuse the parent type's placeholder set unless the spec frontmatter declares otherwise
763	- [ ] If TOC exists, placeholder pattern uses the canonical indexed form
764	- [ ] `<design_spec_path>` frontmatter declares `canvas_format`, `canvas_width`, `canvas_height`, and `canvas_viewbox`; PPTX/SVG-backed templates also declare `source_canvas_width`, `source_canvas_height`, and `source_viewbox`
765	- [ ] SVG `viewBox` matches the declared canvas dimensions, not just the aspect ratio (for `ppt169`: `0 0 1280 720`; for `banner`: `0 0 1920 1080`); `width` / `height`, if written, equal it
766	- [ ] Model-facing placeholder bounds and transform page coordinates use at most two decimals; normalized crop/viewBox ratios, path geometry, transform scale/rotation coefficients, authored-preset frames, and tool-side native frames retain their required precision
767	- [ ] Placeholder names follow the canonical convention where applicable; templates with intentionally different vocabularies (e.g. `{{KEY_MESSAGE}}` instead of `{{PAGE_TITLE}}`) should declare a `placeholders:` frontmatter block to silence advisory warnings
768	- [ ] Asset files referenced by SVGs exist at their resolved paths. In both scopes, bitmap references resolve through `../images/`; no bitmap remains accidentally stranded in `templates/`
769	- [ ] `<design_spec_path>` frontmatter declares `native_structure_mode: structured`; no `native_structure.json` or `source_template.pptx` is packaged
770	- [ ] Every SVG root declares Master/Layout key and picker names; Master/Layout visuals are direct semantic atoms and obey the explicit paint-order contract. Ordinary `<g>` elements remain forbidden there; a validated helper-generated compact canonical preset `<g>` is the sole group exception because it compiles to one native shape. Structural `data-pptx-role` is used only when specialized metadata cannot express required package/page-number/animation behavior
771	- [ ] Every slot is a direct `<g id>` with explicit design-zone bounds and exactly one compatible direct carrier, or an explicit composite `object` proxy. A validated compact canonical preset `<g>` may be the one carrier of an `object` slot; an ordinary multi-object group may not. Zero-slot Layouts remain valid
772	- [ ] For `standard` / `fidelity`, every placeholder bound is the complete editable box rather than the current marker text's tight bounds; general body/object carriers begin at the upper-left and only intentional short focal roles remain centered
773	- [ ] In review output, authored placeholder prompts remain readable; `template_preview_pptx.py` uses preview-only sample text and leaves every canonical source marker and carrier style unchanged
774	- [ ] `standard` / `fidelity` output SVGs and their Master/Layout/slot contracts were newly authored without preserving or distilling source topology
775	- [ ] Every additional authored Master represents a distinct reusable design family, not one Layout or an equivalent duplicate; every declared Master owns at least one emitted Layout and every declared Layout has at least one emitted prototype
776	- [ ] Mirror output preserves source slide order, Master/Layout identity and parentage, placeholder facts, and ownership; fixed-layer group expansion is mechanical and pixel-equivalent, and the Source Preservation Map lists every source slide
777	- [ ] Mirror materialization wrote one compact `ppt-master.template-execution-manifest.v1` roster and one linked `ppt-master.template-text-slots.v2-min` diagnostic sidecar per prototype; each slot has only `selector`, `role`, `current_text`, `text_segments`, and `tspan_count`; neither artifact is injected into page authoring, while validation/export check the complete prototype
778	- [ ] Mirror roots preserve source inherited-shape visibility with canonical lowercase `data-pptx-show-master-shapes` and `data-pptx-show-inherited-shapes`; same-key Layouts agree on the former, while each Slide retains its own latter value
779	- [ ] Mirror preflight covered the complete source graph; each unused Layout has one `layout_<layout_key>.svg` definition prototype and each otherwise-unused Master is retained through at least one such Layout
780	- [ ] For `standard` / `fidelity`, no duplicate-Layout-contract warning remains; mirror may keep equivalent source Layout identities when the preservation map explains them
781	- [ ] All template-creation edits used the authoring IR; Type A mirror used `mirror_template_materialize.py`, validated its manifest/hash/graph/source-ref closure before atomic publication, reused only converter-supported payload for hash-matching Slide-local/slot refs, deduplicated supported opaque payload and repeated native restoration attributes into `templates/native_payloads.json.gz`, stripped IR-only source-ref metadata, and kept fixed Master/Layout visuals as direct atoms
782	- [ ] If any SVG references an extracted vector, it uses `data-icon="imported/<name>"` and the sole SVG asset exists at `<authoring_workspace>/icons/imported/<name>.svg`; `templates/icons/` does not exist and no separate illustration embedding script was added
783	- [ ] For `fidelity` mode: every sprite-sheet asset retains its nested `<svg viewBox=...>` crop wrapper; no image whose file aspect differs from its on-page aspect was flattened to a bare `<image>`
784	- [ ] For `mirror` mode: source-page SVG count equals source page count, while additional files are exactly the required `layout_<layout_key>.svg` definitions for unused source Layouts; source-page filenames follow the `<NNN>_<page_type>.svg` convention; no new `{{...}}` authoring placeholders were inserted into materialized source-page SVGs; §V Page Roster lists every emitted file and marks definition-only prototypes explicitly
785
786	This step is a hard gate. Do not generate a review PPTX, register, install a staged structural transition, or hand the workspace to the main pipeline until validation passes. After a staged project install, rerun the checker on the final `<target_project>/templates/`; it validates the effective Layout roster when Layout and Deck coexist. A one-Master template may skip Step 6 when no review was requested; a multi-Master template must continue to Step 6 and may not register or complete before that package gate passes.
787
788	---
789
790	## Step 6: Template Review PPTX and Multi-Master Package Gate
791
792	Trigger — Create Layout/Create Deck only: Run when the user requests a PowerPoint review file or when the validated SVG roster declares more than one unique Master key. A multi-Master template requires this step even when no review artifact was requested. A one-Master template may skip directly to Step 7 when the user did not request a review file. Create Brand and Create Style always skip this step because they own no SVG roster or native structure.
793
794	Export the complete SVG roster, one prototype per slide, from the workspace root:
795
796	```bash
797	python3 skills/ppt-master/scripts/template_preview_pptx.py "<authoring_workspace>"
798	```
799
800	`<authoring_workspace>` is the final workspace normally and the isolated staging
801	root during a project structural transition. The default output is
802	`<authoring_workspace>/exports/<template_id>_template_preview.pptx`; the command
803	creates `exports/` on demand. Copy a requested/required successful review
804	artifact into the target project's `exports/` during the same atomic install.
805	The script consumes `templates/*.svg` directly, compiles the declared structured Master/Layout contract, and reopens the result. For `standard` / `fidelity`, it uses ephemeral SVG copies with concise preview-only placeholder samples so long `{{...}}` markers stay readable; canonical source SVGs and placeholder semantics are not modified. It does not require a project `spec_lock.md`, does not create a persistent intermediate project, and does not infer or distill structure.
806
807	The first export refuses an existing output. After intentionally fixing the template and replacing its prior review deck, rerun with `--force`; never rely on a silent overwrite:
808
809	```bash
810	python3 skills/ppt-master/scripts/template_preview_pptx.py "<authoring_workspace>" --force
811	```
812
813	Validation:
814
815	- [ ] Review PPTX exists under `<authoring_workspace>/exports/` and, after a staged project transition, was copied to the final project `exports/`
816	- [ ] PPTX slide count equals the template SVG roster count
817	- [ ] Package read-back reports the expected Master and Layout counts
818	- [ ] The presentation registers the exact Master and Slide rosters; every Master registers exactly its owned Layouts; every Layout and Slide relationship resolves to its declared parent
819	- [ ] Every registered Master targets a distinct Theme part; shared Theme ownership across structured Masters is a hard failure
820	- [ ] Generated `p14:creationId` values are valid and unique across Slides, Layouts, and Masters; Master/Layout numeric registration IDs are valid and unique in their required scopes
821	- [ ] For `standard` / `fidelity`, every carrier-bound placeholder on each review Slide has exactly the same type, effective index, and full frame as its registered Layout placeholder; `template_preview_pptx.py` verifies this automatically
822	- [ ] For `mirror`, source Slide-local placeholder geometry remains unchanged even when it differs from the Layout default frame
823	- [ ] The user can open one file and review every template page in deterministic filename order
824	- [ ] When Microsoft PowerPoint is available for acceptance testing, the file opens without a repair prompt and every emitted Layout appears under its intended Master. When PowerPoint is unavailable, report package read-back as the verified evidence and do not claim a PowerPoint-open result
825
826	`template_preview_pptx.py` automatically enforces the deterministic package checks above during read-back. Every applicable validation item is a hard gate for the review artifact. Fix the owning SVG/spec/asset or exporter defect before reporting the preview as verified. For a multi-Master template, any Step 6 failure blocks registration and completion; for a one-Master template, failure of an unrequested preview does not block a workspace that already passed Step 5.
827
828	---
829
830	## Step 7: Register Template in Library Index (Library Scope Only)
831
832	Branch on the confirmed output scope:
833
834	\| Scope \| Action \|
835	\|---\|---\|
836	\| `library` \| Run the registrar below after Step 5 passes and Step 6 also passes whenever it was requested or required by a multi-Master roster \|
837	\| `project` \| Skip the registrar entirely. Do not edit any global template index or library README; continue to Step 8 with index status `Not registered (project workspace)` \|
838
839	Run the unified registrar with the kind flag; it derives the corresponding index entry from `templates/design_spec.md` (frontmatter when present, prose fallback otherwise) plus the actual `templates/*.svg` file list. The registrar retains read compatibility with old flat library packages; new creation never writes that shape:
840
841	```bash
842	# For brand
843	python3 skills/ppt-master/scripts/register_template.py <template_id> --kind brand
844
845	# For style
846	python3 skills/ppt-master/scripts/register_template.py <template_id> --kind style
847
848	# For deck
849	python3 skills/ppt-master/scripts/register_template.py <template_id> --kind deck
850
851	# For layout
852	python3 skills/ppt-master/scripts/register_template.py <template_id> --kind layout
853	```
854
855	Outputs by kind (the JSON index is the single source of truth — READMEs describe the kind in prose but do not enumerate templates):
856
857	\| `--kind` \| Index updated \|
858	\|---\|---\|
859	\| `deck` \| `templates/decks/decks_index.json` \|
860	\| `layout` \| `templates/layouts/layouts_index.json` \|
861	\| `brand` \| `templates/brands/brands_index.json` \|
862	\| `style` \| `templates/styles/styles_index.json` \|
863
864	The Layout/Deck completion card's file roster is collected by globbing
865	`templates/*.svg` in the workspace. Brand/Style cards are spec-only. Legacy
866	flat Layout/Deck packages still use their root `*.svg` roster.
867
868	The index file is the complete registered-library discovery source for
869	Default [`generate-pptx`](./generate-pptx.md#step-3-template-candidate-preparation)
870	Stage-1 template controls. Step 3 prepares their candidate input without
871	interaction; the controls read only the four kind indexes, while chat discovery
872	uses the same entries to list exact workspace-root paths. Neither path scans
873	template directories. Selecting a registered entry and submitting Stage 1
874	activates installation. An exact unregistered workspace supplied by the user,
875	or the exact validated root handed off by this route in the current
876	conversation, appears as a specified candidate and is preselected when it is
877	the only supplied root; it remains labelled `explicit` and does not enter the
878	library catalog. If an explicit root exactly matches a registered canonical
879	root, it may be displayed as `library`. Bare names and style phrases are never
880	resolved implicitly or used to preselect a template.
881
882	> Recommended for new templates: declare a YAML frontmatter block at the top of `<design_spec_path>`. The registrar prefers it over prose extraction:
883	>
884	> ```yaml
885	> # style example
886	> ---
887	> style_id: consulting_analytical
888	> kind: style
889	> summary: Answer-first, evidence-led decision-document defaults without page prototypes or brand identity.
890	> keywords: [consulting, decision-support, evidence, analytical]
891	> ---
892	>
893	> # deck example
894	> ---
895	> deck_id: my_deck
896	> kind: deck
897	> category: brand
898	> summary: ...
899	> keywords: [brand, reporting, structured]
900	> canvas_format: ppt169
901	> canvas_width: 1280
902	> canvas_height: 720
903	> canvas_viewbox: "0 0 1280 720"
904	> source_canvas_width: 1280
905	> source_canvas_height: 720
906	> source_viewbox: "0 0 1280 720"
907	> replication_mode: standard
908	> # All current deck/layout templates rebuild the current structured SVG contract.
909	> # Downstream strict/adaptive use is confirmed by Strategist and is not stored here.
910	> native_structure_mode: structured
911	> page_count: 5
912	> primary_color: "#005587"
913	> ---
914	>
915	> # layout example
916	> ---
917	> layout_id: my_layout
918	> kind: layout
919	> category: general
920	> summary: ...
921	> keywords: [general, layout, structured]
922	> canvas_format: ppt169
923	> canvas_width: 1280
924	> canvas_height: 720
925	> canvas_viewbox: "0 0 1280 720"
926	> source_canvas_width: 1280
927	> source_canvas_height: 720
928	> source_viewbox: "0 0 1280 720"
929	> replication_mode: standard
930	> native_structure_mode: structured
931	> page_count: 5
932	> page_types: [cover, toc, chapter, content, ending]
933	> ---
934	> ```
935
936	> To rebuild every entry at once (e.g. after editing many specs), run:
937	>
938	> ```bash
939	> python3 skills/ppt-master/scripts/register_template.py --kind style --rebuild-all
940	> python3 skills/ppt-master/scripts/register_template.py --kind deck --rebuild-all
941	> python3 skills/ppt-master/scripts/register_template.py --kind layout --rebuild-all
942	> ```
943
944	README files describe each kind in prose only — they do not list templates.
945	The Default Stage-1 template controls and chat discovery read the JSON index files; the
946	registrar does not touch READMEs.
947
948	---
949
950	## Step 8: Output Confirmation
951
952	Produce one scope-aware, evidence-driven completion card for either location:
953
954	```markdown
955	## Template Creation Complete
956
957	Template Name: <template_id> (<display_name>)
958	Kind: brand \| style \| layout \| deck
959	Output Scope: library \| project
960	Workspace Path: `<template_workspace>/`
961	Template Source: `<template_workspace>/templates/`
962	Design Spec: `<installed_design_spec_path>`
963	Bitmap Path: `<template_workspace>/images/` ← omit when no bitmap was written or adopted
964	Imported Vector Path: `<template_workspace>/icons/imported/` ← omit when no imported vector was written or adopted
965	Review PPTX: `<template_workspace>/exports/<template_id>_template_preview.pptx` ← Create Layout/Create Deck only; omit for Create Brand/Create Style and when an optional one-Master review was not requested
966	Primary Color: <hex> ← Create Brand/Create Deck only; omit for Create Style/Create Layout
967	Index Registration: Done \| Not registered (project workspace)
968
969	### Files Included
970
971	\| File \| Status \|
972	\|------\|--------\|
973	\| `templates/01_cover.svg` \| Done \|
974	\| `templates/02_toc.svg` \| Done \|
975	\| `templates/03_chapter.svg` \| Done \|
976	\| `templates/04_content.svg` \| Done \|
977	\| `templates/05_ending.svg` \| Done \|
978	\| `exports/<template_id>_template_preview.pptx` \| Verified, when requested or required for multi-Master \|
979	```
980
981	For Create Brand, replace the SVG/review rows with
982	the Design Spec plus only real identity assets. For Create Style,
983	list only that spec. Both completion cards must explicitly
984	state `SVG roster: N/A` and `Native structure: N/A`; Style must also state
985	`Visual review trigger: N/A (advisory focus only)`.
986
987	The exact `<template_workspace>/` root in either scope is the
988	current-conversation handoff to Default Generate Step 3. It appears as the
989	specified candidate, defaults Stage 1 to template mode, and is preselected only
990	when it is the sole supplied root. After Stage 1 confirms it, the application
991	stage resolves the root's Design Spec(s) and always ignores `exports/`.
992	Brand/Layout/Deck copy or consume package-owned `templates/` plus any existing
993	`images/` and `icons/`; Style consumes only its own spec and ignores sibling
994	project scaffolding. It then authors new `svg_output/` pages
995	under the template contract and exports a new PPTX. Neither the reference
996	PPTX/SVG nor the template prototypes are upgraded in place. A legacy-flat
997	Brand/Layout/Deck package root remains readable only when it satisfies its
998	current kind contract; for Layout/Deck that includes the structured SVG
999	contract. Style has no legacy-flat form. Otherwise create a new workspace
1000	through this route.
1001
1002	---
1003
1004	## Color Scheme Quick Reference
1005
1006	\| Style \| Primary Color \| Use Cases \|
1007	\|-------\|---------------\|-----------\|
1008	\| Tech Blue \| `#004098` \| Certification, evaluation \|
1009	\| McKinsey \| `#005587` \| Strategic consulting \|
1010	\| Government Blue \| `#003366` \| Government projects \|
1011	\| Business Gray \| `#2C3E50` \| General business \|
1012
1013	---
1014
1015	## Notes
1016
1017	1. SVG technical constraints: Create Layout/Create Deck load [shared-standards-core.md](../references/shared-standards-core.md) plus [pptx-structure-interface.md](../references/pptx-structure-interface.md), and load [svg-effects.md](../references/svg-effects.md) only when the authored design uses those effects. Create Brand and Create Style author no SVG and load none of these SVG modules. Do not restate the contracts in the template's `design_spec.md`.
1018	2. Color consistency: Create Deck SVG files must use the same color scheme as `design_spec.md §II Color Scheme`; Create Layout owns no identity colors, Create Style owns only overrideable visual defaults, and Create Brand/Create Style own no SVG files
1019	3. Native-object mapping: Treat Theme/Master/Layout/Placeholder as compiled PowerPoint objects, not template kinds. Layout owns topology and placement, Brand owns identity values/assets, Style owns portable direction/method defaults, and Deck adds descriptive recurring-application context.
1020	4. Placeholder convention: `{{}}` format only; default names listed in [Placeholder Reference](../references/template-designer.md#4-placeholder-reference-canonical-convention-overridable-per-template). Override per template via `placeholders:` frontmatter when needed.
1021	5. Discovery requirement: A library template appears in the Default Stage-1 template selector and chat discovery only after `register_template.py` has updated its kind index (Step 7). A project-scoped workspace intentionally stays out of the library catalog and is consumed as an exact `explicit` workspace-root candidate. Step 3 only prepares candidates; Stage 1 confirms communication plus free design/template use together, and only a non-free confirmed selection installs a workspace before Stage 2.
1022	6. Review output: Generate `exports/<template_id>_template_preview.pptx` on request and always for a multi-Master template. It is derived local evidence, never a source input during template application, and library exports stay Git-ignored. Brand and Style never generate this preview; Style Review Focus cannot activate visual review.
1023
1024	> Full role specification: [template-designer.md](../references/template-designer.md)
1025

1025 lines MARKDOWN