| 1 | --- |
| 2 | description: Create Deck child workflow for a recurring presentation application with integrated identity and structure. |
| 3 | --- |
| 4 | |
| 5 | # Create Deck Workflow |
| 6 | |
| 7 | Enter this child workflow only after [`Create Template`](../create-template.md) dispatches `kind: deck`. |
| 8 | |
| 9 | ## Responsibility Boundary |
| 10 | |
| 11 | | Owner | Responsibilities | |
| 12 | |---|---| |
| 13 | | Create Template | Child-workflow dispatch plus the shared source taxonomy, `library` / `project` scope, confirmation gate, collision preflight, structured authoring contract, validation commands, registration, completion, and Generate PPTX handoff | |
| 14 | | Create Deck | Recurring-application interpretation, integrated identity/structure, complete `design_spec.md`, SVG roster, and deck-specific validation | |
| 15 | |
| 16 | **Hard rule — child workflow, not a top-level route**: Create Deck executes only inside Create Template. It reuses the parent workflow's Steps 1–8 and never creates a competing entry route or second confirmation gate. |
| 17 | |
| 18 | **Hard rule — recurring application**: A deck owns descriptive application context together with integrated identity and structure. The context states the recurring presentation family, intended audiences/outcomes, delivery/reading assumptions, and representative narrative/page roles. It helps later AI planning understand the resource, but it does not prescribe which prototypes or visible content a future project must keep. It is a reusable template workspace, not the user's finished content deck. |
| 19 | |
| 20 | ## Invocation Points |
| 21 | |
| 22 | 1. Use §1–2 below while executing Create Template Steps 1–3. |
| 23 | 2. After Create Template Step 4 preflights `<template_workspace>`, use §3 to author or materialize the deck workspace under the shared structured contract. |
| 24 | 3. Apply §4 in addition to Create Template Step 5, then continue through shared Steps 6–8. |
| 25 | |
| 26 | ## 1. Deck Input Interpretation |
| 27 | |
| 28 | Use Create Template Step 1 for source ingestion and internal creation-strategy feasibility. Interpret source evidence across all three segments: |
| 29 | |
| 30 | - Identity: color, typography, logo, visual voice, and icon style, with fact/suggestion provenance preserved in the brief. |
| 31 | - Structure: canvas, page grammar, Master/Layout families, slot geometry, semantic text roles, alignment/wrapping/capacity behavior, page types, image behavior, and density rhythm. |
| 32 | - Application: recurring situations, intended audiences/outcomes, delivery or reading assumptions, representative narrative/page roles, and the actual source-page vocabulary. Do not assign required/optional/repeatable status or fixed/replaceable/example-only policy. |
| 33 | - Internally, `standard` and `fidelity` author a new complete system; source topology is not output topology. `mirror` preserves only validated package/contract facts in a new workspace and never modifies the source. The AI derives this implementation from the natural-language intent; it is not a user mode selector. |
| 34 | |
| 35 | Direct conversation text, pasted requirements, converted documents/websites, images, and supplied assets are first-class evidence under Create Template Step 1. In a mixed bundle, combine the applicable identity, structure, and application evidence without erasing provenance. Exact user-authored instructions remain decisions whether they arrive in chat or a user-written brief file; vague prose remains suggested interpretation until the shared confirmation gate. |
| 36 | |
| 37 | Create Deck is selected when identity and structure must travel together, when the source is a specific organization's branded presentation system, or when reusable scenario/content semantics are requested. A complete PPTX source alone does not make the output a Deck. If only identity is stable, use Create Brand; if the reusable structure is brand-neutral and the communication application remains downstream-defined, use Create Layout. Return to Create Template dispatch before the shared confirmation marker is emitted when the evidence supports a different kind. |
| 38 | |
| 39 | ## 2. Deck Brief and Schema |
| 40 | |
| 41 | Add these child-owned requirements to Create Template Step 2: |
| 42 | |
| 43 | | Field | Requirement | |
| 44 | |---|---| |
| 45 | | Deck ID and display name | Required; `deck_id` is a filesystem-safe ASCII slug | |
| 46 | | Recurring presentation family | Required; identify the repeatable situations this Deck serves rather than listing every plausible use | |
| 47 | | Intended audiences and outcomes | Required; state who the recurring users/recipients are and what the presentation should enable | |
| 48 | | Delivery and reading assumptions | Required; state whether the family is usually presented, closely read, handed off, or used in a mixed way | |
| 49 | | Representative narrative/page roles | Required; describe the roles present in the source or useful to the recurring family without assigning future inclusion rules | |
| 50 | | Identity | Required; primary color plus supported palette, typography, logo policy, visual voice, and icon style | |
| 51 | | Canvas and page grammar | Required; exact canvas, page types, variants, grids, zones, density rhythm, and image behavior | |
| 52 | | Native structure | Required; Master families, Layout ownership, slot vocabulary, and zero-slot Layouts where intentional | |
| 53 | | Creation intent | Required as natural-language prose: what should remain recognizable, what should be rebuilt into a reusable system, and whether the source page set should be preserved broadly or distilled. The AI derives `replication_mode` internally. | |
| 54 | | Adopted assets | Optional; list included and excluded candidates with reasons | |
| 55 | |
| 56 | Write this complete schema: |
| 57 | |
| 58 | ```markdown |
| 59 | --- |
| 60 | deck_id: <confirmed slug> |
| 61 | kind: deck |
| 62 | category: brand | general | scenario | government | special |
| 63 | summary: <one-line recurring presentation family and intended outcome> |
| 64 | keywords: [<three-to-five tags>] |
| 65 | primary_color: "#XXXXXX" |
| 66 | canvas_format: ppt169 |
| 67 | canvas_width: 1280 |
| 68 | canvas_height: 720 |
| 69 | canvas_viewbox: "0 0 1280 720" |
| 70 | replication_mode: standard | fidelity | mirror |
| 71 | native_structure_mode: structured |
| 72 | page_count: <N> |
| 73 | --- |
| 74 | |
| 75 | # <Deck Name> — Design Specification |
| 76 | |
| 77 | ## I. Template Overview |
| 78 | ## II. Color Scheme |
| 79 | ## III. Typography |
| 80 | ## IV. Signature Design Elements |
| 81 | ## V. Page Roster |
| 82 | ## VI. Assets |
| 83 | ## VII. Placeholder Overrides |
| 84 | ``` |
| 85 | |
| 86 | `replication_mode` is required machine provenance, not a user-facing choice. Omit Typography only when the shared default is intentionally used. Omit Assets and Placeholder Overrides when none exist. Do not restate generic SVG constraints, layout libraries, font-ratio bands, or the canonical placeholder table. |
| 87 | |
| 88 | Write Template Overview as descriptive application context. In Page Roster, |
| 89 | describe each prototype's observed or intended role, visual character, |
| 90 | reusable slots, and structural capacity. Do not add required/optional/ |
| 91 | repeatable status or fixed/replaceable/example-only content policy; downstream |
| 92 | Strategist inspects the actual template and current content and decides what to |
| 93 | use. |
| 94 | |
| 95 | ## 3. Author or Materialize the Deck |
| 96 | |
| 97 | Follow Create Template Step 4 and the shared Template_Designer contract with `kind: deck`, `kind_dir: decks`, and `id_key: deck_id` fixed. Do not ask the user to choose the kind again. |
| 98 | |
| 99 | The output is: |
| 100 | |
| 101 | ```text |
| 102 | <template_workspace>/ |
| 103 | ├── templates/ # design_spec.md + SVG prototypes |
| 104 | ├── images/ # optional adopted bitmaps |
| 105 | ├── icons/ |
| 106 | │ └── imported/ # optional imported vectors |
| 107 | └── exports/ # conditional review evidence |
| 108 | ``` |
| 109 | |
| 110 | Every SVG is a complete preview and declares one root Master and Layout under the shared structured contract. The deck's SVG paint, typography, and adopted assets must agree with its identity segment. Every additional authored Master represents a distinct reusable design family, not one Layout or an organizational duplicate. |
| 111 | |
| 112 | ## 4. Deck Validation |
| 113 | |
| 114 | In addition to Create Template Steps 5–6, verify: |
| 115 | |
| 116 | - `templates/design_spec.md` contains `deck_id`, `kind: deck`, `summary`, `primary_color`, canvas fields, `replication_mode`, `native_structure_mode: structured`, and `page_count`; `summary` names the recurring presentation family/outcome rather than only visual tone. |
| 117 | - `deck_id` matches the confirmed workspace ID in library scope. |
| 118 | - Template Overview, Color Scheme, Signature Design Elements, and Page Roster exist; Template Overview describes the recurring application context, every roster row factually describes its prototype and slots without future-use policy, and conditional sections match real choices/assets. |
| 119 | - Every identity color is `#RRGGBB`; the primary table row matches frontmatter, and SVG paint follows the confirmed identity. |
| 120 | - Every SVG in the roster satisfies the shared Master/Layout/slot contract and the roster is bidirectionally complete. |
| 121 | - Every referenced image/icon exists under the same workspace; this workflow created no optional directory solely to leave it empty. Pre-existing initialized-project scaffolding is allowed and remains untouched. |
| 122 | |
| 123 | For library scope, Create Template validates and registers with: |
| 124 | |
| 125 | ```bash |
| 126 | python3 skills/ppt-master/scripts/register_template.py <deck_id> --kind deck --dry-run |
| 127 | python3 skills/ppt-master/scripts/register_template.py <deck_id> --kind deck |
| 128 | ``` |
| 129 | |
| 130 | For project scope, skip both commands. The exact workspace root becomes the next Generate PPTX Step 3 input; any separately supplied Brand, Style, or Layout workspace overrides the corresponding complete segment downstream without mutating this deck workspace. |
| 131 |