content-create-hero-image

name	content-create-hero-image
description	Use when the operator wants a hero or meta image for a Prisma blog post; asks to create or generate a blog hero, cover, social card, Open Graph, or YouTube image; mentions cover art, a blog thumbnail, cover.svg/hero.svg/meta.png; references content-create-hero-image; or wants to interactively design cover imagery in Prisma's 2026 brand (light paper, prism accents, Sora). Produces an editable SVG hero plus a pixel-exact PNG meta image, and includes an interactive mode and a built-in design-review pass.
metadata	{"author":"Prisma","version":"2026.8.11"}

Create blog hero & meta images

Produce the hero and meta (Open Graph) images for a Prisma blog post in the 2026 brand — light paper surfaces, the prism accent family (cyan/yellow/red), Sora display type — styled from the bundled reference assets and from the most recent posts in the operator's checkout, then wire them into the post's frontmatter.

The hero is a hand-authored, layered SVG — the editable source of truth — rendered to a pixel-exact PNG. The meta image is raster (PNG) because social platforms do not render SVG. A single design usually serves both. Output is saved into the repo, not just returned in chat.

Companion to content-write-blog (which scaffolds the post itself). This skill makes the imagery; it can be invoked standalone or as the cover step of that workflow.

Use README.md for usage and sample prompts; this SKILL.md is the execution contract for producing assets.

References (load on demand)

• references/design-system.md — colors, fonts, layout recipe, the content-module catalog, formats, sources. Read before designing.
• references/design-review.md — structured critique (A–F grades, AI-slop list, fix loop), adapted from the gstack design-review skill. Read before the review pass.
• assets/tokens.json — machine-readable tokens; the source of truth for hex/font values.
• references/figma-source.md — what SOCIALS.fig contains and how it was extracted.
• references/figma-mcp.md — optional: pull live specs/assets from the Prisma Figma workspace when a Figma MCP is connected.
• assets/logos/ — official Prisma logo/symbol, Prisma 8 mark + lockup, Postgres/Compute icons (README.md).
• assets/fonts/ — bundled brand fonts (Mona Sans, Inter, Geist Mono); used by the scripts.
• assets/templates/cover.svg — parameterized starting template.
• assets/examples/ — worked hero/meta pairs per content module. Pre-rebrand (dark Eclipse era): study for composition and module structure ONLY — their palette, fonts, and surfaces are retired. The current quality bar is the newest committed covers in apps/blog/public/*/imgs/.
• assets/hero1.svg–hero4.svg — abstract reference heroes, also pre-rebrand; same structure-only caveat.
• scripts/embed-fonts.py — inline the brand fonts into the SVG as base64 @font-face. Run first.
• scripts/export-png.sh — render the font-embedded SVG to PNG via headless Chrome so the PNG matches the SVG in a browser exactly. Run second.

Output contract

Two images: a hero shown on the post itself, and a meta image for Open Graph and social cards. A single design may serve both files.

Contexts of use — design for all three. A cover lives as (1) a grid thumbnail in the blog index, cropped to ~16:9 by object-cover and rendered ~400px wide directly beside the post's real title, on light AND dark card surfaces; (2) the full-size social/OG card; (3) the in-post hero. The thumbnail-next-to-title context drives the hardest rules:

• Headline: a compressed thesis of ≤6 words, or no copy at all — never a restatement of the post title it will sit beside. Across a batch, vary composition (no-copy graphic-led, corner-stripe brand moment, headline+module) so adjacent covers don't read as one template.
• Kicker: ≥20px with a ≥5.5px dot, or omit it — a 17px kicker is noise at thumbnail scale.
• Sign-off: prefer the full-color lockup (assets/logos/prisma-lockup-color.svg, ~112px wide, inlined as a group) over the plain-text wordmark; the mark carries at thumbnail scale where small grey type disappears.
• Crop-safe zone: every critical element (lockup, kicker, headline, module edges) stays ≥72px from every canvas edge and must survive a centered 16:9 crop of the 1200×630 frame.
• Dual-surface: the artwork never theme-switches; it must read as an intentional object on both white and ink (#1a1a1a) surrounds. Avoid vast empty pure-white regions — washes on covers run a step stronger than page washes (~0.18–0.28 per stop) so the piece carries color at small sizes and on dark.

1. Format.
   • hero: SVG by default — the prisma.io/blog standard, and it suits the typographic, geometric heroes the blog favours. The SVG is the editable source of truth; always export its PNG too. Fall back to a raster (PNG) hero only when the hero is genuinely photographic, or when the operator asks for raster — and say so when you do.
   • meta: PNG (raster) always. Open Graph and social cards do not render SVG.
2. Dimensions. 1200×630 px (standard Open Graph size, ~1.9:1) for both hero and meta by default.
   • SVG: viewBox="0 0 1200 630" with width/height set to 1200/630.
   • Raster: 1200×630 at 1x (renders crisply on social cards, ~200–500 KB). A 2x export (2400×1260) is acceptable for retina crispness only if it stays within budget; otherwise drop back to 1x. Always preserve the 1.9:1 ratio.
   • Other canvases (in-post hero 844×474, YouTube 1280×720, custom) are produced on request — change width/height/viewBox and scale font sizes proportionally (≈ ×0.70 for the 844-wide hero).
3. Size budget. Keep the meta PNG under 1 MB. A 1x export normally lands ~200–500 KB; a cover whose art is mostly smooth wash gradients can overshoot (one landed at 1.4 MB), so check the file and re-export at 1x, or flatten a redundant wash layer, if it does. Keep the SVG lean with subset, embedded fonts (step 6): a typographic cover lands ~30–55 KB, and a code/terminal-heavy one ~55–75 KB because the mono glyph subset is larger. Above ~120 KB, check that fonts actually subset (the venv python needs fonttools + brotli; without them embed-fonts.py silently falls back to embedding whole WOFF2 files). Prefer vector paths over embedded raster; flag any SVG over ~1 MB.
4. Naming. Base names hero and meta, extension following the format: hero.svg (or hero.png when raster) and meta.png. No content hashes, no dimensions in filenames. For N explored directions, suffix the base name (hero-a.svg/meta-a.png, …).
5. One design, both files. When one design serves hero and meta, render the meta PNG from the hero SVG so they are pixel-identical.
6. Destination. The image directory the recent posts use for the given {slug} (see Discover blog conventions). Fall back per step 7 of the workflow only when discovery yields nothing.

Pre-conditions — halt if unmet

1. A blog post slug, or a post title to derive the kebab-case slug from. Ask if neither is given.
2. Reference material: the bundled assets/ (examples, logos, fonts, tokens) or the recent posts found during discovery. Ask the operator to supply some if none is available.

Discover blog conventions

Never hardcode blog structure: the repo evolves. Before designing, learn the current conventions from the operator's checkout.

1. Find the last few published posts (most recent by date in filename or frontmatter).
2. From those posts, extract:
   1. Image directory and filename pattern for both hero and meta (e.g. public/{slug}/imgs/hero.svg, meta.png, or whatever the recent posts use).
   2. Frontmatter fields that point at the hero and the meta image, and the exact value shape each expects (public-relative path, relative path, etc.).
   3. Prevailing hero format (SVG vs raster) so the default matches what the blog ships.
3. Record the resolved directory, filenames, frontmatter fields, and value shapes; use them for the rest of the workflow.

Inputs

Blog context drives the design. Useful inputs: title, subtitle/excerpt, the Prisma product in focus, target audience, the core technical concept, desired mood, required dimensions, and the output format. A path to the post's index.mdx is the richest input — read its frontmatter and lead. A GitHub PR URL is also valid input: read the PR title/body and any changed blog index.mdx files before designing.

Workflow

0. (Optional) Refresh from the live Figma workspace

If a Figma MCP is connected, follow references/figma-mcp.md to reconcile tokens.json against the live Eclipse variables, sight the current cover frames for layout/dimensions, and re-export any stale logos. Read-only — never edit the shared file. If no Figma MCP is connected, skip this; the committed assets are the default.

1. Read the blog context

Extract: main product, core concept, audience, and intended emotional register (launch / educational / conceptual / editorial / technical). Given an index.mdx, read the frontmatter (title, metaDescription, slug) and the lead paragraph. Given a prisma/web PR URL, fetch the PR metadata and changed blog files, then design one hero/meta pair per changed post unless the operator asks for a single combined cover.

2. Gather inputs — interactive or inferred

Two ways to reach a design brief. Pick based on how the skill was invoked:

• Inferred (default). Context is rich (an index.mdx, a PR, a clear pitch). Infer the brief and ask only what you genuinely cannot — offer a recommended default with each, and prefer a structured-choice question when the environment supports one.
• Interactive. The operator asks for interactive/guided mode, or gives only a thin prompt ("make me a cover"). Drive the brief through the question set below in one structured-choice round (don't interrogate one question at a time). Skip any question already answered by context, and carry the recommended default into each.

Interactive question set. Always read the post first, then ask a single structured-choice round. Make every question context-aware — phrase it around this specific post and carry the recommended default (derived from the content) into each option, so the author can accept the whole set in one pass. Title each round with the post, e.g. "Blog hero — 'Price the Work, Not the Workflow'".

#	Question	Context to surface	Default
1	Canvas size	which format(s) this is for	Social/OG 1200×630 (offer in-post hero 844×474, YouTube 1280×720, custom)
2	Text on the cover?	"Most Prisma blog images carry no copy — the graphic + Prisma wordmark carry it. But this post has a strong short thesis that could work as a headline."	No copy, unless the thesis is short and punchy
3	Custom copy (if text)	quote the post's own thesis as the suggestion	the post's thesis verbatim; blank = no text
4	What should the graphic symbolise?	restate the post's core idea in concrete terms	the literal mechanism from the post
5	Isometric skew on the graphic?	"Default yes for card/table modules; flow/loop diagrams usually read best flat."	yes for cards/tables, flat for flows
6	Accent color	name the owning product	cyan (ORM / Prisma 8 / platform); yellow (Postgres); red (Compute)
7	Mood	launch / educational / conceptual / editorial / technical	educational, light paper
8	Product logo	which mark, if any	the post's product mark when it clarifies; else just the Prisma wordmark
9	How many directions to explore?	1–4 distinct concepts	1 (offer up to 4)

Turn the answers into the brief(s) in step 3. No-copy is a first-class, common choice — when chosen, the graphic + Prisma wordmark carry the cover. If N directions are requested, produce N separate hero/meta pairs (hero-a, hero-b, …) and present them together. Honor every "must be present" element and the chosen logo/skew/background; creative direction still obeys the anti-patterns and the design-review bar — creative ≠ slop.

3. Choose a visual direction

Decide a concept that's literal-but-elegant, never generic. Pick: surface (light paper default / ink dark only with a stated reason), product accent, kicker label, the content module that fits the content (see design-system.md → Content modules: pipeline/flow, data/log panel, terminal, code card, comparison card), and whether a product lockup belongs in the composition. Anchor every choice in design-system.md. One accent, one idea, strong hierarchy, generous space.

Before drawing, write a compact design brief for yourself:

• Message: the one sentence the cover must communicate.
• Metaphor / module: the concrete visual structure, preferably from the post itself (log, stream, config file, deploy target, image pipeline, chart, …).
• Product signal: the product logo/icon to use, or "Prisma only" if no product owns it.
• Output path: the discovered blog asset path, the example path, or the fallback path.

4. Select assets

From assets/logos/: use an official logo or product mark only when it clarifies the idea. Default to no footer chrome. If a brand sign-off is wanted, place the Prisma wordmark in the bottom-left as plain text with no logo mark beside it, or use a single official product lockup as the subject — never pair an icon with extra "Prisma" text, and never add prisma.io/blog to the canvas. Drop the wordmark entirely rather than crowd the frame. Pull exact hex/fonts from tokens.json; do not introduce off-system colors, fonts, or stock imagery.

5. Generate the SVG

Copy assets/templates/cover.svg and fill the {{TOKENS}}, or hand-compose when the graphic is the message (e.g. a chart) — keep the layer groups (background, badge, headline, brand, chart) so it stays editable. Hand-wrap the title into 1–3 lines (drop title size to 56px if > 30 chars). Set the eyebrow/badge pill width to roughly (label length × 14) + 48. Include the <title>/<desc> metadata.

Fonts (avoid the #1 off-brand bug): the brand faces are Sora (headings/display, weight 500, emphasis 600 — never 700+), Inter (body 400, kicker labels 600), and Mona Sans Mono (data/code, 500), bundled in assets/fonts/. Do not use Mona Sans display, Geist Mono, or Barlow — those are the retired pre-rebrand faces. A wrong family/weight falls back to a generic sans. For emphasis, change colour or size, not weight. When the graphic is the message, let it own the canvas — center it, drop competing chrome, use the standalone product logo as the brand mark, and label data with real numbers.

Keep text short. Don't repeat the full blog title when a sharper phrase reads better — use the post title in <title> metadata and a shorter headline on canvas. Supporting lines must be factual labels, not taglines. Avoid fluffy copy, ellipses, and stacked sentence fragments.

Diagram cards (the right-side metaphor): keep the card off the canvas edge — ≥ 48px margin on the right (1200-wide canvas → card right edge ≤ ~1128). Position absolutely, not via a group transform that pushes past the edge. Inside: give arrows real length (~40–56px shaft + arrowhead), pad content evenly from the card walls, and make every node labeled and connected — a flow should end in a recipient (client, webp file, deploy target), not a dangling arrow. Tie any header number to the data it labels, and highlight the "live"/current element.