ppt-polish

## Permissions This skill requires broad tool access for its automation workflows. The `.claude/settings.json` has been pre-configured with the minimum necessary permissions. A SessionStart hook ensures the environment is properly initialized. # PPT Polish Optimize diagram-heavy PPT pages so they become clearer, more editable, and more presentation-ready. Prefer rebuilding structure over cosmetic tweaks when the original slide is messy. The goal is not just “make it prettier”, but “make it readable, editable, and reusable”. ## Core workflow 1. Identify the source form - Existing editable PPT/PPTX slide - Screenshot/image of a diagram - Mixed case: image already placed inside a PPT 2. Classify the diagram - Flowchart / process map - System topology / architecture diagram - Org / hierarchy diagram - Dense infographic-like technical diagram 3. Preserve the information structure - Extract layers, groups, nodes, and major relationships first - Decide what is primary path vs supporting path - Do not start from colors or decoration 4. Rebuild or polish in PowerPoint - If the slide is already editable and structurally decent, adjust layout/style directly - If the slide is messy or image-based, reconstruct shapes/text/connectors instead of polishing the pasted image 5. Final quality pass - Improve readability for presentation - Ensure all important items remain editable - Reduce visual noise and accidental line crossings ## Decision rules ### When polishing an existing PPT Prefer direct editing when: - Text is already editable - Shapes are mostly separable - Layout is salvageable Prefer rebuilding on a new slide when: - The current slide is essentially a screenshot - Elements are badly misaligned or inconsistent - Connectors are too chaotic to repair efficiently - The user wants a more premium/client-facing result ### When starting from an image Use the image only as reference. Do not treat “insert image into PPT” as completion. A valid result should have editable: - titles - containers - nodes - text - connectors ## Layout heuristics ### Flowcharts - Keep a clear main direction: left→right or top→bottom - Put decision nodes at branch points - Keep similar node types same size and style - Reduce crossing lines, even if that means slightly changing spacing ### Topology / architecture diagrams - Group by layer or domain first - Put gateways / hubs / central schedulers near the center - Put external actors at the edge - Put data/storage below or on a dedicated side band - Put ops/monitoring in a side rail or bottom band ### Dense technical diagrams - Keep the density if that is part of the original style - Still enforce consistent spacing, headers, and color logic - Use container regions so the eye can parse clusters quickly ## Styling heuristics - Use 1 visual language per slide, not several mixed styles - Keep a consistent color family by layer/category - Use emphasis only for core nodes and main paths - Use lighter visual weight for supporting lines and less important modules - Prefer subtle rounded rectangles and clean borders over excessive effects - Avoid overusing gradients, shadows, and icons unless they help meaningfully ## Read bundled references when needed - Read `references/image-to-ppt-flowchart-sop.md` for image→editable-flowchart reconstruction workflow - Read `references/ppt-topology-from-image.md` for topology-specific decomposition and layer mapping ## Expected outputs Depending on the request, produce one or more of: - optimized `.pptx` file - rebuilt single-slide diagram page - alternate visual versions (e.g. dark, clean, infographic) - structure draft in Markdown / Mermaid before rebuilding ## Quality checklist Before finishing, verify: - The main information structure is preserved - Important text is editable - Shapes are editable rather than flattened into an image - Layers/groups are obvious at a glance - Alignment and spacing are consistent - Connector hierarchy is readable - The page is suitable for presentation, not just archival ## Notes When multiple output versions exist, keep filenames explicit, such as: - `*-refined.pptx` - `*-infographic.pptx` - `*-dark.pptx` - `*-polished.pptx` Prefer descriptive naming over generic names like `final-final2.pptx`.