---

name: hallmark description: "Anti-AI-slop design skill for greenfield pages, audits, redesigns, and design extraction from URLs or screenshots. Use when the user asks to build a new app or landing page, wants to redesign something, invokes Hallmark by name, or uses audit/redesign/study." version: 1.1.0

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 (Anthropic's frontend-design 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.

| Invocation | What it does | | --- | --- | | (default) | The user asked you to design or build something new. Follow the Design flow below. | | hallmark audit <target> | Read the target, score it against the anti-pattern list, return a ranked punch list. Do not edit. | | hallmark redesign <target> [--mood <name>] | Take the target's content and intent, then redesign the visual structure inside the existing implementation boundaries unless the user explicitly confirms a full rebuild. New section rhythm, new heading placement, new component voice. Preserve existing routes, component ownership, copy intent, brand, and information architecture; replace only the visual/interaction layer needed for the requested scope. | | hallmark study <screenshot \| URL> | The user pasted or attached an image of a design they admire, or pasted a URL to a live page. Extract the DNA — macrostructure, archetypes, type-pairing, colour anchor — and produce a diagnosis report, then optionally rebuild the user's content using the extracted DNA or emit a portable design.md of the DNA. Detection is automatic: a URL (http:// / https:// prefix) routes to URL mode; anything else routes to image mode. URL mode reads the page's HTML and CSS via WebFetch — it can name exact fonts and exact colour values, but can't judge rhythm. After the diagnosis, the user has three follow-ups: build with the DNA (handoff to default), lock the DNA into a portable design.md (opt-in via "lock the DNA" / "give me a design.md"), or stop at the diagnosis. Never copies pixels. Refuses template-marketplace URLs. Tighter refusal layer for design.md emission than for the diagnosis itself — URL-mode emission requires attestation that the source is the user's own or a public reference for their own brand. Falls back to asking for a screenshot if the URL is auth-walled, a JS-only SPA shell, or otherwise un-readable. Load references/study.md before this verb runs. |

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 21 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 six 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 46.

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 48.

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 47.

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 + root overflow-x: clip on both html and body, never hidden (gate 34); no two-line clickable text — buttons, primary nav links, footer links, breadcrumbs, CTAs (gate 49); image-bearing grid tracks use minmax(0, 1fr), never bare 1fr (gate 50); display headers wrap inside long words via overflow-wrap: anywhere; min-width: 0 (gate 51); section heads collapse to one column on mobile across every theme variant (gate 52); radio-tab patterns don't scroll-jump (gate 53). See references/responsive.md § Mobile — non-negotiable. This is a hard floor, not a wish list.

6. Typography purity — no italic headers. Headings and display type are always roman (font-style: normal). An italicised emphasis word inside an otherwise-upright heading (Built to <em>think</em>) is one of the most reliable AI tells; so is an all-italic display face on headings. Carry emphasis with weight, accent colour, or a drawn underline. Italic survives only as body-copy emphasis inside running paragraphs. See references/anti-patterns.md § Italic headers and slop-test gate 38a.

---

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 40–41) / 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. N1a–N13 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 conv