Myslide

MySlide - AWS-Themed Presentation Generator

Create visually compelling presentations that follow AWS design systems. Supports two themes: dark (reInvent 2023/2025) and light (L100/field enablement). Every slide should look like it was crafted by the AWS brand team.

Theme Selection

| Theme | When to Use | Reference | |-------|------------|-----------| | Dark (reInvent 2023/2025) | reInvent, Summit keynotes, tech demos | [aws-theme.md](references/aws-theme.md) | | Light (L100/Field Enablement) | L100/L200 training, customer-facing, internal workshops, sales enablement | [light-theme.md](references/light-theme.md) |

Auto-detect: If the user says "L100", "training deck", "white background", "밝은 테마", "교육 자료", "customer-facing" → use Light theme. Otherwise default to Dark theme.

Quick Start

1. Choose theme: Dark (default) or Light — read the corresponding theme reference
2. Read [references/aws-theme.md](references/aws-theme.md) for dark theme OR [references/light-theme.md](references/light-theme.md) for light theme
3. Read [references/slide-patterns.md](references/slide-patterns.md) for layout templates
4. Read [references/pptxgenjs.md](references/pptxgenjs.md) for PptxGenJS creation guide
5. Read [references/editing.md](references/editing.md) for editing existing PPTX files
6. Read [references/animations.md](references/animations.md) for animation primitives
7. Use scripts/create_aws_slide.py to generate background/SVG assets
8. Official AWS service icons are in icons/ (248 icons extracted from AWS Architecture Icon Deck)

All references and scripts are self-contained within this skill directory. No external skill dependencies required.

Cross-Skill Integration (Design Enhancement)

For richer visual output, leverage these companion skills when available:

• svg-diagram: Generate pixel-perfect SVG diagrams, architecture visuals, and flowcharts

with anti-overlap rules. Use for any slide needing diagrams beyond basic arrow connections.

Default Presenter

When generating title/thank-you slides, ask the user for their presenter info (name, title, company, contact) or use sensible placeholders. Do not hardcode personal details.

Workflow

A. Creating a New Presentation

1. Gather requirements: Ask the user for topic, key messages, and target audience
2. Write a design spec (when applicable — see gate below): Produce a markdown

spec that lists every slide's layout, key message, and visual intent. Save to design-specs/.md. See [references/design-spec-template.md](references/design-spec-template.md) for the table format and approval flow.

Spec gate — when to require a spec before any PPTX work:

| Scope | Spec? | HTML preview? | |-------|-------|---------------| | 1-2 slides, single edit | No | No | | 3-7 slide deck | Yes (markdown only) | Optional | | 8+ slide deck | Yes | Yes | | User says "design first" / "디자인 먼저" / "plan first" | Always | Always |

The reason: structural rework (wrong slide order, monotonous layout, wrong theme) is the most expensive kind to fix once PptxGenJS code exists. A spec catches it in seconds. For a quick one-pager the gate adds friction without the savings, so skip it.

Approval is mandatory for decks where the gate applies. After writing the spec (and rendering the preview if applicable), wait for the user to say "go" / "승인" / "OK" / "진행" before moving to step 3. If they ask for changes, edit the spec, re-render, ask again — don't start building from a partially-approved spec.

HTML preview (8+ slides): ``bash python3 scripts/render_design_preview.py design-specs/.md # Opens in browser: theme palette chips + per-slide wireframe thumbnails. # Variety warnings (3-streak layouts, no-diagram decks) appear at top. ``

1. Generate background images: Run the gradient background generator script
2. Create slides: Use PptxGenJS (Node.js) with the AWS theme constants
3. Add SVG visuals: Generate SVG diagrams for architecture/flow slides and embed as images
4. Apply animations: Design contextual animations and apply via apply_animations.py
5. QA (two-phase): QA uses two complementary layers — programmatic validation

catches what rendered images hide (out-of-bounds shapes, font violations), then visual inspection catches what code cannot judge (aesthetics, readability).

Phase 1 — Programmatic QA (fast, deterministic, run in main agent): ``bash python3 scripts/qa_validate.py output.pptx `` If critical issues are found (exit code 1), fix them before proceeding to Phase 2.

Phase 2 — Visual QA (kiro preferred, subagent fallback): Delegates image-heavy inspection to a separate context to protect the main context window. Prefer kiro CLI (Opus 4.6) for higher quality analysis with severity classification. If kiro is not available, fall back to a subagent (Sonnet 4.6+).

# Step 1: Generate AWS gradient backgrounds
python3 scripts/create_aws_slide.py backgrounds --output-dir /tmp/myslide-assets/

# Step 2: Run the PptxGenJS creation script (generated per presentation)
node create_presentation.js

# Step 3: Apply animations (design JSON spec per presentation context)
python3 scripts/apply_animations.py output.pptx animations.json -o animated.pptx

# Step 4: Programmatic QA — catches structural issues renderers hide
python3 scripts/qa_validate.py output.pptx

# Step 5: Visual QA — prefer kiro (Opus 4.6), fall back to subagent (see below)

B. Editing an Existing Slide

When the user says "change slide 3" or "update the title slide":

1. Identify which slide(s) to modify
2. Read the current slide content (markitdown + image inspection)
3. Apply targeted changes (text, colors, layout, or visual elements)
4. Re-render and verify only the affected slides

B.1 Overlay on a File You Didn't Generate

If the customer (or a teammate) has drawn a slide in PowerPoint and you need to ADD a few elements to it without redrawing everything, use python-pptx overlay rather than regenerating from scratch. See [references/pptx-overlay.md](references/pptx-overlay.md) for the full workflow, including the add_connector endpoint-vs-width trap that is the most common cause of diagonal arrows piercing the slide title. That reference also has ready-to-copy helper functions for dashed lines, arrowheads, transparent container boxes, and zero-margin text labels.

Typical overlay use cases:

• Adding a new external system group (e.g., MCP bridge to on-premises systems)

to an existing architecture slide

• Inserting a callout or annotation on a partner-provided deck
• Fixing one mispositioned label without touching anything else

For the MCP-specific styling (color, dash pattern, label convention), also read references/mcp-external-integration.md in the aws-diagram skill. Even when overlaying on an existing file, the visual conventions should match the from-scratch aws-diagram output so diagrams across the deck look consistent.

C. Sub-Agent Strategy for Large Decks (8+ slides)

For presentations with many slides, use parallel sub-agents to maximize throughput. Each sub-agent handles an independent group of slides.

Parallelization pattern:

• Agent 1: Title + Section Header slides (structural)
• Agent 2: Content slides (odd-numbered)
• Agent 3: Content slides (even-numbered)
• Agent 4: SVG diagram generation for all visual slides

# Sub-agent prompt template:
Generate slides [N] through [M] for the AWS presentation.
- Use the AWS theme from references/aws-theme.md
- Background images are at: /tmp/myslide-assets/
- Save individual slide JS snippets to: /tmp/myslide-parts/slide-{N}.js
- Follow the layout pattern specified for each slide type.

After all sub-agents complete, combine the JS snippets into one PptxGenJS script and execute.

Visual Diversity Strategy (CRITICAL)

Never repeat the same visual pattern more than twice in a deck. Slides that are all "dark box + bullet text" create visual fatigue. Use a mix of these patterns:

Hybrid Approach: SVG Visuals + Native PPTX Text

The most effective method combines SVG diagrams (for gradient shapes, glow effects, icons) with native PPTX text (for editability). The workflow:

1. Generate SVG with visuals only (shapes, gradients, glow, icons — NO text)
2. Convert to transparent PNG (remove background ` fill, set to fill="none"`)
3. Embed PNG as slide background image at the content area position
4. Overlay native PPTX text using slide.addText() positioned to match SVG element locations

// Step 1: SVG visual as background (no text, transparent bg)
slide.addImage({ data: noTextPngBase64, x: 0.15, y: 1.2, w: 13.0, h: 5.4 });

// Step 2: Native PPTX text on top (editable in PowerPoint)
slide.addText('Title', { x: 5.0, y: 3.0, w: 3.5, h: 0.5, fontSize: 24, bold: true, ... });

Benefits:

• User can edit text directly in PowerPoint
• Gradient/glow effects preserved from SVG
• Transparent PNG works on any slide background color
• Text is searchable and accessible

SVG Infographic Patterns (use svg-diagram skill)

Generate these via svg-diagram skill with transparent backgrounds:

| Pattern | When to Use | Example Slides | |---------|------------|----------------| | Hub-Spoke | Central concept + related items | "What is X?" with Pain→Hub→Solution | | Radial 5-node | 5 features/capabilities around a center | "Why X?" feature highlights | | Horizontal Icon Strip | Sequential or parallel items | "5 Advantages" with icon+label | | Cross Quadrant | 2x2 categorization | "4 Pain Points" with icons per quadrant | | Donut Chart | Market share, proportions | Statistics with percentage breakdown | | Timeline | Evolution, roadmap | "4 Stages of AI Coding" | | Architecture | System/data flow | "LLM Gateway Architecture" | | Process Flow | Step-by-step | "3-Step Onboarding" |

Transparent SVG Background Rule

All SVG infographics MUST have transparent backgrounds so they work on any template.

When generating SVGs, ensure the first ` (background) has fill="none"`:

When stripping text from existing SVGs for hybrid approach:

svg = svg.replace(/]*>[^/g, '');  // Remove all text elements

Gradient Shapes in PPTX

PptxGenJS doesn't support native gradient fills. Use pre-rendered gradient PNG images:

// Pre-generate gradient card backgrounds
async function createGradCard(w, h, c1, c2) {
  const svg = ``;
  return sharp(Buffer.from(svg)).png().toBuffer();
}
// Embed as image, then overlay transparent ROUNDED_RECTANGLE for border
slide.addImage({ data: gradPng, x, y, w, h });
slide.addShape(pres.shapes.ROUNDED_RECTANGLE, { x, y, w, h, fill: { type: 'none' }, line: { color, width } });

Build-Then-QA Workflow (MANDATORY)

Every batch of slide changes MUST be followed by visual QA before reporting completion.

1. Edit slide code (JS files)
2. Regenerate PPTX: node create_presentation.js
3. Convert to images: soffice → PDF → pdftoppm (target slides only)
4. Launch QA subagent (background): check alignment, readability, overlap
5. If QA finds issues → fix coordinates → regenerate → re-QA
6. Report completion only after QA PASS

For hybrid slides (SVG image + native text): QA must specifically check that PPTX native text aligns precisely with SVG visual elements (circles, boxes, etc). Coordinate misalignment is the #1 issue — text must be centered inside its target shape.

Fix workflow for misaligned text:

1. Open the user-modified PPTX (if available) with python-pptx
2. Extract actual coordinates: shape.left / 914400 (EMU to inches)
3. Update JS code with corrected coordinates
4. Regenerate and re-verify

Hybrid Slide Alignment Lessons (from user corrections)

These rules come from analyzing user manual corrections on hybrid slides. Apply these BEFORE generating to minimize manual fixes needed:

1. SVG Image Vertical Offset SVG infographic images should start below the title with extra margin:

• Title ends at ~y=1.0. Image should start at y=1.5~1.6, not y=1.2
• This gives breathing room and prevents cramped feeling

2. Radial/Spoke Layout Text Placement For radial (hub + spoke) diagrams:

• Top spoke: text goes ABOVE the icon circle (y = icon_top - 0.6)
• Left spokes: text goes LEFT of icon (x = iconleft - textwidth - 0.1)
• Right spokes: text goes RIGHT of icon (x = icon_right + 0.1)
• Bottom spokes: text goes BELOW icon (y = icon_bottom + 0.1)
• Allow negative x values (e.g. x=-0.15) for left-edge spokes — PPTX clips gracefully

3. Horizontal Icon Strip Text Y-Position For 5-column horizontal layouts (icon above, text below):

• Icon occupies y=1.5~3.5 area
• Title text starts at y=3.83 (not 4.0) — tighter to icon bottom
• Korean subtitle at y=4.23, description at y=4.58
• Column spacing: calculate exact x from SVG icon centers, not evenly dividing

4. Quadrant Layout Text Positioning For cross-quadrant (2x2) layouts:

• Text x must be at least 0.15" right of icon right edge to prevent overlap
• User corrected: Q1/Q3 left columns x=2.67, Q2/Q4 right columns x=9.12~9.18
• Start y slightly below quadrant top: top row y=1.99, bottom row y=4.56~4.6

5. General SVG-Text Alignment Rule Calculate PPTX text positions FROM the SVG source coordinates:

pptx_x = (svg_element_cx / svg_viewBox_width) * slide_width
pptx_y = (svg_element_cy / svg_viewBox_height) * (image_h) + image_y_offset

Then fine-tune: add 0.1~0.2" margin away from icon edges.

QA Delegation Rules

Always delegate QA to subagents or kiro to protect the main context window:

• Visual QA (image-heavy) → run_in_background: true subagent or kiro skill
• Content fact-checking → dedicated subagent with reference MD files
• Alignment QA for hybrid slides → subagent with specific coordinate check instructions
• Never read slide images directly in the main agent context
• Main agent only receives QA text summary and applies fixes

Narrative Flow Patterns (Slide Ordering)

These patterns come from analyzing user reordering of customer case study slides. Plan slide order BEFORE generating based on the narrative pattern that fits.

Case Studies Pattern: "Specific → General" (Preferred)

When presenting customer case studies followed by a summary:

[Case 1] → [Case 2] → [Case 3] → [Section Header: "N 사례"] → [Summary Table]

Why this works:

• Audience sees concrete examples first (easier to grasp)
• Section header acts as a "conclusion marker" reinforcing the pattern
• Summary table at end provides reference/recap (not an introduction)

Avoid this order (common mistake):

[Section Header] → [Summary Table] → [Case 1] → [Case 2] → [Case 3]

This creates a "abstract first, concrete later" flow which feels academic and forces the audience to remember the table while watching individual cases.

Section Header Placement

Two valid placements:

1. Opening — "Here's what we'll cover" (introduces the section)
2. Closing/Bridging — "This is what we just saw" (wraps up the section, bridges to next)

The closing/bridging placement is especially effective when:

• Cases have been shown individually first
• The section serves as a summary or pivot point
• You want the audience to mentally organize what they just saw

Strength-of-Recommendation Language

User corrections consistently favor conditional recommendations over absolute ones, especially in customer-facing decks:

| Too Strong (Avoid) | Preferred (Conditional) | |--------------------|-------------------------| | "Amazon Bedrock 우선 검토 권장" | "엔터프라이즈 거버넌스 상이라면 → Amazon Bedrock 우선 검토 권장" | | "X is the best choice" | "If your requirement is Y, X is the best choice" | | "Always use Z" | "For scenarios requiring Z, use Z" |

Frame recommendations with the conditi

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: jesamkim
• Source: jesamkim/oh-my-skills
• License: MIT

Install and usage instructions live in the source repository linked above.