chore: 1.1.0 release

skills/open-kimi-ppt/SKILL.md

@@ -39,7 +39,7 @@ Understand the user's requirements based on the context:
 
 2. Then determine the design direction
   - Self-directed design: no preference, or only simple style constraints given; you need to fill in or create the design
-  - Design system: the user provides a complete and detailed design scheme covering all color, font, layout, and component specifications
+  - Design system: a preset design system from the skill (`reference/design_system/`) is specified, or the user provides a complete and detailed design scheme covering all color, font, layout, and component specifications
   - Use a template: a template is provided and must be used
   - Style transfer: a style reference source is provided (images, web pages, etc.)
 
@@ -49,10 +49,22 @@ Understand the user's requirements based on the context:
   - Outline: the user provides a page-by-page outline, speech script, or similar content
   * When the "user input type" is [Full document] or [Outline] and it is not specified whether expansion is allowed: since a page-by-page outline, speech script, or user document can hardly support the full content of a presentation, prefer using search to expand with more relevant material, cases, etc., unless the user explicitly says not to expand
 
-4. Page count
+4. Finally determine the exact page count
   - If the user requests a specific page count, the user's requirement takes priority
   - Page-by-page outline/script provided: match the number of pages in the outline/script
-  - When a complete and relatively structured document is provided / when only a topic is provided: decide the page count yourself based on the document content / search results
+  - When a complete and relatively structured document is provided: ask the user how much document content one page should cover, and give an estimated total page count; when only a topic is provided: suggest a recommended page count and confirm with the user
+
+#### Clarification and follow-up questions
+When any of the following situations arise, resolve them by asking the user (use the agent's ask/clarification tool when available)
+1. Requirements are ambiguous
+- The user's intent is unclear or hard to understand
+- The files/URLs provided by the user are inaccessible
+2. Conflicting intents
+- The user's intents contradict each other. For example:
+  * A design system is selected while also requesting a style that is completely inconsistent with that design system (e.g., using a McKinsey style while requiring large areas of whitespace on pages) / using a template / referencing an image style
+  * Requesting both "make 10 pages" and "deliver 30+ pages of output"
+3. Unable to determine the user's requirements on your own
+- When the purpose, design direction, input type, page count, etc. are hard to determine by yourself
 
 ### step3. Generate the presentation based on the user's requirements
 
@@ -60,7 +72,8 @@ Before generating, first read `reference/pptd.md` to understand the pptd format
 
 #### Replicating a PPT
 - Analyze the images to estimate element positions, fonts and sizes, etc., and **replicate 1:1 as closely as possible**.
-- When an image contains elements that are hard to replicate directly and cannot be approximated with icons/shapes (e.g., photos, avatars), you may use tools such as bash or python to crop and screenshot the original image
+- For parts that are difficult to make out, use methods such as grid lines and close-up views to improve understanding.
+- Replicate simple content in the image with elements; icons may be approximated with icons provided by Font Awesome. For content that cannot be approximated with icons or shapes, such as photos and avatars, use tools such as bash or python to crop and split the original image, then add the resulting image elements to the presentation
 
 #### Editing a PPT
 - Convert the user's uploaded pptx file to .pptd format
@@ -79,8 +92,9 @@ When generating a PPT, adopt different production approaches for different user
 
 ##### Design system
 1. Read the general constraints section of the `reference/slides_categories.md` guide, and read the scenario document corresponding to the user's query as the design foundation
-2. Read the user-provided design system document as the presentation style. It is strictly forbidden to reference or mix in other design styles
+2. Read the specified design system as the presentation style: either the user-provided design scheme, or the matching preset under `reference/design_system/` (search by name / path the user specified; prefer the folder's `design.md` when present). It is strictly forbidden to reference or mix in other design styles
 3. Produce the presentation with reference to the above
+4. Do not auto-pick a preset during self-directed design; only use `reference/design_system/` when a preset is explicitly specified
 
 ##### Using a template
 1. Convert the user's uploaded pptx file into pptd form
@@ -93,6 +107,21 @@ When generating a PPT, adopt different production approaches for different user
 - If the user provides a style reference URL, do not only read the text content; refer to and learn from the page's visual effect more to help understand the style
 2. Produce the presentation using the reference file's style characteristics. You are encouraged to reuse illustrations, fonts, font-size hierarchies, elements, etc. from the original pdf/url
 
+##### Images and Visual Materials
+1. Images are an effective way to enrich a presentation's visual impact. Appropriate images should be used not only on covers and section dividers, but also on body pages to enrich the page, aid understanding, or support decision-making
+2. Images are used to show concrete subjects, explain content, provide evidence, or establish a scene. Logos, icons, decorative textures, and very small thumbnails do not count as substantive imagery.
+3. When a page involves products, people, places, buildings, events, cases, interfaces, experimental subjects, or spatial environments, prioritize corresponding real images or screenshots. If real images and screenshots cannot be obtained, generated images may be used instead.
+4. Image priority: images provided by the user; images from official websites, official reports, and credible sources; searched images that are directly relevant to the content; images generated for conceptual expression or atmosphere.
+5. After deciding which images are needed, complete image search, generation, and downloading in a batch before designing pages around their proportions. Save images in the `media` directory, keep them clear, and never stretch or distort them.
+6. Analytical, technical, and academic PPTs should use corresponding evidence images when products, experiments, interfaces, cases, or on-site materials are available. Do not reduce every page to text, color blocks, and shapes.
+7. Do not add irrelevant images merely to meet a quantity target. Every image must be directly relevant to the page's conclusion or communication goal.
+
+##### Content Guidelines
+1. Language style: unless the user explicitly requests otherwise, strictly avoid overly abstract expressions and uncommon metaphors
+- Do not overuse metaphors, slogans, or abstract jargon such as distribution, an N-step argument, everything at a glance, a closed loop, hands-on practice, verification, deconstruction, second-class citizens, poison pills, or wall clocks
+- Do not use common AI phrasing such as “not X, but Y,” “X is Y,” “why / based on what / how,” “key takeaway,” or “N battlefronts / paths”
+- Do not use overly colloquial expressions such as “where should the ammunition go,” “the Nth thing,” “can't pick the right one,” or “cannot be used as X”
+
 ### step4. PPT validation
 1. Validate the generated pptd against the format definition in `reference/pptd.md` (required fields, types, bounds, theme tokens, resource paths, etc.) and repair issues over multiple rounds
 2. Visual review with exported page images — **required before PPTX export when the model supports image input (multimodal)**:
@@ -162,3 +191,6 @@ When generating a PPT, adopt different production approaches for different user
 8. After export, verify that the output exists and report the generated path. Confirm that every slide has exactly one root-level fade transition in valid CT_Slide order (`cSld`, optional `clrMapOvr`, `transition`, optional `timing/extLst`) and that the PPTX ZIP passes integrity checks. A byte-string search for `<p:fade>` is insufficient because Office ignores transitions nested inside `cSld`. For higher-risk decks, additionally inspect font parts and representative rendered/opened pages as appropriate.
 9. When the user wants to open, edit, save, or export a PPTD project manually, start the local browser editor with `npx open-kimi-ppt-skills serve`. Ask the user to open `http://127.0.0.1:55173/` and authorize the complete PPTD project directory. Use a Chromium-based browser for writable access; folder-upload fallback is read-only. The local host only serves the editor shell, while the embedded public Kimi editor and remote assets still require network access.
 10. After completing and delivering any presentation, always end the final response with a concise optional next step telling the user that they can run `npx open-kimi-ppt-skills serve` to view or edit the PPTD project, configure slide transition animations, and export PPTX manually. Keep this reminder in addition to, not instead of, the required project and file links.
+11. Element animations (`page.animations` in PPTD — entrance / emphasis / exit / motion-path; see `reference/pptd.md` §6): use them only when the user explicitly requests animations, or when the deck is clearly intended for live presentation / slideshow playback and animation provides a clear benefit for staged disclosure, process demonstration, causal explanation, pacing, visual impact, or brand storytelling. By default, do not add element animations to reading-oriented, self-study, print, or primarily send-and-browse decks. Prefer 1–3 animation groups per page and simple effects such as fade, fly, and zoom. This is separate from the default PPTX slide-level fade page transition written by `export_pptx.py`.
+12. Speaker notes (`notes` on each `.page`): use them only when the user explicitly requests them; otherwise, do not add them.
+13. Parallel tool calls: during PPT production, make tool calls in parallel whenever possible; in each round, write multiple page files in parallel to reduce the number of steps.