Create professional AWS-themed PowerPoint presentations with two theme options:
dark (reInvent 2023/2025 with gradient backgrounds) and light (L100/field
enablement with white backgrounds and soft gradient accents). Uses AWS brand
colors, rich visual elements (SVG diagrams, architecture diagrams, icons),
and cross-skill integration (svg-diagram). Supports creating
from scratch, editing specific slides conversationally, and embedding SVG
visualizations for maximum design impact.
Trigger: "myslide", "make slides", "AWS presentation", "create pptx",
"slide deck", "AWS slides", "프레젠테이션", "슬라이드 만들어", "발표자료",
"L100", "L200", "training deck", "light theme", "밝은 테마", "교육 자료"
Instalação
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
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.
Auto-detect: If the user says "L100", "training deck", "white background", "밝은 테마",
"교육 자료", "customer-facing" → use Light theme. Otherwise default to Dark theme.
Quick Start
Choose theme: Dark (default) or Light — read the corresponding theme reference
Use scripts/create_aws_slide.py to generate background/SVG assets
Official AWS service icons are in icons/ (304 icons, including 56 Bedrock AgentCore variants)
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.
Directory Convention — All generated assets go under artifacts/ (sibling to the skill directory), never /tmp:
Gather requirements: Ask the user for topic, key messages, and target audience
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/<deck-name>.md. See 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.
Generate background images: Run the gradient background generator script
Create slides: Use PptxGenJS (Node.js) with the AWS theme constants
Add SVG visuals: Generate SVG diagrams for architecture/flow slides and embed as images
Apply animations: Design contextual animations and apply via apply_animations.py
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):
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 {workspace}/artifacts/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":
Identify which slide(s) to modify
Read the current slide content (markitdown + image inspection)
Apply targeted changes (text, colors, layout, or visual elements)
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 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: {workspace}/artifacts/myslide-assets/
- Save individual slide JS snippets to: {workspace}/artifacts/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:
Generate SVG with visuals only (shapes, gradients, glow, icons — NO text)
Convert to transparent PNG (remove background <rect> fill, set to fill="none")
Embed PNG as slide background image at the content area position
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 <rect> (background) has fill="none":
<rectwidth="1200"height="500"fill="none"/>
When stripping text from existing SVGs for hybrid approach:
svg = svg.replace(/<text[^>]*>[^<]*<\/text>/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 backgroundsasyncfunctioncreateGradCard(w, h, c1, c2) {
const svg = `<svg ...><linearGradient ...><rect fill="url(#g)"/></svg>`;
returnsharp(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.
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:
Open the user-modified PPTX (if available) with python-pptx
Extract actual coordinates: shape.left / 914400 (EMU to inches)
Update JS code with corrected coordinates
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.51.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 = icon_left - text_width - 0.1)
Right spokes: text goes RIGHT of icon (x = icon_right + 0.1)
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:
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:
Opening — "Here's what we'll cover" (introduces the section)
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 condition/qualifier FIRST so the customer
feels empowered rather than dictated to. This is especially important for
AWS customer-facing content where neutrality matters.
Slide Types
Each presentation should use a MIX of these layouts. Never repeat the same layout more than twice in a row.
Type
When to Use
Reference
Title
First slide (single speaker)
slide-patterns.md > Title Slide
Title (Two Speakers)
First slide (co-presentation)
slide-patterns.md > Two-Speaker Title
Agenda
Second slide, table of contents
slide-patterns.md > Agenda Slide
Section Header
Chapter dividers (01, 02...)
slide-patterns.md > Section Header
Content Card
Key points with icon
slide-patterns.md > Content Card
Two Column Card
Side-by-side options/concepts
slide-patterns.md > Two Column Card
Three Column
Comparisons, 3 options
slide-patterns.md > Three Column
Process Flow
User scenarios, step-by-step flows
slide-patterns.md > Process Flow
Comparison Table
Option comparisons, feature matrices
slide-patterns.md > Comparison Table
Architecture
System diagrams
slide-patterns.md > Architecture
Venn/Comparison
Overlapping concepts
slide-patterns.md > Venn Diagram
Screenshot+Text
Demo/console walkthrough
slide-patterns.md > Screenshot
Summary Grid
2x2 key takeaways
slide-patterns.md > Summary Grid
Evolution/Progression
Maturity stages, AI evolution
slide-patterns.md > Evolution
Multi-Card Grid
2x2 or 3x2 feature cards
slide-patterns.md > Multi-Card Grid
Gradient Border Cards
Light cards with colored borders on dark bg
slide-patterns.md > Gradient Border Cards
Thank You
Last slide
slide-patterns.md > Thank You
Light Theme Additional Patterns
These layouts are specific to the Light theme (L100/field enablement style).
See references/light-theme.md for full code examples.
Type
When to Use
Reference
Section Divider (Light)
Chapter breaks with gradient blob accents
light-theme.md > Section Divider
Data + Citation
Market data with bar charts + source quotes
light-theme.md > Data + Citation
Key Points Grid
2x3/2x4 grid with purple ALL-CAPS labels
light-theme.md > Key Points Grid
Feature Badges + Screenshot
Tan pill badges + product screenshot
light-theme.md > Feature List + Screenshot
Full-Color Background
Bold single-color slide (max 1 per deck)
light-theme.md > Full-Color Background Slide
Step Guide
Purple numbered badges + screenshots
light-theme.md > Step Guide with Screenshots
Customer Case Study
Logo + Challenge/Solution/Result + pill tags
light-theme.md > Customer Case Study
Do's vs Don'ts
Green/red color-coded comparison columns
light-theme.md > Do's vs Don'ts Comparison
CTA Slide
Orange numbered badges + action items
light-theme.md > Call to Action
Dashboard Evidence
Product UI screenshot as proof point
light-theme.md > Dashboard Screenshot Slide
SVG Visual Elements
For slides that need diagrams, architecture visuals, or flowcharts, generate inline SVG and
convert to PNG for embedding. This dramatically improves visual quality over plain text slides.
When to generate SVGs:
Architecture or system flow explanations
Process/workflow diagrams
Comparison charts or feature matrices
Any slide where the content is inherently visual
SVG generation approach:
# Generate SVG with official AWS service icons, convert to PNG for embedding
python3 scripts/create_aws_slide.py svg-diagram \
--type architecture \
--elements "CloudFront,API Gateway,Lambda,Bedrock,S3" \
--output {workspace}/artifacts/myslide-assets/arch-diagram.png
Available icon names (use these as element names for automatic icon embedding):
Lambda, EC2, S3, DynamoDB, API Gateway, CloudFront, Bedrock, Bedrock AgentCore, ECS, EKS, RDS,
Aurora, VPC, ELB, Route 53, CloudWatch, IAM, Cognito, SNS, SQS, Step Functions,
EventBridge, Kinesis, SageMaker, Redshift, Athena, Glue, KMS, WAF, Shield,
Fargate, ECR, AppSync, OpenSearch, ElastiCache, Secrets Manager, ACM, and 200+ more.
See icons/ directory for the full list of available service icons.
AgentCore component-specific icons: 56 variants covering 9 AgentCore components
(logo, ai-agent, runtime, gateway, identity, code-interpreter, observability, browser-tool, memory)
across 4 color accents (teal, blue, purple, cyan) and 2 themes (light, dark).
Pattern: agentcore-{component}-{color}-{theme}.svg — e.g., agentcore-runtime-teal-light.svg.
Use these in slides when highlighting individual AgentCore services with matching color to slide theme:
Arrows must NEVER pass through another service box. This is the #1 architecture
diagram defect. Before drawing each arrow, trace the path from source to target and
verify no intermediate box lies in the way. If one does:
Route around: Use two LINE segments (L-shape or Z-shape) to go around the box
Move the blocking box to a row/column that clears the path
Connect via the intermediate box if there's a logical flow through it
Arrow segments must maintain >= 10px clearance from any icon bounding box
In hub-spoke layouts, radial arrows must not cross sibling spokes -- stagger spoke y-positions
Validation: After all elements are placed, mentally trace every arrow and confirm
it does not cross any box. See slide-patterns.md > Arrow Routing Rules for code examples.
aws-diagram Skill Integration
For complex architecture diagrams (VPC nesting, orthogonal arrows, 8+ services), use the
aws-diagram skill instead of create_aws_slide.py. It produces native PPTX architecture slides
that can be merged into myslide decks:
SVG layer order rule (applies to all SVG diagram generation):
Icons must render ABOVE arrows. Render order: background > containers > arrows > callouts > icons.
Image Generation (Optional)
When a slide needs a conceptual illustration, hero image, or visual metaphor that cannot
be expressed with SVG diagrams or AWS icons, use the sd35l skill (GA) to generate images
via Amazon Bedrock. nova2-omni is also available as an alternative (gated preview).
Requires: If used, the sd35l skill must exist under {WORKING_DIR}/skills/sd35l (or adjust the find path above).
When to Use Image Generation vs SVG Diagrams
Content Type
Use SVG/Icons
Use sd35l
AWS architecture diagrams
Yes
No
Process flows, step diagrams
Yes
No
Conceptual hero images (AI brain, cloud, etc.)
No
Yes
Abstract background visuals
No
Yes
Product/scenario illustrations
No
Yes
Screenshot placeholders
No
Yes
Data flow with service icons
Yes
No
Slide-Optimized Aspect Ratios
Use Case
Aspect Ratio
Slide Coverage
Full-slide background
16:9
Entire slide behind text
Hero image (title slide)
16:9
Right 60-70% of slide
Half-slide illustration
2:3 or 3:4
Left/right half
Card illustration
1:1
Inside a content card
Banner (wide strip)
21:9
Top or bottom strip
Integration Workflow
# 1. Generate image with sd35l (resolve under application/skills only)
SD35L_SCRIPT=$(find "${WORKING_DIR}/skills" -path "*/sd35l/scripts/generate_image.py" 2>/dev/null | head -1)
python3 "$SD35L_SCRIPT" \
--prompt "Abstract dark gradient with glowing neural network connections, deep navy and purple tones, futuristic technology atmosphere, minimal clean composition" \
--negative-prompt "text, watermarks, logos, people, bright colors, white background" \
--aspect-ratio 16:9 \
--seed 42 \
--output-dir {workspace}/artifacts/myslide-assets/
# 2. Result JSON: {"model": "...", "seed": 42, "images": ["{workspace}/artifacts/myslide-assets/sd35l_1.png"]}# 3. Embed in PptxGenJS using base64
All card-like shapes (content cards, agenda items, grid cells, tag badges, summary bars)
MUST use ROUNDED_RECTANGLE with rectRadius instead of plain RECTANGLE.
This gives a modern, polished look consistent with contemporary UI design.
Radius Guidelines
Element
rectRadius
Notes
Large cards (content, 2-col, 3-col)
0.10 - 0.12
Main content containers
Inner boxes (code blocks, option cards)
0.06 - 0.08
Nested within larger cards
Tag badges (effort/impact labels)
0.15
Pill-shaped badges
Progress bars
0.10
Pill-shaped bars
Summary/footer bars
0.08
Horizontal wide bars
Accent Styling with Rounded Corners
Do NOT overlay thin rectangular accent bars on ROUNDED_RECTANGLE shapes (they won't
align with corners). Instead, use line border property for accent colors:
Full-slide overlays (dark transparency over hero images)
Table cell backgrounds (must tile without gaps)
Decorative gradient accent bars at slide edges
Thin Accent Lines Under Titles (DO NOT USE)
Do NOT add thin orange/pink accent lines (h: 0.04) under slide titles.
This creates visual noise and looks repetitive across slides. The title text
itself is sufficient as the visual anchor. If visual separation is needed
between title and content, use whitespace (0.3"+ gap) instead of a line.
// ❌ WRONG: Thin accent line under title
slide.addShape("rect", {
x: 0.8, y: 1.05, w: 1.5, h: 0.04, fill: { color: C.orange },
});
// ✅ CORRECT: Use whitespace gap between title and content// Title at y: 0.33, content starts at y: 1.41 (natural 0.3"+ gap)
Color Discipline (CRITICAL)
Slides look more professional with fewer, well-chosen colors. Too many colors
create visual noise and distract from the message. Limit each slide to 5 core
colors maximum. A restrained palette feels intentional and polished; a rainbow
of colors feels chaotic.
The 5 Core Colors (Dark Theme)
Role
Color
HEX
When to use
Background
Deep Purple-Black
09051B
Slide background (via gradient image)
Primary Text
White
FFFFFF
All headings, body text, bullets
Emphasis
Orange
F66C02
Key terms, highlights, numbered badges
Container
Dark Navy
161E2D
Card fills, table cells, box backgrounds
Secondary
Light Slate
C8D0D8
Subtitles, descriptions, captions (readable on projectors)
The 5 Core Colors (Light Theme)
Role
Color
HEX
When to use
Background
White
FFFFFF
Slide background
Primary Text
Near Black
1A1A1A
All headings, titles
Accent
Sky Blue
4FC3F7
Table headers, bullets, links
Card Fill
Cream/Beige
F5F0EB
Card backgrounds, content areas
Body Text
Dark Gray
333333
Body text, descriptions
Light theme allows additional accents sparingly: coral (C96842) for key stats,
purple (6B46C1) for architecture labels/badges, AWS orange (FF9900) for
internal badges and CTA numbers. See light-theme.md for full palette.
Allowed Accent (sparingly)
C91F8A (Magenta) — card border lines only, max 1-2 per slide
5600C2 (Purple) — already in the gradient background, no need to add separately
Colors to AVOID in regular slides
These colors exist in the theme file for special cases but should NOT appear in
normal content slides. Using them creates a cluttered, inconsistent look:
FF28EF (Neon Pink) — only for section header numbers
ABABE3 (Lavender), FF9EA2 (Salmon Pink) — only for complex architecture diagrams
00A0C8 (Teal), 69AE35 (Green) — only when semantically meaningful (e.g., success/info)
010135, 02043B — only in multi-layer architecture diagrams
Rule of thumb: If you're about to use a 6th color, stop and ask whether one
of the 5 core colors can serve the same purpose.
Gradient Fills for Cards and Containers
PptxGenJS does not support native gradient fills on shapes. To create gradient
card backgrounds (e.g., a subtle dark-to-darker gradient inside a card), render
an SVG gradient rectangle and convert to PNG:
Use gradient fills sparingly — they add visual depth but overuse diminishes the effect.
One or two gradient cards per presentation is ideal.
Gradient Borders (for any shape)
Gradient borders work on any card — single Content Card, Multi-Card Grid,
or the Gradient Border Cards layout. The technique: render an SVG with a
gradient-filled rectangle and a smaller inner rectangle in the fill color,
creating a border effect.
See slide-patterns.md > Gradient Border Cards for the full multi-card layout pattern.
Typography Size Rules (CRITICAL)
Body text must NEVER be smaller than 15pt. This is the #1 visual quality issue.
Table cells, comparison columns, and process flow card text are NOT exceptions —
they must also be 15pt minimum. Only footer copyright and slide-number captions
may go below 15pt.
Minimum Font Size by Element
Element
Min Size (pt)
Recommended (pt)
Weight
Slide title
36
36-44
Bold/Heavy
Section number (01, 02)
36
36
Bold
Card title / Sub-header
20
20-24
Bold
Body text
15
16
Regular
Bullet items
15
15-16
Regular
Table cell text
15
15-16
Regular
Process flow card text
15
15-16
Regular
Three-column body
15
15-16
Regular
Caption / Footer / Copyright
8
8-10
Light
The only elements allowed below 15pt are:
Footer copyright text (8pt)
Slide number labels (8-10pt)
Service name labels under icons in architecture diagrams (10-12pt)
Everything else — including table cells, comparison columns, process flow
descriptions, multi-card grid body text — MUST be 15pt or higher. If content
overflows at 15pt, reduce the text content rather than shrinking the font.
Card-to-Text Balance Rule
Text should fill at least 60% of the card's vertical space. If a card has excessive
bottom whitespace (>30% empty), apply one or more of these fixes:
Increase font size (first choice) — bump body text to 16-18pt
Increase line spacing — use lineSpacingMultiple: 1.3 to 1.5
Reduce card height — shrink the card to fit the content snugly
Add vertical centering — use valign: "middle" on text boxes
// WRONG: Small text in large card = excessive whitespace
slide.addText(bodyText, {
x: 1, y: 2.5, w: 5, h: 3.5,
fontSize: 12, // TOO SMALL
});
// CORRECT: Properly sized text filling the card
slide.addText(bodyText, {
x: 1, y: 2.5, w: 5, h: 3.5,
fontSize: 16,
lineSpacingMultiple: 1.3,
valign: "top",
});
Grid/Multi-Card Slides
For 2x2 grids and 3-column layouts where space is tighter:
Card title: 18-20pt bold
Body text: 15pt minimum (never drop to 12-14pt)
Table cells: 15pt minimum (not 13-14pt — reduce column count or text instead)
Process flow card text: 15pt minimum
If content overflows, reduce text content rather than font size
Use paraSpaceAfter: 6 instead of paraSpaceAfter: 10 to reclaim space
Text Emphasis Rules
The AWS template uses specific color highlighting for emphasis:
Orange (F66C02): Primary emphasis for key terms, important concepts
Magenta (C91F8A): Secondary emphasis, links, interactive elements
White bold: Section headers within content areas
Regular white: Body text
Use rich text arrays in PptxGenJS to apply selective highlighting:
PptxGenJS doesn't natively support gradients on text or shape borders. Two workarounds
are documented in references/pptxgenjs.md:
Gradient Text (section "Gradient Text"): Render as SVG, convert to PNG via sharp,
embed as image. Good for large hero numbers like "80%".
Gradient Border (section "Gradient Border"): Post-process the generated PPTX with
python-pptx to inject OOXML gradient line XML. This is the preferred approach for shape
borders because the result is native PowerPoint and remains editable. Use apply_gradient_border()
from the reference.
Conversational Editing
The user may request changes like:
"3번 슬라이드 제목을 바꿔줘" → Read slide 3, modify title text
"아키텍처 다이어그램을 추가해줘" → Generate SVG + add new slide
"색상을 좀 더 밝게" → Adjust fill/text colors
"순서를 바꿔줘" → Reorder slides in presentation.xml
For each edit request:
Show the user what the current slide looks like (render to image)
Describe the proposed change
Apply the change
Show the result for confirmation
Animations (Contextual Design)
Animations are designed per-presentation based on content and narrative flow.
There are no fixed templates — each slide gets animations tailored to its story.
Design animations contextually after slides are created:
What appears first? (title, framing context)
What's the focal sequence? (data flow, process steps)
What's the conclusion? (output, call-to-action)
Write JSON spec describing the animation sequence per slide
Apply with script:
# List shapes to find target names/IDs
python3 scripts/apply_animations.py deck.pptx --list-shapes
# Apply animations
python3 scripts/apply_animations.py deck.pptx animations.json -o animated.pptx
Key Primitives
Category
Effects
Use Case
Entrance
appear, fade_in, fly_in, wipe, zoom_in
Revealing content step-by-step
Emphasis
pulse, spin, grow_shrink, color_pulse
Drawing attention to key element
Exit
disappear, fade_out, fly_out, zoom_out
Removing elements
Motion
motion_path (SVG path syntax)
Data flow, pipeline visualization
Property
property_change (fill_color, visibility)
State transitions
Triggers
Trigger
Behavior
onClick
New click point — presenter controls timing
withPrevious
Simultaneous with previous animation
afterPrevious
Auto-starts after previous completes
Shape Naming
PptxGenJS does NOT preserve custom name attributes. After generating the PPTX,
run --list-shapes to get actual shape names/IDs, then build the animation JSON spec
using those names.
Animation Design Principles
Less is more — animate only what serves the narrative
Consistent timing — use 500ms for standard, 300ms for fast, 800-1000ms for dramatic
Group related elements — card + text should animate together (withPrevious)
Build left-to-right — for pipelines and data flows
Fade for text, Fly for shapes — general heuristic for visual harmony
For very large or complex presentations, use the team-assemble pattern to coordinate
multiple agents working in parallel. This is more powerful than simple sub-agents because
it enables inter-agent communication, shared task tracking, and phased execution.
When to use Team-Up instead of Sub-Agents:
15+ slides with diverse content types
Presentations requiring research + design + implementation phases
When SVG diagram generation is complex and needs dedicated attention
Team Composition:
Agent
Role
Model
Responsibility
lead
Orchestrator
opus
Plan structure, assign tasks, final QA
designer
Visual Design
sonnet
Generate backgrounds, SVG diagrams, icons
writer-1
Content (slides 1-N/2)
sonnet
Write first half slide code
writer-2
Content (slides N/2+1-N)
sonnet
Write second half slide code
qa
Quality Assurance
opus/sonnet
Run qa_validate.py first, then visual QA via kiro (Opus) or subagent (Sonnet 4.6+)
Team Workflow:
1. lead: Analyze topic, create slide outline, assign tasks
2. designer + writer-1 + writer-2: Work in parallel
- designer generates all background/SVG assets
- writers create PptxGenJS code for assigned slides
3. lead: Combine all parts into single presentation script
4. qa: Run qa_validate.py, fix critical issues, then render and inspect visually
5. lead: Apply fixes, finalize
sd35l / nova2-omni image generation guide for slides
Two-Phase QA (ALWAYS run both phases):
Phase 1 — Programmatic QA (run in main agent, fast):
python3 "${WORKING_DIR}/skills/myslide/scripts/qa_validate.py" {pptx_path}
# Exit code 0 = pass, 1 = critical issues, 2 = error# Add --json for machine-readable output# Add --strict to include INFO-level findings
This catches what rendered images HIDE — shapes extending beyond slide boundaries,
connector endpoints outside the slide, text below 15pt, zero-size shapes. These
issues are invisible in rendered images because renderers clip at the slide edge.
Fix all critical issues before proceeding to Phase 2.
Visual QA is image-heavy and consumes significant context window tokens. Delegate
it to a separate context — never read slide images in the main agent.
Option A — Kiro CLI (preferred, Opus 4.6):
Kiro uses Opus 4.6 which produces more structured reports with severity
classification and deeper design system analysis. Use when kiro CLI is installed.
# First convert PPTX to images
python3 "${WORKING_DIR}/skills/myslide/scripts/office/soffice.py" --headless --convert-to pdf {pptx_path}
pdftoppm -jpeg -r 150 {pdf_path} {workspace}/artifacts/myslide-qa/slide
# Then delegate visual QA to kiro (script under application/skills/kiro if present)
KIRO_RUN=$(find "${WORKING_DIR}/skills" -path "*/kiro/scripts/run_kiro.sh" 2>/dev/null | head -1)
# If KIRO_RUN is empty, use Option B below — do not run bash with an empty path.
bash "$KIRO_RUN" --trust-all --timeout 300 \
"You are a visual QA inspector for AWS-themed PowerPoint presentations.
Read each slide image and inspect for visual quality:
$(for f in {workspace}/artifacts/myslide-qa/slide-*.jpg; do echo "- $f"; done)
Design system: dark bg (#09051B), white text, orange (#F66C02) emphasis,
dark navy (#161E2D) cards, rounded rectangles, body text min 15pt.
Phase 1 (programmatic) already verified: bounds, connectors, font sizes.
Focus on VISUAL quality only:
- Color contrast, orange highlight usage (max 2-3 per slide)
- Layout variety (no 3+ identical patterns), card whitespace (text >= 60%)
- SVG diagram clarity, icon layer order, arrow-icon clearance
- Thank You slide text overlap, generated image dark theme match
Per-slide report: PASS/FAIL with severity (경미/중간/심각) and specific issues.
Summary at end."
Option B — Subagent (fallback, Sonnet 4.6+):
Use when kiro is not available. Spawn a dedicated subagent for visual inspection.
You are a visual QA inspector for AWS-themed PowerPoint presentations.
Phase 1 (programmatic) already passed. Structural checks are verified.
Focus on VISUAL quality only.
1. Convert PPTX to images:
python3 "${WORKING_DIR}/skills/myslide/scripts/office/soffice.py" --headless --convert-to pdf {pptx_path}
pdftoppm -jpeg -r 150 {pdf_path} {output_prefix}
2. Read each slide image and check:
- Color contrast sufficient (white on dark)
- Orange highlights used sparingly (max 2-3 per slide)
- Layout variety across deck (no 3+ identical patterns in a row)
- SVG diagrams render cleanly without text overlap
- Icons render above arrows (correct layer order)
- No arrow lines crossing over service icons
- Card whitespace ratio: text fills >= 60% of card height
- Thank You slide: English/Korean text not overlapping
- Generated images match dark theme (dark with accent glows)
- Text overlay on images has sufficient contrast
3. Return a text-only report:
- Per-slide: PASS or FAIL with specific issues
- Summary: total pass/fail count and critical issues to fix
Do NOT return images. Only return text findings.