iPolloWork Template Generation
Create a reusable template, not a one-off artifact. The product-selected category and server validator are authoritative.
Route The Work
- Read references/template-generation-contract.md.
- Read exactly one surface reference:
- Design: references/design.md
- Slides or native editable PPT: references/slides-ppt.md
- HyperFrames Video: references/video.md
- When converting an existing project, preserve its category, surface, structure, and source files. Saving creates a new personal template; it never updates the source template.
Conversational Authoring
Guide the user in this order: purpose and audience, content structure, reusable variables, visual/design system, surface-specific constraints, generation and validation.
- Ask one consequential question at a time.
- Do not ask for information the user already supplied.
- Once the project is sufficiently specified, edit the project and show the result instead of extending the interview.
- Keep the package manifest, variable declarations, cover, and validation checklist current after every structural change.
- Treat the selected design system as optional context. Load only its manifest, usage guide, and design rules; never load every installed system.
- Use local assets or stable user-provided asset URLs. Do not invent dependencies.
Package Loop
- Maintain
manifest.json, the surface entry, design-tokens.css, local assets when needed, and a 960 x 540 cover.
- Put reusable content in typed manifest/HyperFrames variables and reusable visual choices in
--ipw-* tokens. Do not mix content variables with design tokens.
- Preserve structural invariants while applying themes: DOM meaning, responsive layout, slide geometry/PPT markers, or video timing/tracks/compositions.
- Run the product validator before saving:
node .codex/skills/ipollowork-template-generation/scripts/audit-template.mjs <template-directory>
- Repair every error. Warnings must be resolved or deliberately accepted.
- Re-instantiate the staged package and verify that the correct right-side editor opens, variables remain editable, theme switching preserves structure, and the source project is unchanged.
Hard Boundary
This Skill is guidance for repository agents. Product runtime behavior does not depend on Skill discovery. Authoring System Context and the shared server validator provide the same category rules to every user.
Completion
Report the selected surface/category, files changed, reusable variables, design-system coverage, preserved surface invariants, validator result, re-instantiation result, and any remaining warning.
1---2name: ipollowork-template-generation3description: Create or update reusable iPolloWork templates through conversation for Design, Slides/native editable PPT, and HyperFrames Video. Use when planning, generating, repairing, validating, or saving a template package, manifest, reusable variables, cover, slide/PPT markers, video composition, or design-system token integration.4---5
6# iPolloWork Template Generation
7
8Create a reusable template, not a one-off artifact. The product-selected category and server validator are authoritative.
9
10## Route The Work
11
121. Read [references/template-generation-contract.md](references/template-generation-contract.md).
132. Read exactly one surface reference:
14 - Design: [references/design.md](references/design.md)
15 - Slides or native editable PPT: [references/slides-ppt.md](references/slides-ppt.md)
16 - HyperFrames Video: [references/video.md](references/video.md)
173. When converting an existing project, preserve its category, surface, structure, and source files. Saving creates a new personal template; it never updates the source template.
18
19## Conversational Authoring
20
21Guide the user in this order: purpose and audience, content structure, reusable variables, visual/design system, surface-specific constraints, generation and validation.
22
23- Ask one consequential question at a time.
24- Do not ask for information the user already supplied.
25- Once the project is sufficiently specified, edit the project and show the result instead of extending the interview.
26- Keep the package manifest, variable declarations, cover, and validation checklist current after every structural change.
27- Treat the selected design system as optional context. Load only its manifest, usage guide, and design rules; never load every installed system.
28- Use local assets or stable user-provided asset URLs. Do not invent dependencies.
29
30## Package Loop
31
321. Maintain `manifest.json`, the surface entry, `design-tokens.css`, local assets when needed, and a 960 x 540 cover.
332. Put reusable content in typed manifest/HyperFrames variables and reusable visual choices in `--ipw-*` tokens. Do not mix content variables with design tokens.
343. Preserve structural invariants while applying themes: DOM meaning, responsive layout, slide geometry/PPT markers, or video timing/tracks/compositions.
354. Run the product validator before saving:
36
37```powershell
38node .codex/skills/ipollowork-template-generation/scripts/audit-template.mjs <template-directory>
39```
40
415. Repair every error. Warnings must be resolved or deliberately accepted.
426. Re-instantiate the staged package and verify that the correct right-side editor opens, variables remain editable, theme switching preserves structure, and the source project is unchanged.
43
44## Hard Boundary
45
46This Skill is guidance for repository agents. Product runtime behavior does not depend on Skill discovery. Authoring System Context and the shared server validator provide the same category rules to every user.
47
48## Completion
49
50Report the selected surface/category, files changed, reusable variables, design-system coverage, preserved surface invariants, validator result, re-instantiation result, and any remaining warning.
gabrielmoreira