跪拜 Guibai
← Back to the summary

Hallmark: A Design Skill That Shuts Down the AI-Slop Defaults in Generated Pages

Introduction

Making AI-generated pages "look human-made" is not about what you add, but what you leave out.

This is the 249th article in the "One Open Source Project a Day" series. Today's project is Hallmark (Nutlope/hallmark).

You have probably seen those pages: a small uppercase "eyebrow" line above the headline, one word in the title with a gradient, cards nested inside cards, an email capture box at the bottom, and a form whose submit button does nothing. These are not quirks of one model; they are the defaults almost every coding assistant falls into when unconstrained.

Hallmark's positioning is clear: it is a Skill that makes coding-assistant output look "designed" rather than "generated." It does not teach models aesthetics. Instead, it writes the characteristics of "machine flavor" into rules one by one, then checks them with tooling.

What you will learn

Prerequisites

Project Background

Project Overview

Hallmark is a design Skill that works with Claude Code, Codex CLI, Cursor, and OpenCode. The README summarizes it: it holds one hard baseline, then steps aside; deals three themes from 48 "materials," builds the page around what the visitor is trying to do, checks the result in a real browser against a set of rules, then hands it to a reviewer with a fresh context for a final judgment.

The "machine flavor" it checks includes:

Author and Team

Project Numbers

Data taken from GitHub on 2026-10-27, for reference only:

Main Features

Core Role

Hallmark does four things in a single page build:

  1. Preflight: reads the project's existing fonts, palette, framework, and locked design.md, and asks only once for assets it still needs
  2. Deal: draws three of 48 themes, picks one; then draws the page anatomy according to the "job" the page must do
  3. Hero first: writes only the nav and above-the-fold content, renders it, runs a fresh-context review, and only after it passes builds the rest
  4. Scan: sloplint --render checks the page at 8 widths, followed by a subagent review with fresh eyes

The output is self-contained HTML and CSS. The first CSS comment carries a "stamp" recording what decisions were made for this page.

Use Cases

  1. Generate a landing or marketing page from scratch

    • Give a one-sentence requirement, let the assistant deal and build, instead of reusing a generic template

  2. Give an existing page a health check

    • /hallmark audit ./index.html only produces a report, never modifies files

  3. Rebuild an existing page while keeping content and functionality

    • /hallmark redesign ./src/app keeps content and wiring, only swaps system and layout

  4. Add a quality gate to your team's UI output

    • Use sloplint on any page or directory by itself, and wire it into editor hooks

  5. Custom design

    • Say "custom," Hallmark abandons the theme library, keeps only the baseline and gates, and looks in your prompt for "one idea that only this client would have"

Quick Start

# Install into all projects (remove -g to only install into the current project)
npx skills add nutlope/hallmark -g

# Install for only one harness
npx skills add nutlope/hallmark -g --agent claude-code

Requires Node 18 or newer. Browser checks (sloplint --render, screenshots) need npm i -g puppeteer-core and Chrome in addition; without them, static checks still run.

Harness Install location Invocation
Claude Code ~/.claude/skills/hallmark /hallmark <prompt> or directly describe a new request
Codex CLI ~/.agents/skills/hallmark $hallmark <prompt>
Cursor reads the above copies /hallmark <prompt>
OpenCode reads the above copies /hallmark <prompt>

It can also be installed as a Claude Code plugin:

/plugin marketplace add nutlope/hallmark
/plugin install hallmark@hallmark

If it does not trigger by itself, just say: use hallmark to build ...

Check any page by itself:

node skills/hallmark/scripts/sloplint.mjs <file-or-directory> --render

Core Features

  1. 48 material themes

    • Each one is a "material" (paper, fonts, colors, surfaces, its own components, texture), with a finished-page image; each theme file is under 8 KB

  2. Build pages from the job to be done

    • A booking page is for booking, a store is for selling, a subscription page is for subscribing: the action goes where such sites normally put it, and the page closes with it

  3. Real product screenshots

    • Give it a URL, a dev server, or an app, and it screenshots the real thing instead of drawing a fake product window

  4. 755 openly licensed photos

    • Selected per theme and credited on the page; from Wikimedia Commons; not using libraries like Unsplash or Pexels whose terms forbid AI tool selection

  5. redesign and audit

    • The former rebuilds while preserving content and wiring; the latter only reports issues

  6. Three rule tiers

    • Floor can never be waived; Reflex can be waived with reason; Finish only hints and never blocks

Project Strengths

Comparison Hallmark Directly letting the assistant write the page Generic frontend templates
Convergence Dealing + log prevents adjacent builds from colliding Model defaults repeat Everyone uses the same one
Quality check Measures contrast, focus rings, above-the-fold in a browser By eye or after-the-fact feedback None
Content honesty No fabricated metrics, testimonials, logos Easily fabricated Placeholder copy
Redo safety Records every link and field first; fails if lost Easy to drop wiring Not applicable

Why it is worth a look?

Detailed Analysis

The Three Rule Tiers: Floor, Reflex, Finish

This is the skeleton of the whole project. Every gate in gates.md has a tier that determines whether you can disagree with it:

Tier Meaning Treatment
Floor No one building a page to be championed would intentionally violate these (correctness, accessibility, honesty, prohibitions), or they are Hallmark's stricter-than-industry "house rules" Never waivable; FAIL means no delivery
Reflex Defaults a model slides into on its own Can be waived with a real reason recorded; more than three waivers triggers the note "this is actually your house style, write it into design.md"
Finish Craft details invisible at arm's length Only report and answer, never block
Ledger Bookkeeping about repetition Only NOTE records, not part of the verdict

Floor contains 16 rules, for example:

Some of these are explicitly marked as "house rules": eyebrow lines (54), screen word budget (58), template punctuation (63), and letterspaced caps (67). The point is these are the most stable signals of "machine flavor," so Hallmark is stricter than the industry norm.

Waivers are written in the page's CSS stamp, with three fields: gate number, protecting evidence, reason.

/* Hallmark · waive 47b · one frame, a real terminal capture inside · the terminal is the product being sold */

A waiver request for a Floor gate is rejected and the gate fires as usual. sloplint re-derives the protecting condition, so waivers without a real reason usually fall apart on their own.

Gate numbering has a detail: retired numbers (5, 13, 14, 21, etc.) are never reused, so old stamps stay readable.

Dealing: Using a Log to Avoid Convergence

How do you keep several consecutive builds from looking the same? Hallmark's answer is dealing: 

node <skill-dir>/scripts/theme.mjs deal --genre <genre> --prompt "<prompt>" [--log .hallmark/log.json]

It deals three themes from the 48 that match the prompt and avoids themes recently used in the log. The assistant looks at the three images, picks the material that best carries this request (motion, photos, code), and states its reasoning.

After choosing the theme, draw runs:

node <skill-dir>/scripts/theme.mjs draw --material photo|product|words --job <job> --theme <slug>

It deals out the page according to its "job": the page's shape, the hero's posture, navigation, footer, first section, the placement of the action, two compositions to avoid, and what the hero leads with.

One line in the README summarizes this design: the theme is material, not a plan. Themes never dictate what the page contains or its order, so two prompts under the same theme produce two different pages.

The author added a "mirror test": would two adjacent similar prompts get the exact same combination? If so, change one decision and say which one changed.

Each build writes to .hallmark/log.json with fields like shape, theme, hero, nav, footer, photos, signature, waived, and fingerprint; the next deal avoids those.

What a Theme Looks Like

Take Dusk as an example (a financial reconciliation product). The top of a theme file is metadata:

name: Dusk
slug: dusk
genre: modern-minimal
paper: dark 17.5 268
display: grotesk-sans Wix Madefor Display
accent: cool 274
posture: committed
keywords: treasury, banking, fintech, payments, reconciliation, ledger, ...

keywords match the prompt during dealing. The prose describes the material: "money software at the end of the day". The hero sits on a real dusk land photo with the headline on the brightest part, the product window is smoked glass with a highlighted edge, and lower down the page turns slate, with light surfaces as bone-white "wells."

Below that are complete tokens (using the oklch color space) and three "knobs": two Dusk pages in the same run must differ on at least two knobs.

The 48 themes follow a similar format, from almanac, arcade, atelier to terminal, vellum, werkstatt.

Build Flow: Hero First, Then the Rest

SKILL.md splits the flow into 7 steps. Key constraints:

The "signature" rule is another interesting one: every page needs something the visitor will remember, the strongest real material from the prompt shown to its best degree, like a photo of that place, or the product doing its actual thing, shown above the fold and named in the Picks block and stamp.

Review: sloplint Plus Fresh Context

Checks happen on two layers.

sloplint is a zero-dependency script (sloplint.mjs around 230 KB, render layer sloplint-render.mjs around 99 KB) that can read HTML, CSS, framework components, and Tailwind class names. With --render, it measures inside a real browser:

For each gate it gives a tiered result: FAIL, REFLEX, WAIVED, WARN, ANSWERED, NOTE.

Fresh-context review is the second layer: a subagent that never saw the build process reads only the review prompt and the finished page, and gives its verdict as the first word (recapture, rebuild, fix, or ship). SKILL.md is explicit that "the builder never opens review-*.md," to keep builders from writing pages against the review criteria.

The builder must honestly write the result in the last line of the Picks block, e.g. Floor 0 FAIL · Reflex 2 (1 waived: 47b) · finish-review: subagent, 3 resolved. The docs say: faking a pass is itself slop.

redesign: Record First, Rebuild, Fail on Loss

redesign is the most "safety engineering" part of Hallmark. It only touches an existing design when the user asks for it by name:

/hallmark redesign ./src/app
/hallmark audit ./index.html

A full redesign preserves content and wiring, only swapping system and layout; saying keep the layout means a reskin, saying polish only fixes machine-flavor issues.

Mechanically:

Also, SKILL.md mandates: in existing projects, state which files will change before changing them; without an approved file-level plan, no route or component tree gets deleted.

Honesty of Images and Assets

Hallmark is restrained with images:

Evaluation: The Eval Directory

The repository's eval/ directory holds a test suite, including briefs.json (test prompts), run-matrix.py, judge.py, score.mjs, report.mjs, and index.html, used to generate pages across models and harnesses in batch, screenshot them, score them, and produce a report. ROADMAP admits: "run the same prompt on Claude Code, codex exec, and OpenCode, and assert all reach 0 FAIL" is still in "Now," not done.

Roadmap Items Worth Noting

ROADMAP lists the author's own judgments:

This shows the author keeps chasing the drift of "AI flavor": today's counter-pattern can become tomorrow's pattern.

Scope and Limitations

Project Address and Resources

Official Resources

Related Resources

Summary and Outlook

Key Points Recap

  1. Constraints beat prompt polishing: breaking "AI flavor" into individually checkable rules then checking with tooling is more reliable than repeatedly telling a model to "have design sense"
  2. Rules are tiered: Floor is unbreakable, Reflex can be waived with a reason and leaves a record, Finish only hints, so the system has both a bottom line and flexibility
  3. Dealing prevents convergence: 48 themes plus a log keep consecutive builds from colliding; "theme is material, not plan"
  4. Two-layer verification: sloplint measures in a real browser, then a fresh-context reviewer judges, and the builder cannot see the review criteria
  5. Redesign must provably not lose things: record every link and field first; fail if anything is lost

Who This Is For

Usage Advice

Run /hallmark audit against an existing page first, see which issues it reports, and get a sense of the rule scale; then pick a small request and go through a full build, reading the final Picks block carefully. If you have brand guidelines, lock the system in with design.md first.

Explore PrimeSkills — a curated selection of AI agents and skill tools, each validated in real workflows. No hype, only genuinely useful tools.

Visit my personal page for more insights and interesting products.

Comments

Top 1 from juejin.cn, machine-translated. The original thread is authoritative.

西索种西瓜 1 likes

The rule forbidding `transition: all` in Floor is harsh, but rightly so. Models default to writing `transition: all .3s`, animating width and height together, causing layout jitter that's hard to debug. The fake form rule is also practical: clicking submit only shows a thank-you, the request never actually fires — that's really common in landing pages. Rules divided into Floor / Reflex / Finish are more reliable than just telling the prompt to 'make it design-savvy'.