unify template authoring rules, media workflows, and streaming feedback

.agents/skills/image-generation/SKILL.md

@@ -1,14 +1,15 @@
 ---
 name: image-generation
-description: Generate image assets through the active iPolloWork Image Studio while preserving structured style, camera, lighting, size, and quality choices.
+description: Generate image assets through iPolloWork's image service, whether Image Studio is open or closed.
 ---
 
 # Image generation
 
-Use this Skill when the user wants a new image and Image Studio is active.
+Use this Skill for a requested new image or a missing supporting image identified while authoring a PPT, website or video. Image Studio does not need to be open. Plan assets during initial creation/full redesign; preserve narrow edit scopes and explicit no-image requests. Reuse suitable assets first; visual clarity and context are valid reasons to generate, not only absolute necessity. Assess the visual purpose, existing assets and best medium internally; no separate assessment report is required. Keep diagrams editable, treat pure decoration as optional, and never present generated illustrative scenes as real evidence.
 
 1. Preserve the user's subject, composition, text, brand, and format requirements.
-2. Put visual style, camera, and lighting into the matching structured Image Studio fields when possible instead of repeating them throughout the prompt.
-3. Use the installed provider exposed by Image Studio. Never request, print, or place API keys in a prompt or workspace file.
-4. Save generated results as new workspace artifacts and report the exact returned path.
-5. Keep the first pass focused. Generate variants only when the user asks for alternatives.
+2. Discover `openai-image-generation` using `ipollowork_extension_list_actions`, then call its `status` action. Call status first and check authorization, capabilities and supported parameters. Preserve a model explicitly selected for this task or captured workbench request. If it is unavailable or unsuitable, ask before substituting unless alternatives were already authorized, and continue independent file work. For no explicit model, use a verified suitable user-saved preference or existing automatic-selection policy, or the sole suitable authorized model within the task scope and allowed cost settings. With multiple suitable models and no such preference or policy, ask once for the task before committing any image-dependent page; never silently use `defaultModel` or downgrade to shapes merely to avoid the question. Continue independent text/layout work if useful, mark the asset pending, and do not claim the complete deliverable until the choice is answered or the user declines the image. Reuse the verified selection for compatible assets; recheck when the model, operation, parameters or authorization state changes or a service error requires it. A first-result/defaultModel fallback is not evidence of a saved user preference. Missing authorization or an unqueryable capability must not block the caller or open settings: report the state and continue. Never request keys in chat. Do not invent preferences or budgets. Pass the chosen stable model ID explicitly. Never submit variants outside scope; query or recover uncertain jobs before resubmitting. In this image status response, `defaultModel` is an automatic first-available candidate, not a persisted user preference. For an explicit workbench settings/annotation request, honor its captured selection instructions; do not change the workbench model through UI automation.
+3. After resolving the model by this policy, call `image_generate` through `ipollowork_extension_call` with that exact stable `model` ID, the prompt, and optional quality/size. Include style, camera, and lighting requirements in the prompt.
+4. Use this server action for ordinary chat requests even when Image Studio is open. UI tool discovery and opening the workbench are unnecessary. Use workbench tools only when the user explicitly requests the current workbench settings or selection. Never request, print, or place API keys in a prompt or workspace file.
+5. Save generated results as new workspace artifacts and include a Markdown image link to the exact returned path in the final response. Never claim success until the action returns the saved file. For a composition, place the saved image under its existing assets directory, use a project-relative reference, and verify loading, crop and export compatibility before delivering the composition. Standalone images can be opened in Image Studio from the conversation.
+6. Keep the first pass focused. Generate variants only when the user asks for alternatives.

.agents/skills/ipollowork-design-studio/SKILL.md

@@ -7,13 +7,25 @@ description: Create or edit HTML designs inside an active iPolloWork Design Stud
 
 Use this Skill only for a design project already owned by the active iPolloWork session. The built-in Design Studio, templates, editor, undo history, and exports exist independently of this Skill.
 
+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.
+
 ## Session contract
 
 - Treat the active session's injected Design contract and exact editable path as authoritative.
 - Read the current HTML and its adjacent `design-tokens.css` before editing.
 - Keep all changes inside the current `design/<session-id>/` project.
 - Never create a replacement project, start another preview server, or alter iPolloWork application files.
 
+## Required type rules
+
+Before editing, resolve the category from the session contract and manifest, or infer it from the requested deliverable when no manifest is available. Read this Skill's [references/shared-guidelines.md](references/shared-guidelines.md) and [references/design.md](references/design.md), then only the matching category reference listed there. Resolve these paths relative to the current installed Skill, not a remembered checkout. If a file is missing, check the advertised Skill location once and report the gap; never pretend to have read it.
+
+Use this sequence for bundled/custom templates, fully custom generation and follow-up edits while preserving the narrower edit scope. Type references own structure, interaction and acceptance checks; shared guidelines and media Skills own asset and model decisions.
+
+For `category: "slides"`, use `ipollowork-presentations` and its packaged `references/shared-guidelines.md`, `references/slides-ppt.md` and `references/layout.md`, including for HTML decks. Preserve the HTML presentation runtime or native editable PPTX contract as appropriate.
+
+For `category: "video"`, use `ipollowork-video-studio` and the session's Video surface contract. Do not replace the timed composition with a Design HTML page.
+
 ## Editing rules
 
 1. On the initial brief application, derive the content structure from the brief and treat the installed template's sections and components as reusable visual patterns. Add, remove, reorder, repeat, or recombine them when the content requires it; do not carry inherited sample structure forward by default.
@@ -25,6 +37,10 @@ Use this Skill only for a design project already owned by the active iPolloWork
 
 If the active session provides stricter instructions, those instructions take precedence.
 
-## Content scope
+## Content-led layout adaptation
+
+Follow the injected template layout contract. Before editing, identify reusable typography, palette, spacing, shapes and artwork in the source; sample section geometry is not fixed. Match each section to its purpose: comparison, steps, evidence, case study or key message. Reuse a fitting pattern, vary its proportions/columns/alignment, or compose a new layout from the same primitives. Keep coherent reading order and responsive behavior across widths; do not reduce every section to the same card grid.
+
+Respect an explicit request to match the template exactly, fixed-brand regions and selected-element scope. Inspect rendered sections for overflow, excessive density, unjustified repetition and style drift. Recompose dense content rather than shrinking text or deleting facts; do not introduce variety merely for decoration.
 
-Let content determine page count, scene count, and duration. Template sample quantities and timings are not limits, even when an inherited checklist calls them fixed. Apply counts or duration constraints only when explicitly requested by the user. Approximate targets allow reasonable variation; explicit maximums remain strict. Do not omit important content or add filler to fit a template. For narration, pass `targetDurationSeconds` only for a user duration request and synchronize scenes to actual audio duration.
+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.

.agents/skills/ipollowork-design-studio/references/design-app.md

@@ -0,0 +1,24 @@
+<!-- Distribution reference: maintained in .codex/skills/ipollowork-template-generation/references/; checked against the source by plugin-package-manifest.test.ts. -->
+
+# Application Interface Rules
+
+Use for `app`: screens, dashboards and interactive prototypes. Read `design.md` and shared guidelines first.
+
+## Tasks and structure
+
+- Identify the main user task, entry state, action and observable outcome. Select screens and states from that flow rather than copying a sample dashboard.
+- Reuse navigation, controls, spacing and state language. Do not fill space with invented analytics, customers or activity.
+- Choose suitable forms, tables, lists, inspectors and detail views. Marketing sections are not a substitute for a usable application flow.
+- Keep the implementation boundary explicit: an HTML prototype may demonstrate local interaction, but does not establish authentication, persistence, payment or remote integration.
+
+## States and assets
+
+- Cover normal, loading, empty, invalid, failed and completed states needed by the flow. Keep transitions consistent; success must reflect an actual or clearly labeled simulated outcome.
+- Preserve input after validation errors. Explain unavailable actions and protect destructive actions appropriately within the artifact's scope.
+- Use labeled inputs, accessible state feedback, keyboard navigation and visible focus. Test menus, dialogs, escape/close and forms; do not rely on hover alone.
+- Adapt dense navigation/data to narrow screens through intentional scrolling or alternate views, rather than clipping controls or squeezing labels.
+- Follow shared media rules for meaningful product/content visuals. Prefer editable charts for data and consistent icons for navigation; decorative generation remains optional.
+
+## Acceptance
+
+Drive the primary flow from entry to outcome, including relevant empty/error/recovery cases. Check representative widths, long labels and realistic data volumes. Verify edit/save claims in the supported runtime. Distinguish prototype behavior from connected services and identify untested states.

.agents/skills/ipollowork-design-studio/references/design-article.md

@@ -0,0 +1,23 @@
+<!-- Distribution reference: maintained in .codex/skills/ipollowork-template-generation/references/; checked against the source by plugin-package-manifest.test.ts. -->
+
+# Article Rules
+
+Use for `article`: editorial pages, long-form reading and WeChat articles. Read `design.md` and shared guidelines first.
+
+## Reading and editorial structure
+
+- Preserve facts, meaning and the requested voice. Derive title, introduction, sections, quotes and conclusion from content rather than a fixed template structure.
+- Prioritize sustained reading: suitable line measure, paragraph rhythm and heading relationships. Check Chinese punctuation, mixed scripts and meaningful line breaks in the final font.
+- Avoid turning every paragraph into a decorative card or slide. Use lists, emphasis and pull quotes to clarify; do not duplicate passages merely to fill slots.
+- Keep captions, credits, links and sources associated with their passage/image. Never invent bylines, publication dates or attribution.
+
+## Assets and destination
+
+- Apply shared media rules to useful cover, setting, subject and supporting illustrations. Atmosphere is a valid purpose; there is no image quota.
+- Preserve fixed brand header/footer images and nodes marked `data-ipw-fixed="true"`. Targeted text editing does not authorize changing locked elements.
+- Distinguish browser articles from publishing-platform content. Use supported styles, links and interactions for the destination; browser preview does not establish WeChat paste/publishing fidelity.
+- For actual email delivery, also read `design-other.md`'s email boundary. An article preview is not email-client verification.
+
+## Acceptance
+
+Read the full article in order and inspect its beginning, middle and ending at narrow and wide widths. Check loading/crops, captions, long links, spacing and CTA destinations. Verify requested transfer/export where available; otherwise retain the editable file and identify the unverified destination. Never claim publication without performing the authorized action.

.agents/skills/ipollowork-design-studio/references/design-cards.md

@@ -0,0 +1,23 @@
+<!-- Distribution reference: maintained in .codex/skills/ipollowork-template-generation/references/; checked against the source by plugin-package-manifest.test.ts. -->
+
+# Card Series Rules
+
+Use for `cards`: social carousels and shareable information card series. Read `design.md` and shared guidelines first.
+
+## Sequence and capacity
+
+- Content determines card count unless explicitly constrained. Give each card a clear role and maintain opening, progression and conclusion without forcing separate cards for each.
+- Preserve requested channel dimensions and consistent series geometry. Do not convert cards into PPT or impose long-page scrolling on export canvases.
+- Reuse typography, margins, attribution and numbering. Vary structure for different content relationships, not simply for decoration.
+- Retain sufficient context when cards are shared alone. Keep values, units, sources and qualifications together; do not split claims from conditions to fit.
+- Recompose or split dense content within user constraints rather than shrinking text. Keep content editable where supported.
+
+## Assets and behavior
+
+- Apply shared media rules across the series. Reuse a coherent visual family and check each crop; avoid redundant generation for repeated subjects.
+- Do not bake final copy, figures or real logos into generated illustrations when separate editable objects are required.
+- If interactive carousel behavior is requested, test next/previous, focus and touch. Static card exports do not need invented navigation or hover effects.
+
+## Acceptance
+
+Inspect every card and the series in order at final size and typical mobile reading scale. Check blank/duplicate cards, lost endings, numbering, safe areas and visual consistency. Verify requested export count, dimensions and order; report untested export behavior separately.

.agents/skills/ipollowork-design-studio/references/design-other.md

@@ -0,0 +1,22 @@
+<!-- Distribution reference: maintained in .codex/skills/ipollowork-template-generation/references/; checked against the source by plugin-package-manifest.test.ts. -->
+
+# Other Design Rules
+
+Use for `other` when no existing category fits the active artifact. Read `design.md` and shared guidelines first. Do not silently change an existing manifest to fit the routing table.
+
+## Establish the contract
+
+- Infer purpose, audience, canvas/viewport, editable content and format from the request/current files. Ask only about missing choices that materially change delivery.
+- Record constraints briefly in the task. Do not invent a new category, runtime, app scaffold or specification file.
+- Borrow relevant checks from the nearest type: site responsiveness, poster geometry, report evidence or article readability. Do not import unrelated navigation, pagination or exports.
+- Apply shared layout/media rules. Without a dedicated catalog, reuse local patterns or create scoped structures with the existing theme.
+
+## Special delivery boundaries
+
+- Email: distinguish web mockups from actual email HTML. Establish target clients and a supported export/transfer path. Use compatible structure/styles, non-scripted actions and supported asset delivery. Check narrow layouts, image blocking, fallback text and links. Claim compatibility only for clients actually inspected.
+- Image-led work: use media Skills for raster generation/editing; use Design for surrounding editable composition when needed. Raster references do not establish recoverable text layers or native vectors.
+- Unusual print/interactive formats: inspect actual runtime/export capabilities before promising them. Continue independent work and identify concrete unsupported requirements.
+
+## Acceptance
+
+Verify the inferred contract using real content and the supported preview. Check completeness, readability, geometry, assets and relevant interactions; inspect requested exports when available. Identify which type checks were used and remaining limitations. HTML validity alone cannot establish acceptance of an unknown format.

.agents/skills/ipollowork-design-studio/references/design-poster.md

@@ -0,0 +1,22 @@
+<!-- Distribution reference: maintained in .codex/skills/ipollowork-template-generation/references/; checked against the source by plugin-package-manifest.test.ts. -->
+
+# Poster and Banner Rules
+
+Use for `poster`: a single promotional canvas, poster or banner. Read `design.md` and shared guidelines first.
+
+## Canvas and hierarchy
+
+- Use requested dimensions, aspect ratio and viewing context. Preserve the existing canvas when unspecified; clarify only consequential missing dimensions. Do not inherit PPT's 16:9 requirement.
+- Establish a focal message, supporting information and action. Preserve required dates, locations, terms, logos and contact details without treating sample copy as mandatory.
+- Maintain safe margins and deliberate alignment. Fixed export canvases scale for preview without composition reflow. Responsive web banners may need a separate narrow composition; inspect each requested variant.
+- Keep text/graphics editable where supported. Do not replace all content with a generated raster poster when editability is required.
+
+## Assets and output
+
+- Follow shared media rules for campaign, subject and atmosphere imagery. Preserve real product geometry and brand marks; never fabricate sponsors or endorsements.
+- Judge resolution at final export size. Check crops, contrast, important subjects and text over images. Keep QR codes undistorted and test their destination when present.
+- Apply print bleed, color-space and production requirements only when requested and supported. Browser HTML alone does not prove press-ready output.
+
+## Acceptance
+
+Inspect the entire canvas at final dimensions and intended reading scale. Check required copy, safe margins, overlap, sharpness and brand proportions. Inspect actual exports when requested; distinguish editable HTML from verified raster/print output. Static delivery needs no decorative animation.