skills/infographics-generate-style/SKILL.md
Generates a new infographic style definition from reference material (images, PPTX files, URLs, or verbal descriptions). Analyzes the source, extracts design DNA, and writes a style markdown file. Use when user asks to "create a style", "new infographic style", "generate style", "add a style from", or "extract style from".
npx skillsauth add paolomoz/skills infographics-generate-styleInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Analyzes source material — PPTX files, images, URLs, or verbal descriptions — and produces a structured style definition that the LLM-based infographic generation pipeline can use.
/infographics-generate-style path/to/reference.pptx
/infographics-generate-style path/to/screenshot.png
/infographics-generate-style https://example.com/design-page
/infographics-generate-style "dark tech aesthetic with neon accents"
Before investing time in style generation, answer these 3 questions. If any answer is "no", stop and tell the user why.
Is this a visual style, not a rendering medium? Mediums (chalkboard, claymation, craft-handmade) describe how something is rendered but lack a distinctive visual vocabulary — they produce generic images "rendered as chalk." A style has specific colors, motifs, compositional rules, and recognizable visual DNA.
Can this style produce recognizably different images across 3+ layout types? Test mentally: would a bento-grid, a linear-progression, and a tree-branching layout each look distinct and good in this style? Styles that only work for one layout type (e.g., subway-map) are too narrow for the library.
Does this overlap with an existing library style? If yes, proceed only if you can write at least 5 specific Anti-Patterns differentiating the new style from the existing one. If you can't articulate the difference, the style is redundant.
Adapt your analysis approach to the source type:
PPTX files are ZIP archives containing XML. Unzip to a temp directory and extract:
ppt/theme/*.xml — look for <a:clrScheme> with dk1, lt1, dk2, lt2, accent1–6<a:majorFont> and <a:minorFont> in theme XMLppt/presentation.xml — <p:sldSz> (EMUs ÷ 914400 = inches)ppt/slideMasters/*.xml and actual slides — solid fills, gradients, image treatmentsppt/slideLayouts/*.xml — names and structure of content arrangementsppt/slides/slide*.xml — panels, dividers, image treatments, repeated shapesRead the image files directly (Claude is multimodal). Identify:
Reference images — use selectively: When the user provides images as style references, save 2-4 of the strongest/most representative ones in a references/ subdirectory next to the style file. These can be passed as --ref images during generation.
However, reference images can add noise for illustration styles. Photos from Unsplash are photographs, not illustrations — they guide palette and motifs but push the generator toward over-decoration and photorealism. Only use reference images when:
For most illustration styles (comics, graphic design, ink-based, geometric), a well-written style definition with strong Anti-Patterns produces better results than adding photographic references.
Fetch the page and analyze visual design. Extract same properties as images.
Work with the user to pin down concrete visual properties. Ask clarifying questions about colors, typography feel, layout preferences, and reference examples.
Before writing anything, read 2-3 existing style files from backend/sumi/references/data/styles/ to calibrate on the actual format, tone, and detail level used in practice. Pick styles that are adjacent to the one you're creating — they'll also serve as Anti-Pattern targets in Step 3.
This step is critical. Writing from an abstract template alone produces inconsistent structure, mismatched section formatting, and weaker Anti-Patterns. Reading real files ensures your output matches the established library standard.
Style definitions live at: backend/sumi/references/data/styles/{style-id}.md
The filename becomes the style ID (kebab-case). The loader at backend/sumi/references/loader.py parses them automatically.
The StyleRef dataclass extracts:
id: From filename stem (e.g., adobe-slide from adobe-slide.md)name: From H1 heading, converted via _kebab_to_title() or _NAME_OVERRIDES dictbest_for: Text content of the ## Best For sectioncolor_palette_desc: Text content of the ## Color Palette sectioncontent: Full markdown (passed to the LLM during generation)The loader converts kebab-case IDs to title case automatically (cyberpunk-neon → Cyberpunk Neon). If the style name needs special casing (e.g., acronyms, proper nouns, non-standard capitalization), add an entry to _NAME_OVERRIDES in backend/sumi/references/loader.py:
_NAME_OVERRIDES: dict[str, str] = {
"ukiyo-e": "Ukiyo-e",
"art-nouveau": "Art Nouveau",
# add new override here if needed
}
Use this template. All sections are important — the full markdown is passed to the LLM during infographic generation.
The style definition is a prompt that guides an AI image generator. Every description must be vivid, concrete, and visually evocative — as if you're painting a picture with words. The generation model responds to sensory language, not abstract theory.
DO — use concrete, evocative descriptions:
DON'T — use abstract design theory:
The difference is stark: theory-oriented descriptions produce sterile, diagrammatic output. Prompt-oriented descriptions produce expressive, artistic output. Always ask: "Can the model see what I'm describing?" If the answer requires understanding design history, rewrite it.
# {style-id}
{1-2 sentence description capturing the essence and visual identity of the style. Make it vivid — describe what you SEE, not what design movement it belongs to.}
## Color Palette
- Primary: {2-4 dominant colors with hex codes}
- Background: {Background colors/treatments with hex codes}
- Accents: {3-6 accent colors with hex codes}
- Text: {Text color rules — what color on what background}
### Palette Combinations
| Combination | Colors |
|-------------|--------|
| {Name} | {Color A + Color B + Color C + ...} |
{3-4 combinations covering different moods/contexts}
## Variants
| Variant | Focus | Visual Emphasis |
|---------|-------|-----------------|
| **{Name}** | {Use case} | {Key visual characteristics} |
{2-4 variants offering meaningful visual diversity within the style}
## Visual Elements
- {10-15 bullet points defining the visual vocabulary}
- {What shapes, textures, treatments ARE used}
- {What is explicitly NOT used — helps the LLM avoid wrong choices}
- {Specific rendering rules: stroke weights, corner radii, fills, effects}
## Compositional Patterns
| Content Structure | Composition | Reference |
|-------------------|-------------|-----------|
| Hierarchy/levels | {How this style represents hierarchy} | {Visual reference} |
| Flow/process | {How this style represents sequences} | {Visual reference} |
| Comparison | {How this style represents side-by-side analysis} | {Visual reference} |
| Categories | {How this style groups related items} | {Visual reference} |
{Map 6-10 common content structures to style-specific compositions}
## Visual Metaphor Mappings
| Abstract Concept | {Style Name} Metaphor |
|------------------|----------------------|
| Data/information | {How this style visualizes data} |
| Processes | {How this style represents steps/flows} |
| Connections | {How this style shows relationships} |
| Growth | {How this style represents increase/progress} |
| Time | {How this style represents temporal progression} |
| Hierarchy | {How this style shows importance/ranking} |
{Map 10-15 abstract concepts to concrete visual representations}
## Typography
- {Font style: serif, sans-serif, hand-drawn, monospace, etc.}
- {Weight hierarchy: what weight for headings, body, captions}
- {Size hierarchy: relative or absolute size relationships}
- {Special treatments: letter-spacing, line-height, effects}
- {Alignment rules}
- {What to avoid}
## Anti-Patterns
{THE MOST IMPORTANT SECTION. This is what prevents the generation model from producing generic output. Write at least 8 anti-patterns for styles with close siblings in the library, at least 5 for unique styles. Be aggressive, specific, and repetitive.}
- **NOT {adjacent-style-id}** — {explain the specific visual difference, e.g., "NOT bauhaus — Bauhaus uses primary colors in geometric grids; this style uses earth tones in organic flowing forms"}
- **NOT {another-adjacent-style-id}** — {explain difference}
- **NOT {most likely wrong interpretation}** — {what it looks like when the model gets it wrong}
- **NOT {sterile/corporate version}** — {describe the generic fallback to avoid}
- {Quantitative threshold}: "{maximum N shapes per figure}", "{at least N% negative space}", "{no more than N colors per composition}"
- {Repeat the single most important constraint with emphasis}: "Flat fills only. NO gradients. ZERO shading. Flat. Flat. Flat."
- {End with a grounding sentence}: "This must look like [specific real-world artifact from a specific year/place], not [generic fallback]"
## Reference Images
{If reference images were provided, list them here with brief descriptions of what each contributes to the style definition. These are passed as --ref during generation.}
- `references/{filename}` — {what this image demonstrates about the style}
## Best For
{Comma-separated list of ideal use cases — this is used by the recommendation engine to match styles to content}
Every style — regardless of complexity — MUST include:
Never skip Anti-Patterns for "simple" styles. Styles that seem self-explanatory (like "pixel art" or "chalkboard") actually need strong Anti-Patterns most, because the model's default interpretation of these terms is often too generic to produce distinctive infographics.
Optional sections (include for rich/artistic styles, skip for straightforward ones):
Anti-Patterns have more impact on output quality than any other section. A style with weak Visual Elements but strong Anti-Patterns produces better images than the reverse. Follow these rules:
1. Name adjacent styles by their library ID:
2. Include quantitative thresholds:
3. Repeat the #1 constraint with aggressive emphasis:
4. Name the most likely failure mode specifically:
5. End with a grounding sentence:
Example — Charley Harper anti-patterns (strong):
- **NOT atomic-age/mid-century generic** — While Harper IS mid-century, his style is specifically
about EXTREME geometric reduction of NATURE subjects. Not starbursts, not boomerangs, not Googie.
- **NOT corporate Memphis** — Memphis uses pastel humanoid figures with noodle arms. Harper uses
bold-colored geometric animals. The reduction is toward geometry, not toward soft blobby shapes.
- **NOT clip art** — Clip art has too many curves and details. Harper animals are geometrically
pure — a bird body is a literal triangle, not a rounded cartoon blob.
- Maximum 8 geometric shapes per animal. If you can count more than 10, reduce further.
- This must look like a mid-century wildlife serigraph print where a cardinal is literally a red
triangle with eyes, not a generic flat illustration of a bird.
Each bullet in Visual Elements should pass the "can you see it?" test. Compare:
Specific patterns that produce strong results:
After writing the file:
_kebab_to_title() produces the correct display name. If not, add to _NAME_OVERRIDES in backend/sumi/references/loader.py.# adobe-slide in adobe-slide.md).## Color Palette, ## Best For exactly (the loader regex depends on these).Generate a test infographic using the new style definition to catch issues that only surface at generation time.
--ref images. Do NOT use generic stock photos as references — they push illustration styles toward photorealism.There are currently 42 styles in the library. Read 2-3 of the most adjacent ones before writing a new style — they are your primary Anti-Pattern targets.
aged-academia, airline-travel-poster, art-nouveau, art-nouveau-mucha, atomic-age, axonometric, bauhaus, bold-graphic, charley-harper, constructivism, de-stijl, dia-de-muertos, fantasy-map, futurism, golden-age-comics, googie, ikea-manual, isometric-technical, isotype, jack-kirby, kandinsky, keith-haring, knolling, ligne-claire, matsumoto, memphis, moebius, origami, osamu-tezuka, patent-drawing, pop-art-lichtenstein, renaissance-diagram, richard-scarry, saul-bass, shan-shui, storybook-watercolor, studio-ghibli, sumi-e, superflat, synthwave, tibetan-thangka, ukiyo-e
If the new style overlaps significantly with an existing one, you must either:
development
Generate artistic infographics from any topic. Runs the Sumi pipeline (analyze → structure → craft prompt → generate image) entirely within Claude Code. Use when "generate infographic", "create infographic", "sumi", "make an infographic about", or "visualize topic".
tools
Implement Server-Sent Events streaming from Cloudflare Workers to browser clients with reconnection, state persistence, and progress tracking. Use when building "SSE streaming", "real-time updates", "server push", or "event streaming".
development
Audit websites by cross-referencing query indexes, sitemaps, and navigation to identify content gaps, stale pages, missing metadata, and quality issues. Use when "auditing a website", "finding content gaps", "site quality audit", or "content inventory analysis".
data-ai
Track user session context across multi-turn interactions using browser sessionStorage and server-side KV caching with TTL. Use when implementing "session tracking", "conversation context", "multi-turn sessions", or "user journey tracking".