Guide

A code generator for HTML that reads a written constitution before it writes a line.

Most tools in this space will happily hand you Inter on white with a purple gradient hero and a grid of iconified cards. mk0r refuses by default. Not because the model is smarter, but because a rule list in /app/CLAUDE.md is copied into every sandbox and the agent reads it before its first tool call. Here is the full rule list, with line numbers, so you can grep it in the public repo yourself.

M
Matthew Diakonov
10 min
4.8from 10K+ creators
Three-colors-maximum rule (line 102)
No Inter, Roboto, Arial default (line 144)
No icon library install (line 115)

What every page on this topic tends to list, and what it leaves out

Look at the pages you reach by typing the title of this guide into a search bar. They all list the same thing: what the generator can emit. Tables. Forms. Navbars. Hero sections. Cards. Pricing blocks. That list is almost the same across every tool because the underlying models have the same training distribution. What those pages never list is the set of defaults the tool refuses to ship. The refusal list is where real differentiation lives, because the refusal list is where the taste is.

mk0r publishes its refusal list. It lives in the public repo at src/core/vm-claude-md.ts, templated into /app/CLAUDE.md inside every sandbox, and paired with a full frontend-design skill that extends the rules. The rest of this page walks the list, rule by rule, with line numbers.

0Colors allowed, max
0Icon libraries installed by default
0Patterns on the anti-pattern block
0Port where the HTML is served

Rule 1: three colors, not four

The single most common mark of auto-generated HTML is a palette with three to six soft gradients competing for attention on the same page. The rule that kills this is the first thing the agent reads in the Design Constraints block.

src/core/vm-claude-md.ts

Two details matter. First, the rule names the accent color family (Tailwind's built-in palette, no custom hex) so the agent does not invent a fifth off-brand color. Second, it bans dark backgrounds unless the user asked. A lot of code-generating agents default to dark mode because dark is a shortcut to "looks designed," and the shortcut is what makes every output feel the same.

Rule 2: no icon library, period

The second most common tell is a uniform row of cards, each with a pastel icon in a rounded square at the top. The icon library install is where that pattern gets locked in, so the rule cuts it at the install step.

src/core/vm-claude-md.ts

The rule names three libraries by name (Lucide, Heroicons, FontAwesome) because those are the ones an agent would reach for first. And the functional-icon allowlist is narrow: chevrons, close buttons, check/x indicators, navigation arrows. Everything else has to earn its place.

Rule 3: not Inter, not Roboto, not Arial

Typography is the third tell. If you have ever looked at an auto-generated landing page and thought it looked like every other auto-generated landing page, the font is usually why. The rule names the culprits.

src/core/vm-claude-md.ts

The frontend-design skill, injected at /root/.claude/skills/frontend-design/SKILL.md, extends this rule with an even sharper line: do not converge on Space Grotesk either.

src/core/vm-claude-md.ts

That Space Grotesk callout is the giveaway. Somebody watched the agent pick the same "interesting" font across enough sessions that it became the new Inter. The rule explicitly names the failure mode and tells future agents not to repeat it. You will not find that level of specificity in a hidden system prompt.

The Anti-Patterns block, verbatim

The rule list ends with a block of six explicit don'ts. Each is a specific visual pattern that "looks AI-generated" the moment you see it. They are listed as forbidden, not discouraged.

src/core/vm-claude-md.ts

The full refusal list, with brief reasons

  • Purple or indigo gradients on white — the defining look of generated hero sections since 2023
  • Uniform rounded cards in a grid with icons — the cheapest way to fake structure
  • Generic centered hero with a gradient button — the shape every tool emits
  • Sections that differ only by slight color changes — no editorial rhythm
  • Cookie-cutter layouts that could belong to any product — no commitment to the thing being built
  • Placeholder images or Lorem Ipsum — the agent has to source real copy or ask

How the usual generator starts vs. how this one starts

The contrast is easier to see as before/after. Given a one-line prompt like "build me a landing page for a habit tracker with email reminders," here is what a generator with no design constraints tends to produce, next to what a generator bound by the constitution produces.

Same prompt, two starting points

Default code generator output. Inter everywhere. Hero headline centered on a soft indigo-to-violet gradient. Five feature cards in a grid, each with a Lucide icon in a rounded square. A pricing section with the same rounded cards but a different tint. Lorem Ipsum in three testimonial blocks. Looks designed at a glance, looks identical to the last twenty AI-built landing pages on close inspection.

  • Inter on white, no display font pair
  • Purple to indigo gradient hero
  • Icon grid with Lucide installed by default
  • Lorem Ipsum in testimonials
  • Four to six accent colors competing

A more honest side-by-side

No tool wins on every axis. Here is where the constitution applies, where it does not, and where the tradeoffs land.

FeatureTypical HTML code generatormk0r (constitution on)
Color palette cap before code is writtenNo cap, model picks freelyYes, three colors maximum (line 102)
Typography default fontsInter on white, most of the timeExplicitly not Inter, Roboto, Arial, or Space Grotesk
Icon library policyLucide or Heroicons installed reflexivelyNo install unless user asks (line 115)
Anti-pattern list shown to the modelNone, or hidden in a closed system promptSix explicit forbidden patterns (lines 170 to 175)
User override pathN/A, defaults are not visible to overrideAll rules prefixed 'unless the user explicitly overrides'
Rules readable in public sourceClosed, behind an APIsrc/core/vm-claude-md.ts, grep-able
Where the rules are enforced at runtimeEmbedded in the request path, not inspectable/app/CLAUDE.md inside every E2B sandbox
Account needed to read or run themUsually yesNo

Where the rules physically live at runtime

The constitution is not an abstract claim. It is a file on a real filesystem inside a real sandbox. Here is the layout as the agent sees it on its first tool call.

Agent's first look at the sandbox filesystem

The system prompt that points at the constitution

The agent does not have the rules memorized. It has a one-line pointer that tells it where to look. That pointer is the entire system prompt.

src/core/e2b.ts

The sentence "Read your CLAUDE.md files for detailed workflow, coding standards, and memory instructions" is the hinge. A short system prompt plus a long, file-based rule book means the rules can be edited, versioned, and reviewed without touching the request path. It also means anyone can read them.

How the rule file shapes a single HTML generation

Think of the constitution as a hub. Inputs flow in from one side (a user prompt, a session context, any uploaded assets). The hub is the rule set. Outputs fall out the other side (a component file, a route, a rendered page). Every output has passed through the rule set.

One generation, constitution in the middle

Prompt
Session context
CLAUDE.md rules
frontend-design skill
Agent planning pass
src/App.tsx edit
src/components/<new>.tsx
Vite rendered HTML
Playwright verification

The workflow, in the order the agent runs it

The constitution is rule 3 in the workflow, not rule 1. The agent first reads the user prompt and checks pre-provisioned services, then commits to an aesthetic direction, then writes components, then verifies in the browser. Here is the exact order, taken from the Workflow block of the same file.

From prompt to rendered HTML

1

Understand the request

Agent reads the prompt and asks a clarifying question if the brief is ambiguous. No speculative building before intent is clear.

2

Check /app/.env for pre-provisioned services

Analytics, email, database, and source control are already set up. The agent uses them instead of asking for keys.

3

Commit to an aesthetic direction

Brutally minimal, editorial, retro-futuristic, organic, industrial, playful. One direction, executed with precision. No hedging with a gradient.

4

Apply the Design Constraints

Three colors max. No Inter, Roboto, Arial, or Space Grotesk. No icon library install. No purple gradient on white. This is where the refusal list bites.

5

Write components, always import in App.tsx

A new component file that is not imported from src/App.tsx will never render. The rule prevents the most common failure mode.

6

Verify in Chromium via Playwright

Navigate to http://localhost:5173, take a snapshot, read the console. Fix anything that broke before reporting completion.

7

Report and wait for the next prompt

The sandbox stays live. Turn two edits the same files. HMR reloads only what changed.

What the constitution explicitly refuses to ship

A fast way to feel the contrast is to read the refusal list as a chip row. Every chip here is a default the generator will not emit unless the user asks.

No Inter on whiteNo RobotoNo ArialNo Space GroteskNo purple-to-indigo gradientNo Lucide by defaultNo Heroicons by defaultNo FontAwesome by defaultNo Lorem IpsumNo icon grid on feature cardsNo four-plus accent colorsNo dark mode unless asked

When the constitution is the wrong fit

Two cases. First, a brand that genuinely wants a pastel-gradient mood with Inter and Lucide icons should override every rule in the prompt itself. Every constraint is prefixed "unless the user explicitly overrides them," so a brief that says "use indigo-to-violet on white, Inter body, Heroicons throughout" turns the defaults off. The constitution is a starting point for taste, not a lock.

Second, a one-off static HTML file for a CMS paste should not require a sandbox, a Vite project, and a Playwright verification step. That is overbuilt. Use a snippet tool and move on. The constitution earns its weight when the HTML has to keep growing, turn after turn, without drifting into slop.

Read the rules, then write a prompt

The fastest sanity check is to open src/core/vm-claude-md.tsin the public repo and scroll to the Design Constraints heading. Then open mk0r.com in another tab, type a prompt that would normally produce slop ("build me a SaaS landing page" is a good test), and watch what the generator picks instead. With 0 colors maximum, 0 icon libraries installed by default, and 0 patterns on the anti-pattern block, the output will not look like the other twenty tabs you had open.

Want the constitution applied to your brand?

Book a 20-minute call and we will open a live session, point at your style guide, and override the rules the way a real brand would. You will see the first five minutes of generation in the browser.

Book a call

Frequently asked questions

What does 'code generator for HTML' mean inside mk0r specifically?

Type a description, an AI agent running inside an E2B sandbox writes React plus TypeScript components into a Vite project at /app, and Vite serves rendered HTML at http://localhost:5173. The preview iframe you see on mk0r.com is the live-rendered HTML output. Unlike snippet tools that paste a string into your clipboard, this generator writes into a real working project that keeps evolving with every prompt.

What is the anti-slop constitution, and where does it live?

It is the Design Constraints and Frontend Design Quality sections of /app/CLAUDE.md inside the sandbox. The source template lives at src/core/vm-claude-md.ts in the public repo, specifically lines 98 to 176 for the hard rules and lines 340 to 381 for the frontend-design skill. The agent reads both files before it writes any component code.

What is the three-colors-maximum rule and why does it exist?

Line 102 of vm-claude-md.ts reads 'Three colors maximum: black, white, and one dominant accent color.' It exists because the single most obvious AI-output tell is a palette with four to six pastel gradients on the same page. The rule caps the palette before the agent starts picking colors, which forces it to commit to one accent instead of hedging.

Does mk0r really refuse to default to Inter, Roboto, or Arial?

Yes. Line 144 reads 'Never default to Inter, Roboto, Arial, or system fonts. These are the hallmark of generic AI output.' The agent is instructed to pick a distinctive display font paired with a refined body font, loaded from Google Fonts via CDN. The rule is so strong the skill file at line 376 extends it: 'NEVER converge on common choices (Space Grotesk, for example) across generations.'

Why does the rule list include 'Never install an icon library'?

Line 115 of vm-claude-md.ts reads 'Never install an icon library (Lucide, Heroicons, FontAwesome, etc.) unless the user explicitly requests icons.' Decorative icons on feature cards and section headers are the second most obvious tell of auto-generated HTML. Killing the default at the library-install step means the agent has to earn every icon with a functional reason.

What does the Anti-Patterns block forbid explicitly?

Six patterns, lines 170 to 175: purple or indigo gradients on white backgrounds, uniform rounded cards in a grid with icons, a generic hero with centered text and a gradient button, every section looking the same with slight color variations, cookie-cutter layouts that could be any app, and placeholder images or Lorem Ipsum left in place. If you search the repo for 'Anti-Patterns' you will find this exact list.

How is the constitution actually injected into the sandbox?

At boot time, the ACP bridge copies globalClaudeMd to /root/.claude/CLAUDE.md and skillFrontendDesign to /root/.claude/skills/frontend-design/SKILL.md inside the E2B sandbox. The system prompt at DEFAULT_APP_BUILDER_SYSTEM_PROMPT in src/core/e2b.ts line 148 tells the agent to 'Read your CLAUDE.md files for detailed workflow, coding standards, and memory instructions.' The agent reads them on its first tool call.

What if I want purple gradients or a generic centered hero?

Ask for it. Every rule is prefixed 'These rules apply unless the user explicitly overrides them.' If you write 'I want an indigo to violet gradient and Inter everywhere because it matches our brand,' the agent honors the override. The constitution is a default, not a lock, so a brand that genuinely wants a pastel-gradient mood can still get it on demand.

Does this actually produce better HTML in practice?

The rules eliminate the three most obvious AI-output tells (multi-color gradient palette, Inter on white, iconified card grid) before the agent starts writing. The output still depends on the prompt and the model. But the baseline, the 'what do you get if you just type build me a landing page,' is meaningfully different from what you get from a tool with no such constraints. You can compare by running the same prompt against mk0r and a default code generator.

Can I read the full constitution without running a sandbox?

Yes. The repo is public. Open src/core/vm-claude-md.ts and scroll to the 'Design Constraints' heading. The whole rule list, the anti-patterns block, and the frontend-design skill are a few hundred lines of plain text. Nothing is hidden behind a paywall or an SDK. If you want a flat copy, run 'node -e "import(String.raw`./src/core/vm-claude-md.ts`).then(m => console.log(m.globalClaudeMd))"' from the repo root.

Do I need an account to try this?

No. Open mk0r.com and type a description. A fresh sandbox boots, the constitution is already inside it at /root/.claude/CLAUDE.md, and the agent begins writing components against the rules. No email, no card, no signup.

Type a description. A sandbox is already warming. The rule list is already inside it. No sign-in in front of either.

Generate HTML on mk0r