Showcase — Harry Bournazos, 2026

cgen: components produced from a single design contract rather than ported by hand for each stack

A working proof of concept: four components read from Figma over the Dev Mode MCP server, defined once in ir/, generated for React + MUI and Lit Web Components + Tailwind, and verified by one Playwright conformance suite. The repository is private; this page and the demo below show it in action.

00 — The demo

Import from Figma, generate a stack, run conformance

Five minutes, captioned, no audio. Two Claude Code skill runs replayed at speed: /cgen-import on the step indicator, then /cgen-generate for a React + TypeScript + MUI package that did not exist before.

01 — The mechanism

A single contract, emitted for each stack

Input
Figma
signed-off specs
→
Contract
ir/
token and component JSON
→
Guide
kb/<stack>/
stack-specific guide
→
Result
packages/<project>
the generated package
vanilla-reference/ — built by AI, reviewed by humans against Figma, and refreshed every time the design moves. Genuine styling; the gold standard for both looks and behaviour. What doesn't get copied is its plain-CSS build.
tests/conformance/ — one set of checks, executed against the build of every stack.
02 — The rules

Chiefly here so stacks don't inherit one another's assumptions

These came out of an actual mistake, not from foresight.

1

The contract is right

When a package and ir/ disagree, the package is the one at fault.

2

Copy the appearance, not the tooling

vanilla-reference sets the gold standard for looks and behaviour — but its plain CSS is not the styling engine to reproduce.

3

No looking sideways

A new stack never reads the code or KB of any other stack.

4

Keep to your own folder

The IR and shared config are off limits — a gap gets flagged, never patched.

03 — /cgen-generate, a worked example

An imagined run across all six steps

Suppose someone enters /cgen-generate acme angular unocss — a stack that has never been generated before.

flowchart TD Start(["/cgen-generate acme angular unocss"]) --> Parse["Parse: project = acme stack = angular-unocss"] Parse --> KBCheck{"Does kb/angular-unocss/KB.md already exist?"} KBCheck -- no --> WriteKB["Write KB.md using only ir/ + the Angular/UnoCSS docs (flagged: awaiting sign-off)"] KBCheck -- yes --> ReadCtx WriteKB --> ReadCtx["Load ir/, the KB and vanilla-reference"] ReadCtx --> Scaffold["Scaffold nothing but packages/acme/"] Scaffold --> Test["pnpm test:conformance --project=acme"] Test --> Gap{"Is ir/ itself lacking something this stack needs?"} Gap -- yes --> FlagCentral["Report: gap raised centrally, no local patch"] Gap -- no --> Report["Report: package done, KB not yet signed off"] classDef decision fill:#eef1f8,stroke:#415385,color:#2f3d63,font-weight:600; classDef flag fill:#fdecea,stroke:#c52a1a,color:#c52a1a; class KBCheck,Gap decision class WriteKB,FlagCentral flag

What that run should hand back

1

A fresh KB, not yet signed off

kb/angular-unocss/KB.md now exists, but it's marked as needing review from design and engineering — treated just like an openAssumptions entry.

2

One new package and nothing else changed

packages/acme/ shows up with its own config, components and Storybook, while ir/ and all the other packages stay exactly as they were.

3

A conformance run limited to this package

packages/acme/ is discovered automatically — there's no config to edit in order to register it before the tests run.

4

Central gaps called out, never patched

Should some part of ir/ itself not suit this stack, the report states that plainly rather than silently routing around it.