02OPERATOR-STACK SERIES · REPO 2 OF 3

A visual-asset Claude worker, ICM-structured, fork-ready.

Dispatched a brief, produces self-contained HTML — social cards, OG cards, preview pages, diagrams — composed against a visual system you configure. Inline CSS only. No external fetches. MIT licensed.

View on GitHub Five-minute setup
#f6f5f0
--bg
#111111
--ink
#6a6862
--muted
#ff5436
--accent-warm
#1f4dff
--accent-cool
#d8d4c8
--rule

03WHAT IT IS

Accepts a brief. Produces HTML composed against your visual system.

A working Claude worker that does one thing: reads a brief, reads a visual-system file at reference/visual-system.md, produces HTML with inline CSS and no external dependencies. Fork the repo, edit one markdown file, drop a brief in briefs/, dispatch with one prompt.

Brief-driven

One brief, named dimensions, verbatim copy.

Every dispatch starts with a six-section brief at briefs/<date>-<slug>.md. The brief names the artifact set, the pixel dimensions, and the copy text. The worker doesn't paraphrase.

Palette-configurable

The visual system lives in one file.

Palette, type, grid, density — all in reference/visual-system.md. Edit once. The worker reads it every dispatch and composes against it. No off-table colors. No font surprises.

HTML-first

Source format, not delivery format.

Artifacts ship as self-contained HTML — inline CSS, no external font fetches, no CDN dependencies. Rasterize to PNG with one shell command when a platform demands one. HTML stays editable.

A dispatch trigger looks like this# In a fresh Claude session, after opening the repo folder: > Read the brief at briefs/2026-05-14-focusblock-launch-visuals.md and execute. # That's the entire dispatch. The worker handles the rest: # 1. Reads STATUS.md (first read) # 2. Reads the brief (the contract) # 3. Reads reference/visual-system.md (palette + type + grid) # 4. Runs the pre-flight checklist (5 items, grep-able) # 5. Produces the artifacts as self-contained HTML # 6. Self-verifies (dimensions, palette, contrast, zero external fetches) # 7. Updates STATUS.md (last write)

04WHY THIS ONE

Five things this starter does that most don't.

There are other Claude-worker starter kits. The differentiators below are the reasons this one exists. Each is enforced by the architecture, not by a README that hopes you'll remember.

  1. ICM rigor

    The three always-relevant files — CLAUDE.md, CONTEXT.md, STATUS.md — plus identity, rules, examples, and reference. Not "a CLAUDE.md and hope." Structural, named, enforced.

  2. 60-30-10 layer separation

    Infrastructure / Orchestration / AI, in the corrected definition. AI is the 10%; the other 90% lives in scripts, files, and declarative rules outside Claude. This worker's specific application: HTML is source, PNG is infrastructure — rasterization is one shell command, not an AI step.

  3. Brief-as-contract dispatch

    Clean role boundary between orchestrator and worker. The worker is meant to be called, not driven free-form. The brief is durable, audit-trail-friendly, and complete-or-refused — no "I'll do my best with what's missing."

  4. Pages-ready landing

    The repo IS its own marketing surface. Push it, enable GitHub Pages from the /docs folder, and a public URL goes live in sixty seconds. The page you're reading now is that file.

  5. Tied to a real article series

    The architecture is documented in the operator-AI series, starting with "I burned 800,000 tokens on one daily routine." Read the article, then the code. The two reinforce each other.

05SAMPLE OUTPUT

One brief, three artifacts.

The repo ships with one worked example. A six-section brief asks for a launch sequence for a focus-timer app called FocusBlock: a 1080×1080 social card, a 1200×675 OG card, and a 1280×900 preview page. The worker reads the brief, reads the default visual system, and produces all three artifacts as self-contained HTML.

Social card 1080 × 1080

LAUNCH · v1.0

Schedule the focus.
Stop renting the willpower.

focusblock.example/download
OG card 1200 × 675

LAUNCH · v1.0

Schedule the focus. Stop renting the willpower.

focusblock.example/download

Full artifact set: social-1080.html · og-1200x675.html · preview.html · paired brief + self-verification table in examples.md.

06IN PRODUCTION

Real-user receipts.

This repo is a fresh release. Real-user receipts go in the block below once operators who fork it ship work with it.

Receipts pending.

Forked this repo and shipped real work with it? Open an issue with a one-paragraph note on what you built and how the dispatch shape held up. Selected receipts will be quoted here verbatim, with consent.

07GET STARTED

Five minutes from fork to first dispatch.

  1. Fork the repo

    Click Fork on the GitHub page, or clone directly: git clone https://github.com/NFTYoginis/your-design-worker.git

  2. Open the folder in a Claude session

    Either Claude Code in the terminal, or a Claude Project with the folder uploaded. The worker reads CLAUDE.md as its entry point.

  3. Edit reference/visual-system.md

    The repo ships with a working neutral default so the example dispatches as-is. Replace the default with your own palette tokens, typography stack, grid rules, and density conventions.

  4. Write your first brief

    Copy briefs/_BRIEF-TEMPLATE.md to briefs/<today>-<slug>.md. Fill the six sections — including pixel dimensions per artifact and verbatim copy. Keep it on one screen.

  5. Dispatch

    Paste this into the Claude session: Read the brief at briefs/<your-filename>.md and execute. The worker takes it from there.

08QUESTIONS

What you'll want to know.

Why HTML and not PNG, JPG, or SVG?

HTML is source. PNG is delivery. A hex code in HTML lives in one place — edit it once, the whole artifact updates. A hex code in a PNG is baked into pixel data; you re-render the whole thing to change it. HTML is also diffable (git history of an artifact is meaningful) and accessible (real text, screen-readable, indexable).

Rasterizing the worker's HTML output to a PNG when a platform demands one is one shell command (chromium --headless --screenshot=… --window-size=W,H file.html). That command is infrastructure, not AI. It runs from your terminal, your Makefile, or your CI.

What's the difference between this and other ICM starter kits?

Three things. First, the architecture enforces the orchestrator-worker boundary — most kits collapse both roles into one session and burn tokens accordingly. Second, the 60-30-10 layer framework is restated correctly (Infrastructure / Orchestration / AI), not as a context-budget split. Third, every repo ships with a Pages-ready landing page; push to GitHub, enable Pages from /docs, public URL in sixty seconds.

Why is the visual-system file separate from the worker code?

Because the visual system is the configurable part. The worker's job — read brief, read visual system, compose artifact — doesn't change when your brand palette changes. Keeping the system in reference/visual-system.md means you can fork once and re-skin the worker for different brands, different sub-brands, or different campaigns without touching anything in rules.md or identity.md.

What does the worker refuse to do?

Five named refusal gates in rules.md, each with verbatim refusal language. The big ones: empty visual-system configuration, missing brief preconditions, text-on-asset claims the brief doesn't ground (statistics, ratings, badges), third-party trademarked visual identity without consent confirmation, and high-harm domain imagery without explicit authorization. When a gate fires, the worker writes a question file at briefs/questions/<slug>-question.md and stops. It does not "do its best."

Can the worker produce real PNG/JPG files, not just HTML?

The worker does not. Rasterization is a deliberate role boundary — it's infrastructure, runs deterministically, doesn't need AI reasoning. You run it. One headless-browser command turns the worker's HTML into a PNG of any size. Doing rasterization in-loop would put the 10% AI layer in charge of pixel encoding, which is the opposite of what the architecture is trying to enforce.

What if I need fonts that aren't in the system stack?

Bundle the font file inside the repo and reference it locally with @font-face pointing at a relative path. The worker reads the visual-system file; if your typography table says @font-face url('../assets/fonts/Suisse-Bold.woff2'), that's what the artifact uses. No external CDN. No fonts.googleapis.com. Self-contained means self-contained.

How does the worker handle a campaign that needs cross-artifact consistency?

The visual-system file enforces it. The palette table, the typography stack, the grid rules — all centralized. When the brief asks for a social card, an OG card, and a story variant from one dispatch, the worker reads the same visual-system file three times and composes three artifacts that share palette, type, and grid by construction. Consistency lives in the configuration, not in the worker's memory.

Is this affiliated with Anthropic or Claude?

No. This is an independent project demonstrating one way to structure a Claude-based visual-asset worker. Claude is the model the worker runs on; the architecture and the opinions are this repo's.

09THE SERIES

Two of three.

This repo is the second in a three-repo operator-stack series, each demonstrating the same architecture in a different domain.

your-content-worker — already shipped. Brief in, prose out. github.com/NFTYoginis/your-content-worker

your-design-worker — this one. Brief in, self-contained HTML artifacts out.

your-animation-worker — next in the series. Brief in, voice-to-video MP4 out, via Remotion.

The architecture is documented in Article 1 of the operator-AI series: I burned 800,000 tokens on one daily routine. Here's the architecture that killed it. Read the article for the receipts; read this repo for the code that runs the fix.