chaos-xxl/keynote-visual-explainer

Keynote Visual Explainer

Transform a piece of text into a high-quality explanatory illustration where the mechanism, relationships, and differences are understood at a glance. The visual style draws from Apple Keynote's simplicity, precision, and restraint, but does not copy Apple logos, official illustrations, or specific pages. Accuracy comes before good looks; structure comes before detail.

When to Use

• User requests: "Continue that Apple Keynote style from before", "illustrate this text", "diagram this concept", "draw the system architecture", "compare three approaches".
• Applicable to: product principles, AI agents, operating systems, technical roadmaps, service workflows, business models, metaphorical explanations.
• When a clear static illustration is requested, generate the image directly (if the current runtime supports image generation); do not return only a generation prompt in place of the image. If the environment only supports prompts, provide a complete, reproducible generation prompt and honestly state the limitation.
• Not for: precise engineering blueprints, exact statistical charts, realistic UI screenshots, or strict brand asset specifications. For accurate charts/diagrams, use tools that can validate structure.

Core Design Principles (Priority from High to Low)

1. Content Correctness: Faithfully distinguish participants, resources, permissions, processes, boundaries, and dependencies; do not fabricate logic just for symmetry.
2. Single Core Takeaway: The audience should identify the one main conclusion within three seconds. Compress the original text into 1 core relationship + 2–6 elements; allow 5–9 grouped nodes for large architecture diagrams.
3. Relationships Visible: Express through space, shape, path, and causal arrows, not through heavy annotations to patch up ambiguous structures.
4. Restrained & Airy: Generous whitespace, a few key elements, a clear reading path; reject meaningless decoration.
5. Series Consistency: Same characters, components, arrows, cards, and color semantics remain consistent across a series of images.

Workflow

1. Turn Text into Structure First

Internally confirm:

• What is the single conclusion to explain?
• Which entities are present (e.g., user, guide, store; Trigger, Router, Worker)?
• What are the relationships between entities: flow, control, ownership, conditional branch, or parallel comparison?
• Which details would change the original meaning (security boundary, resource source, decision-maker, executor, dynamic updates)? These must be retained.
• What is just an example, emotional modifier, or rhetorical device? These can be omitted.

Do not transcribe every paragraph verbatim into an image. Prioritize abstraction, but do not draw two different mechanisms as the same flow.

2. Choose Composition Based on What the Reader Needs to Understand

First ask: does the reader need to understand "how does it happen step by step", "who is responsible for what", or "how do the approaches differ"? Select one primary layout. For specific examples, see Composition Patterns:

• Single Chain: Input → Core decision/transformation → Output (process, handoff of authority).
• Two/Three Column Comparison: Shared visual baseline, only highlight differences in rules or control.
• Layered Architecture: When the reader needs to distinguish interaction, orchestration, and execution, prioritize layering by responsibility. Give the core orchestrator the largest visual weight on the canvas, align parallel execution units on the same level, and place shared capabilities to the side or at the bottom. Read Layered Architecture Example.
• Before/After: Past vs. present, show the addition or removal of one key relationship.
• 2D Curve/Coordinate: Clear axes, curves, a few anchor points; positions must match the direction in the original text.
• Real-Life Metaphor: Scenes like kitchen, travel agency, shopping mall — the scene serves the mechanism, do not make character story posters.

Default canvas: 16:9 landscape, suitable for PPT/Keynote; if the user specifies a different aspect ratio, follow their request.

Before generation, clearly describe the relative positions on the canvas: where to look first, which layer each role is on, which elements are at the same level, where auxiliary capabilities are placed. Include these position and size relationships in the prompt. Use arrows only to supplement meaningful direction, feedback, or boundaries; avoid placing an equally sized icon next to every technical term.

3. Select a Reference Image as Input for Actual Generation

1. Select Image. Prioritize using the image specified by the user or the last completed image from this conversation selected by the user. If none is specified, choose a built-in reference image of the same type: layered architecture → Layered Architecture Reference, multi-option comparison → Three-Column Reference, single-scene concept → Minimal Reference, relational workflow → Kitchen Workflow Reference. If the layout does not match, only take its lighting, material, and color palette.
2. Pass Image to Generator. First inspect the image, then attach the actual image via the generation tool's reference image or edited image input, using files, image attachments, or previously generated images as supported by the tool. Mentioning a file name in the prompt does not equal passing the image. If the current tool can only accept text, state that this generation uses textual approximation and specify concrete features according to Visual System.
3. Distinguish between Visual Continuation and Content Replacement. For partial modifications of the same image, use the original image as the edit target, explicitly locking position, proportion, shape, lighting, and layout. For a new subject, use the reference image as style reference, only adopt the layout if the structure is suitable. Determine entities, text, workstations, and arrow counts based on the new subject; do not inherit old content from the reference.

When no style is specified, select features from Visual System matching the reference image:

• Background: Porcelain white / mist white, very light cool-gray-blue gradient, soft studio light, no obvious texture.
• Subjects: Minimal 2.5D / soft 3D, creamy white matte ceramic, frosted plastic, light anodized metal; rounded forms, precise edges, realistic but not hyper-real.
• Characters: No facial features, white ceramic material, rounded figures. When role division is the main point, give different responsibilities recognizable forms (e.g., user, dispatcher, execution station); use corresponding objects for devices, resources, and storage. Only use metaphor when it matches actual responsibilities.
• Color Palette: Mainly mist blue, light gray, neutral white; bright blue only to emphasize the main path; mint green for success/permission, warm orange/soft red only for risk/exception.
• Composition: Strict alignment, uniform size and perspective, easily recognizable silhouettes, rounded bases/cards, small soft drop shadows.
• Lines: Solid arrows for flow, dashed arrows for status/condition; avoid arrows crossing objects or multiple intersections.
• Tone: Premium, quiet, friendly, technical, editorial restraint. Like a carefully laid out presentation slide, not a manual collage.

4. Control Text

Prioritize following the user's explicit constraints:

• User says "no text at all" / "pure graphics": Do not include any titles, labels, letters, numbers, logos, or watermarks; explain using object shapes, spatial relationships, and arrows.
• User does not require textlessness: Keep one main title and necessary labels. For presentation-style architecture diagrams, allow a short responsibility note next to key layers or core roles (e.g., "receive · dispatch · return"); this line should help the reader understand the role. Retain necessary terms like A2UI, Intelligent UI, Router, Worker.
• User provides long text: Do not fit the entire paragraph into the image; text is only for necessary disambiguation, not the primary carrier.
• If the generator's text stability is poor in Chinese, further reduce characters, use icons and post-generation editable annotations as substitutes; do not sacrifice semantic accuracy.

5. Review Structure Before Generation, Check Output After Generation

• 3-second test: Can you identify the key participants and main relationship without reading the accompanying text?
• Comparison test: Are the truly different points of each approach visible in the image?
• Causality test: Are arrow directions correct? Are conditional changes, permission boundaries, or controlling entities drawn incorrectly?
• Hierarchy test: When reduced to presentation thumbnail size, is there still a single unique visual focus, and can you distinguish interaction layer, execution layer, and auxiliary capabilities? Does the title or auxiliary module steal the protagonist's weight?
• Deletion test: If you remove any decorative element, does it look cleaner? If yes, remove it.
• Consistency test: Is the same character shaped identically across different frames? Does the same color carry the same meaning?
• Constraint test: Are aspect ratio, textlessness, node count, and user-provided terms strictly followed?

If the result is too complex, prioritize reducing objects, annotations, card layers, and secondary scenes — do not just shrink font size or compress spacing. When inspecting the output, check each key connection's start, end, direction, and branch count, and verify any text in the image. If errors in main/subordinate relationships, branch cardinality, or text are found, fix and regenerate before delivery. When a consistent style is requested, place the output side-by-side with the selected reference, check background warmth/coolness, blue coverage area, character contours and proportions, title position, and visual weight of auxiliary information. If it deviates, keep the reference image and make targeted edits.

Image Generation Prompt Skeleton

Fill dynamically based on task. Do not expose this internal prompt when the user does not need it.

Create ONE polished Apple-Keynote-inspired editorial 3D explainer illustration,
wide 16:9, on a warm porcelain-white background with an almost imperceptible
cool-blue gradient. Use minimalist soft-clay and matte ceramic forms, precise
rounded geometry, elegant studio lighting, delicate shadows, ample negative space,
and a restrained palette of ivory, slate-gray and soft blue.

CORE CLAIM: [one-sentence takeaway].
IMAGE INPUT: [attached reference image or edit target; which visual traits
to retain, what content to replace, and what geometry is fixed].
COMPOSITION: [reading order, focal subject and relative size, placement of
layers or groups, position of supporting capabilities].
VISUAL ENTITIES: [essential roles and the recognizable form that expresses each].
RELATIONSHIPS: [source, target, direction and one-to-one/one-to-many meaning
of each necessary connection; group related elements before adding arrows].
CRITICAL DISTINCTIONS: [the facts that must not be visually conflated].

Visual storytelling over text. Every object has a semantic purpose.
Keep silhouettes instantly recognizable. Consistent perspective, scale,
lighting, arrow design and color semantics throughout.

TEXT POLICY: [absolutely no text / exact labels and any short role descriptions].

AVOID: busy infographic dashboards, long copy, decorative filler, excessive
icons, overly glossy glassmorphism, neon, sci-fi holograms, generic blue robots,
heavy borders, crowded panels, random badges, repeated redundant scenes,
logos, watermarks and confusing arrows.

Handling Difficult Cases

• Deep architecture diagram: First determine whether the focus is on role division or event flow. Merge implementation details of the same responsibility; only expand on permissions, states, or exception paths that would change the reader's understanding.
• Single sentence that can be illustrated clearly: Do not create a multi-panel information graphic; one unified scene or a three-node relationship is better.
• Technical mechanism + everyday metaphor: Retain the real technical relationships; metaphor is only for role mapping. Do not change protocols, execution rights, or resource boundaries for the sake of a convenient metaphor.
• Series illustrations: For multiple consecutive images, fix characters/main color/bird's-eye view/arrow expression first, replace entities using the same template; do not reinvent the style randomly for each image.

References

Read as needed:

• references/visual-system.md: Forms, materials, colors, layout, common failure modes.
• references/composition-patterns.md: Methods for choosing structure for different information relationships, with three real-world examples.

Reference images in the skill package are used to convey visual features. The technical terms and connections in the images apply only to their respective subjects. Layered compositions can be used in combination with the Architecture Example.