Hallmark

Hallmark

A design skill for AI coding assistants. Makes the UIs they generate look made, not generated.

Hallmark is opinionated, short, and boring on purpose. It encodes a tight set of rules — drawn from the consensus of the anti-AI-slop design field (impeccable, kami, Anthropic's frontend-design skill, taste-skill, the Claude cookbook on frontend aesthetics, and the 2026 "tactile rebellion" movement) — and refuses to let the model fall back to the defaults every LLM was trained on.

The differentiator: Hallmark insists on structural variety, not just visual variety. Two pages by Hallmark for two different briefs should not share the same hero → 3-feature → CTA → footer rhythm. They should feel like different sites, not different colour-swaps of the same template. See references/structure.md.

Powered by Together AI.

How to use this skill

Hallmark has one default behaviour and three explicit verbs.

If the user types anything that does not clearly map to audit, redesign, or study, treat it as default. If the user attaches an image or pastes a URL without a verb prefix, ask: "Should I study this (extract the DNA), or should I treat it as a reference for a fresh build?"

Implementation safety rail. Hallmark is a design skill, not a license to bulldoze a codebase. In any existing project:

• Never delete production files, route trees, component directories, or an old website unless the user explicitly asks for deletion or approves a file-level plan that lists the deletions.
• Default to in-place edits of the named files, or additive new components/tokens that are wired through the existing route. If the redesign would require removing multiple components, stop and ask for confirmation first.
• Treat PDFs, README files, .md briefs, docs, transcripts, and pitch decks as reference material. Do not copy them word-for-word into the page unless the user explicitly says to use that text verbatim.
• Before editing, state the exact files you expect to modify/create/delete. Deletions require explicit confirmation.

The default Design flow always picks a theme. By default it picks one of the 22 named themes — the catalog — and rotates among them per the diversification rule. There is also a quiet custom branch that constructs a one-off OKLCH palette + free-font pairing for the brief; the custom route fires only when the brief carries a creative-intent signal (the user names a brand colour, names a multi-attribute vibe the catalog can't carry, or explicitly asks for a custom theme). For vanilla briefs, the user never sees the words "catalog" or "custom" — the catalog runs silently. See Step 1 (signal detection) and Step 2.6 (dispatch); the protocol lives in references/custom-theme.md.

Disciplines that hold across every verb

These four disciplines are not verb-specific. They apply to default Design, audit, redesign, study, and component-scope alike. They sit alongside the slop test, not inside one branch of it.

1. Pre-emit self-critique. Before handing back any output, score it 1–5 on six axes — Philosophy, Hierarchy, Execution, Specificity, Restraint, Variety. Anything < 3 triggers a revision pass. Stamp the six scores at the top of the artifact (/* Hallmark · pre-emit critique: P5 H4 E5 S4 R5 V5 */). See references/slop-test.md § Pre-emit self-critique.

2. Honest copy — no fabricated content. If the user did not supply a metric, do not invent one. Stat-led layouts, comparison rows, and proof bars must use real numbers, a placeholder (— plus a labelled grey block, "metric to confirm"), or a different macrostructure. "+47 % conversion", "trusted by 50,000+ teams", and "10× faster" are slop the moment they're invented. Same rule for testimonials, logos, and case-study counts. See references/anti-patterns.md § Invented metrics and slop-test gate 56.

3. Locked tokens — no mid-render improvisation. Once a theme is selected at Step 2.6, every colour and every font-family declaration in the artifact must reference a named token (var(--color-accent), font-family: var(--font-display)). Inline OKLCH / hex / rgb() values, or a font-family: "Some Font" declaration that bypasses the token block, are not allowed. If a value is needed that doesn't exist as a token, lift it into the token block as a new named variable, then reference it. See references/anti-patterns.md § Mid-render token improvisation and slop-test gate 58.

4. Re-drawn chrome forbidden. Hallmark must not hand-build fake browser bars (URL pill + traffic-light dots), fake phone frames, fake code-block windows (mock title bar + dots wrapping a <pre>), or fake IDE chrome — the user's environment already supplies real chrome. Use real screenshots wrapped in a <figure> (with at most a hairline border), or omit the chrome and let the content stand on its own. See references/anti-patterns.md § Re-drawn UI chrome and slop-test gate 57.

5. Mobile responsiveness — every emit verified at 320 / 375 / 414 / 768 px. Hallmark's output must render flawlessly at all four widths. The non-negotiables: no horizontal scroll (gate 36), no two-line clickable text — buttons, primary nav links, footer links, breadcrumbs, CTAs (gate 59); image-bearing grid tracks use minmax(0, 1fr), never bare 1fr (gate 61); root has overflow-x: clip on both html and body — never hidden (gate 62); display headers wrap inside long words via overflow-wrap: anywhere; min-width: 0 (gate 63); section heads collapse to one column on mobile across every theme variant (gate 64); radio-tab patterns don't scroll-jump (gate 65). See references/responsive.md § Mobile — non-negotiable. This is a hard floor, not a wish list.

When the brief is a component, not a page

Before entering the full Design flow, check scope. If any of these fire, run the Component-scope flow instead — most day-to-day dev requests are component-shaped, not page-shaped, and the page-level apparatus (macrostructure, hero enrichment, footer archetype, project memory) is wrong for them.

Component-scope signals:

• The brief names a single UI element: a button · an input · a card · a modal · a dropdown · a tooltip · a select · a checkbox · a switch · a tab strip · a chip · a badge · a banner · a snackbar · a popover · a slider · a date picker · an avatar.
• The brief is short (≤ 30 words) and refers to one element.
• The target file is a single component (e.g., ./Button.tsx, ./components/Input.css, app/components/Card.vue).
• The user explicitly says "just the X", "only the Y", "this one element", "a single ___".

If two signals fire, route component. If only the page flow fires (multi-section brief, "build me a landing page"), stay in Design flow.

What Component-scope keeps from the page flow

• Step 0 · Pre-flight scan — same. Read existing tokens, fonts, framework, microinteraction stance. A button on a Geist-bodied Tailwind project must adopt those tokens, not invent new ones.
• Step 1 · Genre detection — same. Editorial / modern-minimal / atmospheric / playful. The component inherits its surroundings' genre (silent default to editorial when unknown).
• Step 2.6 · Theme route — same. If a tokens.css or design.md exists, the component uses those tokens. Otherwise it asks "is there a system to follow, or should I pick one?" — defaulting to catalog if the user is silent.
• 2+1 font discipline — same.
• State discipline — STRICTER. Every interactive component MUST ship code for all 8 states: default · hover · :focus-visible · :active · disabled · loading · error · success. The 8-state checklist in interaction-and-states.md is mandatory, not advisory.
• Slop test — universal-only subset. Run the visual / microinteraction / contrast (gates 46–50) / a11y / typography gates. Skip the diversification gates (no .hallmark/log.json entry — components don't rotate) and skip the layout-safety gates that assume a full page.

What Component-scope skips

• Step 2 · Macrostructure pick. Components don't have macrostructures. State this explicitly: "Component-scope: skipping macrostructure."
• Nav and footer archetype picks. N1–N9 and Ft1–Ft8 are page-scope only. A component is one element; it has no nav, no footer. Skip both.
• Hero polish patterns (HP1–HP4). Page-scope only. A button or card has no hero.
• Step 4 · Enrichment. No hero illustration, no demo video, no abstract background. The component IS the artifact.
• Step 5 · Multi-section preview. Replaced by the 8-state demo wrapper (below).
• Project-memory append. No .hallmark/log.json entry for component runs. The diversification rule doesn't apply.

What Component-scope emits

Two files, side by side:

1. The component artifact — a single self-contained file matching the project's conventions:

   • React / Vue / Svelte: Button.tsx / Button.vue / Button.svelte
   • Vanilla web: button.css + button.html
   • Tailwind: a .tsx with className chains AND a tokens.css if missing
   • The component consumes Hallmark tokens by name (var(--color-accent)), never inlines OKLCH values.

2. An 8-state demo wrapper — <ComponentName>.preview.html (or .preview.tsx). A small standalone page that renders the component in all 8 states stacked vertically, each labelled. The user opens it once, sees the component working, then deletes it. The wrapper is not part of production code. Format:

   ┌──── Button — 8 states ────────────────────────┐
   │                                                │
   │ default       [ Click me                  ]    │
   │ hover         [ Click me                  ]    │  ← .is-hover forces :hover styling
   │ focus         [ Click me                  ]    │  ← .is-focus forces :focus-visible
   │ active        [ Click me                  ]    │  ← .is-active forces :active
   │ disabled      [ Click me                  ]    │  ← disabled attr
   │ loading       [ ⌛ Working…                ]    │  ← data-state="loading"
   │ error         [ ⚠ Try again               ]    │  ← data-state="error"
   │ success       [ ✓ Saved                   ]    │  ← data-state="success"
   │                                                │
   └────────────────────────────────────────────────┘
   

   Each labelled row uses a class (e.g. .is-hover) that the component's CSS targets in addition to the real pseudo-class, so all 8 states render at once on the demo page. Example:

   .btn:hover, .btn.is-hover { background: var(--color-paper-3); }
   .btn:focus-visible, .btn.is-focus { outline: 2px solid var(--color-focus); }
   .btn:active, .btn.is-active { transform: translateY(1px); }
   

Stamp format for component output

Components stamp differently from pages:

/* Hallmark · component: <type> · genre: <genre> · theme: <theme>
 * states: default · hover · focus · active · disabled · loading · error · success
 * contrast: pass (46–50)
 */

The component: prefix tells future Hallmark runs this artifact is component-scoped and shouldn't trigger page-level diversification rules. The states: line is a checklist — every state listed must have actual styling in the file.

When in doubt — ask once

If the brief is ambiguous between component and page (e.g. "design a pricing section" — could be one card, could be a whole page), ask one short question: "One pricing card, or the whole pricing page?" Default to component if the user doesn't engage — single-artifact output is cheaper to redirect than a multi-section page.

Design flow (default)

0. Pre-flight scan

If the project already has code — a package.json, a tailwind.config.*, an index.html, any CSS — Hallmark should read it before asking the user anything. Stomping on an established palette or font stack is the difference between a skill the user keeps and a skill the user uninstalls.

Six signal sources, scanned in order:

0. design.md — at the project root (or DESIGN.md). If present, this is the locked design system for the project — written by a previous hallmark redesign run on the whole app, or by hand. Read it first; it overrides everything else. Subsequent picks (genre, theme, type, motion) defer to it. The diversification rule is inverted on design.md-managed projects: pages must share the system, not differ from each other. See verbs/redesign.md § Multi-page flow for how the file is produced and amended.
1. Font stack — package.json for next/font, @fontsource/*, expo-google-fonts, geist; any <link rel="stylesheet" href="...fonts.googleapis.com/..."> in HTML / layout files; tailwind.config.{js,ts} theme.extend.fontFamily; @import url("fonts.googleapis.com/...") in any stylesheet.
2. Palette — OKLCH / HSL / hex values inside :root blocks; tailwind.config theme.extend.colors; any tokens.json, design-tokens.{json,yaml}, or DTCG-shaped file.
3. Microinteraction stance — package.json dependencies for framer-motion, gsap, motion, lenis, lottie-react, @react-spring/*, auto-animate. Any one of those = "motion-on" project. None = "motion-cut" project.
4. Spacing scale — Tailwind theme.extend.spacing; CSS --space-* custom-property pattern; presence of a 4-pt or 8-pt scale.
5. Framework — Next.js (next in deps), Astro (astro), Vue (vue), Svelte / SvelteKit (svelte / @sveltejs/kit), Remix (@remix-run/*), or vanilla HTML.

Output format — emit this block once, before Step 1, with file:line citations so the user can verify what you found:

Pre-flight findings:
· Font stack: Geist + Geist Mono (next/font, package.json L23)
· Palette: OKLCH custom properties (app/globals.css :root)
· Motion: framer-motion 11 installed (package.json L41)
· Spacing: Tailwind extend.spacing (4-pt scale, tailwind.config.ts L18)
· Framework: Next.js 15 (app router)

Hallmark will preserve: font stack, palette, spacing scale.
Hallmark will introduce: macrostructure, microinteraction discipline,
slop-test gates, hero enrichment recipe.

If you want Hallmark to override any preserved item, say so.

Persistence. Write the findings to .hallmark/preflight.json once. On subsequent runs, re-use the cached findings unless either:

• the user says "refresh pre-flight" (or "scan again", "re-scan"), or
• package.json / tailwind.config.* mtimes are newer than preflight.json.

If the cache is re-used, emit a one-line note instead of the full block: "Pre-flight cached (last scan: 2026-04-30). Say 'refresh pre-flight' to re-scan."

Edge cases:

• design.md found → emit "design.md detected at project root — this is a system-managed project. Reading the locked design system; subsequent picks defer to it." Then read the file in full and use it as the source of truth for genre / theme / typography / spacing / motion / CTA voice. Skip Step 1's catalog/custom dispatch; the system is already chosen. Proceed to macrostructure pick (Step 2) within the family design.md allows for this page's type.
• No signals found (vanilla HTML project, empty repo, scratch directory) → silent. One line only: "No pre-flight signals — proceeding with full Hallmark stack."
• Conflicting signals (e.g. framer-motion installed but no motion.div usage anywhere; or Geist import in package.json but font-family: Inter hard-coded in CSS) → flag the conflict explicitly: "Conflict: Geist imported via next/font but a hard-coded font-family: Inter in app/globals.css L4. I'll preserve next/font Geist; please confirm or remove the Inter declaration."
• Empty project (no package.json, no index.html) → silent.
• The user said "ignore the existing project" → skip pre-flight entirely; emit "Pre-flight skipped at user request." and proceed to Step 1.

Two more sample outputs for the model to imitate:

Vanilla HTML project, motion-cut:

Pre-flight findings: vanilla HTML, no framework detected. No motion library, no Tailwind, no design tokens. Hallmark will introduce: full token system, macrostructure, microinteraction discipline, slop-test gates. Nothing to preserve.

Astro + Tailwind + DTCG tokens already present:

Pre-flight findings: Astro 5 (astro.config.mjs L1) · Tailwind v4 with @theme inline tokens (src/styles/global.css L3) · tokens.json at project root (DTCG format, 12 colour tokens, 6 font tokens). No motion library detected. Hallmark will preserve: Tailwind tokens, the tokens.json file (won't overwrite). Hallmark will introduce: macrostructure, microinteraction discipline, slop-test gates. Motion stance: motion-cut (no framer-motion / motion / gsap detected).

The pre-flight block is the user's accountability line: "here's what I noticed about your project before I touched anything." Skipping it is the fastest way to lose the user's trust.

1. Design-context gate

Hallmark works best when you know three things before writing code:

1. Audience. Who will use this? What do they already know?
2. Use case. What single job does this interface do? What is the one action the user should be able to take?
3. Tone. Pick an extreme — editorial, brutalist, soft, utilitarian, luxury, playful, technical, austere. "Clean and modern" is not a tone.

Always ask — answering is optional. Hallmark always asks before it designs. The bundled question is the first thing the user sees after the pre-flight block. Even on a five-word brief — "design a podcast site", "build a SaaS landing", "make me a portfolio" — ask. Especially on those briefs, since they're where the model is most tempted to invent.

The prompt format:

Before I build, I need three things:

1. Audience — Who will use this? What do they care about? 2. Use case — What's the one action the page should drive? (Sign up? Subscribe? Read? Buy?) 3. Tone — Pick an extreme: editorial · brutalist · soft · utilitarian · luxury · playful · technical · austere. "Clean and modern" isn't a tone.

Or say "go ahead" and I'll infer from the brief — I'll tell you what I picked.

Send the prompt once, in one message. Bold the three labels (Audience / Use case / Tone) so the user can scan them. Do not ladder follow-ups; if the user answers some fields and skips others, treat the skipped fields as opt-out and infer them. If the user says "go ahead", "you pick", "just build it", "don't ask", or doesn't engage after one prompt, the inference protocol below kicks in.

One exception where the gate is silent:

• The skill is invoked with audit, study, or redesign --mood — those verbs read context from the target, not the user.

There is no "the brief looks complete" exception. There is no "the user already named all three" exception. There is no length threshold below which asking is skipped. A long, detailed brief gets the same three-question prompt as a five-word one — the user can wave you through with "go ahead" in two seconds. Default is to ask. The cost of asking is one extra message; the cost of guessing wrong is a whole rebuild.

Genre — pick before themes. Before the theme route, settle on a genre. Hallmark ships four: editorial (default · the canonical anti-slop voice), modern-minimal (Stripe / Linear / ElevenLabs school), atmospheric (Suno / Runway / dark-AI-tool school), playful (post-Linear soft school). The genre scopes which themes can rotate, which slop-test gates apply, and which voice fixtures the LLM picks from. Detection is signal-based — silent default to editorial unless the brief fires one of these:

• AI tool, generative, music, video, voice, late-night, dark mode, atmospheric → atmospheric → load references/genres/atmospheric.md
• SaaS, enterprise, API, platform, developer tool, infra, B2B, dev experience → modern-minimal → load references/genres/modern-minimal.md
• fun, consumer, casual, friendly, onboarding, family, community → playful → load references/genres/playful.md

If two non-default signals fire (rare), ask one short follow-up: "This brief fits both modern-minimal and atmospheric — which feels closer? [modern-minimal · atmospheric]". Default with no signal: silent editorial → load references/genres/editorial.md. The chosen genre file is loaded eagerly (it scopes everything downstream); other genre files stay on disk.

State the genre out loud at Step 2.5 alongside the macrostructure and theme picks: "Genre: atmospheric. Macrostructure: Marquee Hero. Theme: Bloom (atmospheric cluster)."

Theme route — only surface when the brief signals it. Hallmark has two theme routes: catalog (the 22 named themes — Specimen, Atelier, Brutal, Salon, Newsprint, Linen, Studio, Manifesto, Terminal, Midnight, Almanac, Garden, Quiet, Riso, Sport, Bloom, Coral, Violet, Aurora, Halo, Plume, Editorial) and custom (an OKLCH palette + free-font pairing tuned to this one brief). Catalog is the default. The catalog rotation is scoped to the genre's theme cluster — atmospheric rotates Bloom/Midnight/Terminal, modern-minimal stays on Quiet, playful stays on Plume, editorial walks the remaining twelve. Do not offer the user a choice on every prompt — that's friction, not discipline. Surface the catalog/custom fork only when the brief carries one of these signals:

• The user explicitly says custom theme / tailored to our brand / make it ours / something unique / play with the colors and fonts.
• The user names a specific brand colour as the anchor (e.g., "use our terracotta", "the brand red is hex #c0392b", "anchor on sea-blue").
• The user describes a multi-attribute aesthetic that doesn't map to a single catalog theme — three or more vibe words pointing at a specific feel (e.g., "moss, lichen, soft pink, herbal" / "sun-drenched, market-day, carbon-black" / "late-night, neon, brutalist deli"). One adjective ("warm", "technical", "playful") is not a custom signal — that's a tone, and the catalog already carries it.
• The user attaches a brand-mood reference (a colour swatch, a moodboard, a Pantone chip) without asking to study a screenshot.

If any of those fires, ask one short follow-up before picking: "This brief reads like a custom palette would fit better than the catalog. Want me to construct a custom OKLCH palette + free-font pairing tuned to , or stay on the catalog for variety + speed?" Wait for the user to say custom (or catalog). Default is still catalog — silence routes to catalog, not custom.

If none of the signals fires, proceed with catalog silently. Do not mention the fork. Most briefs don't need a custom theme — the catalog's 22 themes plus the rotation rule already deliver structural variety. See Step 2.6 for the dispatch.

If the user opts out or skips fields (says "go ahead", "you pick", "skip", "just build it", "don't ask", answers some fields and leaves others blank, or simply doesn't engage with the question after one prompt):

• Infer audience, use case, and tone from the brief, the domain, and any visible context (filename, framework, surrounding code is fair game now — only because the user delegated).
• State the inferences in one sentence at the top of your reply — "Going with: audience = X · use = Y · tone = Z. If any of those is wrong, tell me and I'll redirect."
• Stamp them in the CSS comment alongside the macrostructure (Step 4 below). The stamp is now the durable record.
• Pick a non-default macrostructure — Specimen-fall-through is still banned, even on inferred briefs.

Do not skip the inference disclosure. The opt-out is a courtesy to lazy users, not an excuse for the skill to be opaque. If the user can't see what was inferred, they can't redirect when it's wrong.

Once the three are settled (asked or inferred), restate them in one sentence and proceed.

2. Pick a macrostructure FIRST

Before loading any visual ruleset, read the slim index at references/macrostructures.md and pick one of the twenty-one named macrostructures. The index is one-line-per-macro; pick a name, then load ONLY that one per-macro file from references/macrostructures/ (e.g. references/macrostructures/05-workbench.md). Do not load the whole catalogue — that's ~37 KB of dead weight for a single pick. Each macrostructure is a complete page-shape — heading placement, body composition, divider language, button voice, image treatment, reveal — bundled as a single named choice. Picking one named macrostructure is faster and more varied than choosing six independent axes from scratch.

Diversification rule (mandatory). Before you pick:

1. Look in the target codebase for an existing /* Hallmark · macrostructure: <name> · ... */ stamp at the top of any CSS file. If you find one, your pick must be a different macrostructure.
2. If you have produced any other Hallmark output for this user in this session, your pick must be a different macrostructure than the last one.
3. The Specimen macrostructure (numbered left-margin labels + huge serif + asymmetric spans + typographic CTA) is no longer a default. Reach for it only when the brief is explicitly editorial, foundry-adjacent, or the user has named it.

Theme-diversification rule (mandatory). Picking a different macrostructure isn't enough on its own — two consecutive Hallmark outputs can share a theme even if their structures differ, and the result reads as repetition. Two consecutive themes must differ on at least one of three axes:

• Paper band — dark (L < 30 %) / mid (30–85 %) / light (> 85 %), per the theme's --color-paper lightness
• Display style — italic-serif (Specimen, Studio, Atelier) / roman-serif (Newsprint, Salon, Linen) / geometric-sans (Plume, Manifesto) / mono (Terminal) / display-condensed-italic (Sport) / display-heavy (Brutal) / system-native (Quiet) / risograph-bold (Riso)
• Accent hue — warm (red / orange / amber: 10–60°) / cool (blue / indigo / cyan: 200–300°) / neutral (no chromatic accent: Quiet) / chromatic-other (green: Studio · sage: Garden · phosphor: Terminal)

If the previous output was Specimen (light · italic-serif · warm), the next can be Studio (light · italic-serif · chromatic-green) — the accent hue differs. But the next can't be Salon (light · roman-serif · warm) which only differs on display style and shares both paper band and accent — pick a more distant theme.

The per-theme axis values live as comments at the top of each theme's tokens block in site/css/tokens.css. When in doubt, name your candidate theme out loud and identify its three axis values; if two of three match the previous output, redirect.

State your pick. Before writing any code, say "Macrostructure: . Theme: . Differs from the last on: ." in plain text. This is a deliberate accountability step — picking on the page (not in your head) prevents the default-attractor sameness that kept the skill emitting Specimen output.

If the brief is genuinely vague (no theme, no tone), do not default. Offer the user three macrostructures from categorically different groups (e.g. one grid-led like Bento, one document-led like Long Document, one poster-led like Manifesto). Three concrete choices, not seven abstract tones.

The macrostructure picks five of the six structural axes for you; you only need to pick the reveal yourself. The deeper axis catalogue is still in references/structure.md when you need to deviate from the macrostructure's defaults.

Pick a nav archetype (N1–N10) and a footer archetype (Ft1–Ft8) at this step. They are not optional chrome; they are part of the page's structural fingerprint. Read the slim index at references/component-cookbook.md and the routing tables at its bottom — the genre's default plus the acceptable alternates. Then load ONLY the picked archetype files from references/components/ (e.g. components/n5-floating-pill.md + components/ft5-statement.md). A typical build loads 5–7 archetype files total (1 hero + 1 section head + 1–2 features + 1 CTA + 1 footer + 1 nav). Do not load the cookbook end-to-end — that's ~55 KB of archetypes you won't use. State both picks alongside the macrostructure: "Macrostructure: Marquee Hero. Nav: N5 Floating pill. Footer: Ft5 Statement. Theme: Bloom."

Default away from N1 and Ft3. N1 (wordmark + 4–5 inline links + button-right at full width) and Ft3 (4 columns of links + social row + tiny copyright) are the most-recognised AI fingerprints. Reach for N5–N9 and Ft1/Ft2/Ft4/Ft5/Ft6/Ft7/Ft8 by default; reach for N1 only when the page genuinely has 2 destinations and the genre allows it; reach for Ft3 only on a genuine docs root or hub.

Diversification extends to nav + footer. Across consecutive Hallmark runs in the same project session (per .hallmark/log.json), no two outputs should share the same nav archetype OR the same footer archetype. If the previous run used N5 + Ft5, the next picks N6/N7/N8/N9 + Ft1/Ft2/Ft4/Ft6/Ft7/Ft8 from the routing tables. The nav and footer picks are recorded in the macrostructure stamp at Step 6.

2.5. Check project memory

If the project has a .hallmark/log.json file (created by previous Hallmark runs), read it before picking the macrostructure or theme. The schema is a JSON array, newest entry first:

[
  { "date": "2026-04-30", "macrostructure": "Bento Grid",   "theme": "Linen",   "enrichment": "E1 clipped-edge",  "brief": "Tracejam · SaaS observability" },
  { "date": "2026-04-28", "macrostructure": "Long Document","theme": "Linen",   "enrichment": "E5 hand-built SVG", "brief": "Maple Street Bread · bakery" },
  { "date": "2026-04-25", "macrostructure": "Manifesto",    "theme": "Manifesto","enrichment": "none",            "brief": "Meridian · studio manifesto" }
]

Use the last 3–5 entries to inform diversification:

• Your macrostructure pick must not match any of the last three.
• Your theme pick must differ from the last on at least one axis (see the theme-diversification rule above).
• Your enrichment pick should not be the same enrichment archetype as the last (E1 clipped twice in a row reads as templated, even with different content).

If the file doesn't exist, this is the first Hallmark run for this project — no constraint, but you'll create the file in Step 6.

If the project has a CSS stamp but no log.json, infer one entry from the stamp and proceed.

State the rotation in plain text before picking. This is the user's accountability line for diversification — picking on the page (not in your head) is what keeps the skill from drifting back into Bento-Grid-by-default. The format:

"Last 5 builds: Bento Grid (Tracejam) · Bento Grid (Foundry) · Long Document (Maple) · Manifesto (Meridian) · Quote-Led (Tide). Bento Grid used 2 of 5 — picking from {Marquee Hero, Stat-Led, Workbench, Letter} this time. I'll go with Marquee Hero."

Then the theme rotation, on the next line:

"Last 3 themes: Linen · Plain · Salon. Picking from {Newsprint, Atelier, Studio, Garden} — Newsprint differs on display style and accent hue."

Three sample shapes to imitate:

• First-time (no log.json, fresh project): no rotation block at all — just the macrostructure pick. "This is the first Hallmark run for this project. Picking Long Document — fits the Coffeebox brief's editorial tone."
• Mature project (5+ entries in log.json): the format above — frequency count, exclusion list, pick.
• User overrode last run ("use Bento Grid again, I want the same shape"): "Last build was Bento Grid (you requested it). You've asked for it again — I'll pick different knob values. Knob deltas: tiles=8 (was 6), accent=full-bleed (was corner-only), spans=irregular (was even). Same archetype, different fingerprint."

The rotation block keeps the user inside the discipline without making them read the rules. Skip it and the user starts thinking the diversification is theatre.

2.6. Theme route — studied-DNA, catalog, or custom

By the time you reach this step, one of four things is true:

0. A study diagnosis was emitted earlier in this conversation and the user is asking to build from it (phrases: "build it", "make it", "use this DNA", "build with this" — immediately following the diagnosis) → theme route is studied-DNA. Skip catalog/custom dispatch entirely. The studied paper OKLCH, accent OKLCH, type roles (with named candidates), macrostructure, and nav/footer archetypes from the diagnosis become the locked system for this build. Diversification is suspended — you're following an external DNA, not rotating the catalog. The Step 6 stamp records theme: studied-DNA (source: <URL or image>) plus the actual OKLCH/font values inline. *If the user later pivots with phrases like "use Linen instead" / "ignore the DNA" / "rotate to a different theme",* route back to the normal dispatch below and resume diversification. Continue to Step 3.
1. The user named custom (because they said so, or because Step 1's signal detection fired and they confirmed) → load references/custom-theme.md, ask the one follow-up (vibe in 4–8 words + optional anchor colour), construct the OKLCH palette + free-font pairing, compute the three axis values (paper-band / display-style / accent-hue), then continue to Step 3.
2. The user named catalog (or implicitly accepted it by not naming custom) → pick one of the 22 named themes per the diversification rule above. Existing flow — continue to Step 3.
3. Neither was discussed (Step 1's signals didn't fire — vanilla brief) → default to catalog. Do not pause. Do not ask. Continue to Step 3.

Custom is a quiet branch, not a default question. Most briefs route to catalog and the user never sees the words "catalog" or "custom." The 22 named themes plus the rotation rule already deliver structural variety; the fork is reserved for when the brief specifically asks for a tuned look the catalog can't carry.

A custom theme is a complete OKLCH palette + font pairing tuned to the brief — not a one-off colour swap, not an excuse to bypass the rules. Every constraint in color.md, typography.md, and anti-patterns.md still applies. The 65 slop-test gates fire unchanged. The Step 5 preview block surfaces the palette + pairing in plain text before any code is emitted, so the user can redirect.

The diversification rule is theme-route-blind: a custom run that follows another custom (or a catalog) must differ on at least one of the three axes from the previous entry, same as catalog-vs-catalog. Custom entries record their three axes explicitly into .hallmark/log.json (see custom-theme.md § F).

3. Load the visual ruleset

The non-negotiables live in references/. Be precise about what to load when. Discipline matters — over-eager loading is the largest avoidable cost of running Hallmark.

Always-load (eager — 1 file):

• The genre file picked in Step 1 — genres/editorial.md, genres/modern-minimal.md, genres/atmospheric.md, or genres/playful.md. Scopes everything downstream.

Index-then-pick (read the slim index, then load only the picks):

• macrostructures.md — slim index of the 21 macros. Pick one name from the index, then load ONLY references/macrostructures/<NN-slug>.md for that pick. Never load the whole index plus more than one per-macro file in a single build. ~30 lines per per-macro file vs. 660 lines for the old monolith.
• component-cookbook.md — slim index of 46 component archetypes (9 heroes, 5 section heads, 6 features, 4 CTAs, 4 testimonials, 8 footers, 10 navs) + the nav + footer routing tables at the bottom. Pick your archetype codes (H#, S#, F#, C#, T#, Ft#, N#) from the index, then load ONLY the matching references/components/<code>-<slug>.md files. A typical build loads 5–7 archetype files. Loading the cookbook end-to-end or pre-loading more than one archetype per category is the single biggest token waste in the skill — don't.

Load-per-build (universal rules — load every build):

• typography.md — fonts, scale, pairing, weights, measure, hero headline sizing
• color.md — OKLCH, palette construction, accent discipline
• layout-and-space.md — 4 pt scale, grid-breaks, asymmetry, depth
• motion.md — durations, easings, what to animate, reduced-motion
• copy.md — verbs, labels, error structure, link text
• anti-patterns.md — the named tells you must not emit

Load-conditionally (only when the page actually needs it — be honest, do not pre-load "for safety"):

• microinteractions.md — load whenever the ou

…(truncated)