ipollowork-presentations git:20260922.10a5d60A

Immutable. This exact content never changes and is served at /api/v1/blob/7fff38620887a408.

---
name: ipollowork-presentations
description: Create, revise, and verify slide presentations in an active iPolloWork Design session while retaining the selected template's visual and editable contracts.
---

# 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. The host queries capabilities and checks saved-file placement and generation receipts; preview remains required. Do not replace this workflow with a verbal assessment or a self-selected geometric style.

## Required references

Before authoring, read [Shared creative guidelines](references/shared-guidelines.md), then [PPT authoring and verification rules](references/slides-ppt.md) and the [PPT layout guide](references/layout.md). Resolve both relative to this installed Skill, not the user's project or a repository checkout. These packaged references carry the detailed rules; the workflow below is an execution summary. 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, establish an available preview/capture path and each chosen layout’s content capacity. Follow the references’ render → inspect → local repair → re-render loop on every slide with final fonts and saved assets. Fix overlap and unreadable contrast within scope, then Chinese orphan endings and spacing; do not stop at source validation or successful image generation. Check editability and requested exports separately. Missing render access means visual verification is incomplete, not passed; avoid repeated environment scans or ad hoc dependency installation.

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. When multiple suitable models have no task preference or approved automatic policy, ask once before image-dependent pages; never silently use defaultModel or downgrade to shapes. Continue independent text/layout work with the asset pending, and do not claim complete delivery until the choice is answered or the user declines. 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, the whole-deck overview, and every slide 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. Review long Chinese titles, dense pages, charts and new layouts. Exercise the relevant editor capabilities and actually produce and inspect requested exports, including PPTX editability when required. Fix affected pages and recheck shared-style impacts. Report actual artifact paths and distinguish source checks, rendered checks, editor checks, export checks and remaining gaps; never claim an unperformed check passed.