This skill is for the exact problem that makes generated art drift over time: a project gets a few one-off screenshots, then nobody can remember which route, what size, or which tokens they used. The workflow here keeps the process repeatable instead of improvisational.
What it does
It turns a vague request like "make the OG cards look like the site" into a tractable workflow that an agent can execute from the repo itself:
- Detects the stack and runtime (bun if the project uses it, otherwise
tsx). In a JS/TS project the generator goes inscripts/image-gen-tools/with a root script; in Flutter, Swift, Android and other non-JS repos that folder becomes a self-contained sub-project. - Reads the real design tokens, fonts, and icon library, copies the values exactly, and shows them to you before any code exists.
- Asks for a few product decisions up front: which artifacts, the standard size for the purpose, a layout preset, and whether the image is composed from HTML or a live app capture.
- Confirms where titles and descriptions come from (a nav config, route manifest, or content collection) and where the images land, which also sets the render scale.
- Generates the generator: a shared
card-renderer.tsframe plus one script per artifact family, rendered in headless Chromium so the output is reproducible, not hand-edited. - Runs it and checks the result with a bundled
verify-images.mjsscript (file count, pixel dimensions, suspiciously small files), then looks at a few images and runs the project's typecheck and build.
<!-- diagram: flow-image-artifact-setup -->
graph TD
A[Identify the project, runtime, and location] --> B[Extract exact tokens, fonts, and icons]
B --> C[Agree on artifacts, size, layout, composed or live]
C --> D[Confirm data source, destination, and render scale]
D --> E[Generate scripts/image-gen-tools]
E --> F[Run it, verify-images.mjs, review, build]Why it earns a place here
The tricky part of image generation is rarely the Chromium code. The hard part is making sure the card looks like the product, uses the correct source data, and lands in the right output path without drifting later. This skill locks those decisions into a workflow so the next time someone asks for a card set, they start from the same source of truth instead of repeating the same guesswork.
Prerequisites
- Bun or
tsxto run the generated TypeScript script. The skill uses bun when the project already does, otherwise it addstsx. playwright-coreplus its Chromium binary. The skill adds the package as a dev dependency and installs Chromium, preferably from apostinstallso a fresh clone works. In a bun project that isbunx playwright-core install chromium.sharp, added by default for compression and JPEG output. It is dropped only when every artifact is an uncompressed PNG.- Node, to run the bundled
verify-images.mjscheck. It has no dependencies. - The app running locally, only for live showcase cards shot from real pages rather than composed from HTML.
What's inside
Maintained publicly in Agentry Labs, a framework-agnostic collection of reusable AI-agent components. The skill directory contains:
SKILL.md: the six-phase workflow for setting up the generatorreferences/project-detection.md: per-stack detection signals, image destinations, token locations, and install commands per package managerreferences/layout-presets.md: the dimension table, four layout presets, and the shared card framereferences/rendering-guide.md: font loading, asset inlining, encoding choice, icons, failing loudly, and variable-length textreferences/capture-pitfalls.md: the gotchas that make live screenshots look polished but actually failassets/card-renderer.ts: the shared HTML/CSS + Chromium runner to adapt for new artifactsscripts/verify-images.mjs: a dependency-free check of image count, dimensions, and file sizeevals/evals.json: test prompts covering OG cards, monorepo README banners, and Flutter store tiles
