iPolloWork Presentations

Use this Skill for slide and presentation work inside the current iPolloWork Design session. It does not provide or control the built-in presentation canvas, template library, editor, or export UI.

Before initial/full authoring, call media/artifact_media_review phase=plan with the active HTML sourcePath and visual needs; follow references/shared-guidelines.md. Before final delivery call phase=check, resolve pending/missing assets and disclose fallbacks. Call media/artifact_preview_review once with kind="slides" after authoring and again only after repairing reported issues. This client action is the sole preview and whole-deck batch-acceptance entry. Never start a temporary server, create helper preview HTML, use generic browser screenshots, or capture slides one by one. Do not replace either workflow with a verbal assessment or a self-selected geometric style.

Required references

Before authoring, read Shared creative guidelines, then PPT authoring and verification rules and the PPT layout guide. Read each reference once per task and retain it in context; do not reread full files after edits. If Design Studio already routed the task here, this packaged shared reference replaces its copy for the remainder of the slide task. Resolve paths relative to this installed Skill, not the user's project or a repository checkout. If a reference is missing, report an incomplete Skill installation rather than claiming to have followed it.

Workflow

1. Use the exact presentation entry file supplied by the active session and read it before editing.
2. Read the confirmed brief and template metadata when present. Identify whether this is initial creation, a narrative rewrite, a targeted edit, or a theme-only change. For theme-only changes, preserve content, slide count/order, assets and object geometry; check font fit without silently rearranging the deck.
3. For initial creation and full redesign, assess each page's message, content relationship, asset purpose, reusable files and missing imagery before committing to a layout. Query capabilities where required by the shared guidelines, then choose a fitting public/local layout or write a new one. For product, people, place, case-study or cover imagery with no suitable existing asset, actually query the media service before settling on a text/geometric-only design. Lack of source photos does not mean illustration generation is unavailable. Explicit pure-text requests, content fully served by editable charts, theme-only edits and explicit no-generation requests do not require this query; choosing a geometric design yourself is not a pure-text user request. Let content and explicit user constraints determine narrative and page count; select, repeat, recombine, remove or reorder template patterns. Do not inherit sample counts, order, copy or assets. Do not require an extra outline approval unless the user requests it or a consequential choice remains unresolved.
4. Preserve the template's distinctive visual system, fixed stage, navigation/runtime behavior, editable object contract, and design-tokens.css link so Design System controls and exports continue to work.
5. For targeted and follow-up edits, preserve unrelated user-authored slides and content. Never replace the deck with a generic presentation.
6. Keep source files, supporting assets, and requested exports inside the current design/<session-id>/ directory.
7. Before composing, check each chosen layout’s content capacity. Use media/artifact_preview_review as the only client preview path and whole-deck batch check, collect its defects, then perform one consolidated repair and one targeted recheck. A shared-style change triggers one batched whole-deck recheck. Fix overlap and unreadable contrast within scope, then Chinese orphan endings and spacing. Check editability once and requested exports separately. Missing client access means visual verification is incomplete, not passed; do not replace it with environment scans, temporary servers, ad hoc dependency installation, browser tabs or per-slide screenshots.

The active session's injected Design and template contracts remain authoritative whenever they are more specific.

Custom template scope

Apply the shared guidelines’ separate source and layout-freedom decisions. A saved custom template without a catalog can supply reusable patterns from its source; an uploaded PPT/HTML or screenshot supplies only the evidence actually available. A screenshot is not an editable template. With no reference, establish a coherent visual system from the brief and existing brand requirements. Default to retaining style while adapting structure to content; preserve exact layout only when explicitly requested or already agreed. Targeted edits and theme-only changes keep their narrower scope. Public layouts never override the custom visual identity. Verify actual import/edit/export support rather than promising source fidelity from the file type alone.

Content-led layout adaptation

Follow the injected template layout contract. Extract the template's type hierarchy, palette, spacing rhythm and graphic primitives before composing. Choose layouts by slide purpose: comparison, timeline/process, evidence/chart, case study or key statement. Reuse a fitting slide, vary its proportions and emphasis, or build a new composition from those primitives. Keep the fixed stage and editable-object contract; extending layouts does not permit unsupported export elements.

Respect explicit exact-layout requests and leave unrelated slides unchanged during targeted edits. Review the deck as thumbnails and at presentation size for narrative rhythm, repeated layouts without a content reason, dense text, clipping and visual consistency. Split or recompose when allowed by the user's page constraint; do not shrink text or omit facts just to fill an inherited layout.

For slides and sites, read core-v1-index.md beside brief.json first, then only the active type's core-v1-slides/ or core-v1-site/ catalog, layout guide and shared contract. The index maps shared content relationships; implementations remain type-specific. PPT keeps its fixed canvas and supported editable markers; websites use responsive flow and semantic interactions. Video uses the Video Studio workflow and its core-v1-video/ catalog with separate timing and playback constraints. Reuse fitting global or local patterns; new layouts remain valid. Copy only structural fragments and scoped styles, excluding preview hosts, palettes and scripts. Preserve the active template's tokens unless restyling is requested, and verify real content/assets under the type rules. Catalog verification never substitutes for current delivery checks.

Media and mode boundaries

Use the shared guidelines' visual-purpose and model-selection rules as the single decision policy. During page planning, identify the visual benefit, reusable assets and best medium internally; do not create a separate assessment report or approval step. Proactively supplement useful product, people, setting, story and cover imagery. Prefer editable charts/process/architecture diagrams; pure decoration does not require generation. Use image-generation for supporting images even when Studio is closed. Native editable PPT supports image objects, and a text-only attachment or geometric example does not prohibit imagery. Resolve the model once for compatible assets. Routine supporting imagery is an approved automatic-selection flow: use a suitable authorized saved preference or defaultModel, and do not ask or leave imagery pending solely because several models are available. Ask only for a requested choice or a material provider, cost or capability tradeoff. Never substitute an explicitly limited model without permission. Missing authorization or query/generation failure must not block the file: report the actual asset state and use a coherent fallback without opening settings. Generate during authoring and verify saved-file placement before delivery; generated scenes cannot replace real evidence.

For native editable PPT, retain supported object markers and let the Design panel own navigation. Do not add presentation scripts, keyboard handlers, controls, speaker-note nodes, responsive reflow or unsupported animation. If notes are requested but cannot be embedded, provide a separate script with the limitation stated. For HTML presentations, retain only the current template's supported runtime, notes and motion; keep presenter-only instructions out of visible slide content. HTML playback is not proof of native PPTX support. Keep text and shape markers on separate elements; verify exported text coverage. If no callable product export capability is available, report that limitation and direct the user to the client export UI. Do not reconstruct an approximate PPTX with an unrelated script and call it the native export.

Completion evidence

Check source fidelity and structure, cover every slide through a batched render/blank-resource check, and inspect representative and flagged slides at presentation size. Verify the asset decision separately from layout validity: retain the reason for reuse/generation/no generation, actual required capability calls, saved files and placement, or an accurate pending/unavailable/failed status in the task record. No capability call means capability and authorization were not checked; it does not mean no model is authorized. Do not require a fixed image count. Exercise affected editor capabilities once and produce/inspect exports only when requested or required for formal acceptance. Fix affected pages together and recheck shared-style impacts as one batch. Report actual artifact paths and distinguish source, rendered, editor and export evidence; never claim an unperformed check passed.