Is Hallmark free, and how do its license and updates work?

Hallmark's official GitHub repository currently uses the MIT License. Its README provides an npx installation command and says you can run it again to update. Before updating, you should still review the repository and file diff to make sure new rules will not override your project's existing constraints.

How should I evaluate Hallmark's output instead of judging only the hero screenshot?

Start by checking whether Hallmark's own rules pass, then test with real copy, long strings, and empty, error, and loading states. Next, check narrow screens, keyboard operation, contrast, and reduced motion, and personally complete one core product task.

Can I use Hallmark study to copy a website I like?

You should not use it for pixel-by-pixel copying. The official skill positions study as a way to extract macrostructure, font pairings, and color anchors, and explicitly rejects pixel clones and paid templates. You remain responsible for asset licensing and sufficient brand differentiation.

Hallmark Design Skill Guide: Avoid AI Slop UI Without Mistaking Rules for Taste

AI coding agents can build a landing page quickly. The problem is that the results often look as though they live in the same apartment block: a centered headline, a glowing gradient, three feature cards, and a pill-shaped button to finish it off. Hallmark tries to break that default with an installable design skill. To be clear, we did not install Hallmark in the project used for this article, nor did we run an A/B test with the same brief. What we can verify here is the official rule set and workflow, not a promise that installation instantly gives an agent a designer's taste.

TL;DR

Hallmark is a design guardrail, not a taste API. It can constrain common defaults, but it cannot supply product context, real content, or brand judgment.
For a new page with references, try study → lock the brief → build. For an existing page, start with audit, then decide between targeted fixes and redesign.
The official materials currently list 21 named themes and 57 slop-test gates, but passing the gates does not mean usability, accessibility, or the core task also passes.

First, diagnose why your AI UI looks generated at a glance

The problem usually goes beyond purple gradients. If a brief says only, "Build me a beautiful SaaS homepage," without specifying the target user, real copy, brand constraints, or required states, the agent has little choice but to select a safe answer from a set of high-probability combinations. Anthropic's frontend aesthetics cookbook likewise constrains output with more specific instructions for typography, color, motion, and backgrounds.

A practical diagnosis for AI slop UI: first identify the product information missing from the brief, then look for visual habits on the screen. Removing the gradient or card grid without adding a clear content hierarchy usually replaces one template with another.

Fill out this gap table before you start:

Brief field	What to provide	What happens if you omit it
Target user	Who uses it, and in what context	Tone and density lose focus
Core task	What the user needs to accomplish on this page	The hero becomes nothing but a slogan
Real copy	Headings, features, limitations, and error messages	The layout works only with placeholder text
Brand constraints	Fonts, colors, and prohibited styles	The agent falls back to generic aesthetics
Required states	loading, empty, error, success	A pretty screenshot cannot ship
References	Two or three directions and why you like them	The agent can only imitate vague adjectives

What Hallmark is, and what it cannot guarantee

What is Hallmark? Hallmark is the open-source design skill at nutlope/hallmark. Its official README positions it for use with Claude Code, Cursor, and Codex, under the MIT License. It brings building, auditing, redesigning, and reference analysis into one rule set.

Verifiable from official materials	Not currently guaranteed by public evidence
Four operations and installation paths exist	The result will always look more professional than your existing process
Themes, structural rules, and slop gates are included	Users will complete tasks more successfully
study rejects pixel clones and paid templates	Every agent will load and apply the skill in the same way
audit returns only a punch list and does not edit	Conversion or satisfaction will improve

The official homepage shows outputs from several different briefs. That demonstrates the range of structures the author is aiming for, but it is not an independent usability benchmark. The most reasonable expectation is that Hallmark raises the starting point. Product content, your design system, and human acceptance testing still own the last mile.

Install safely and confirm activation in a small trial

As of July 20, 2026, the official README provides this installation command:

npx skills add nutlope/hallmark

The README also lists manual locations: ~/.claude/skills/hallmark/ for Claude Code, .cursor/rules/hallmark.mdc for Cursor, and either the personal-level ~/.codex/skills/hallmark/ or project-level .codex/skills/hallmark/ for Codex. These are the official instructions at that time and may change, so check the original repository before running them.

Do not make your primary product the first test. Create a test branch, choose a noncritical page, and save both a visual baseline and a Git baseline. After installation, give it an explicit task such as, "Use hallmark audit to audit this page. Do not modify any files." Then check three things: whether the response recognizes the verb, whether it cites Hallmark's rules, and whether git diff respects the "audit does not edit" boundary.

We have not verified the actual loading messages across different agents, versions, and plans, and we will not guess at model usage or completion time. Evidence that the skill is active should come from your own output and diff, not from a successful installation message.

A decision tree for the four modes: build, audit, redesign, and study

Start with three questions: Does the page already exist? Can its structure change? Do you have usable references?

Situation	Choice	Scope of change
Building a new UI from scratch	default build	Select a structure and theme, then generate a new UI
An existing page where you only want to find problems	`audit`	Return a prioritized punch list without editing
Existing content whose visual structure may change	`redesign`	Preserve copy, information architecture, and brand intent
A screenshot or URL is available	`study`	Extract structure, font pairings, and color anchors

Which mode should you use for a half-finished UI? If you do not yet know what is wrong, start with audit. If the punch list shows only spacing, type hierarchy, and incomplete states, make targeted fixes. Move to redesign only when the structural rhythm truly fails and you accept a larger diff.

For example, suppose a side-project landing page already has a working form and analytics. Going straight to redesign may disturb interactions that already work. An audit separates "the text hierarchy is unclear" from "the entire information architecture needs rearranging," which is much safer than asking to "make everything look premium."

A low-rework SOP: use study to lock the direction, then build and audit

The following workflow is our recommendation based on the official verbs and a reference-first approach. It is not an official Hallmark claim about quantified savings:

Prepare real content: include at least the actual headline, primary CTA, feature limitations, and error messages.
Choose references: explain whether you like the information density, typographic rhythm, or color. Do not stop at "make it feel like this."
Run study: extract the design DNA, reject pixel-by-pixel copying, and do not reuse unlicensed assets.
Lock the brief: confirm the routes, components, copy intent, brand, and information architecture that must remain.
Run build: let the agent generate the page within known boundaries, reviewing the diff file by file.
Run audit: turn the result into a punch list, then have a person approve each change.

The point of this order is not that study will definitely save tokens, because no public comparative data currently supports that claim. It reduces decision ambiguity. Decide what the house is for and how it should be laid out before choosing the walls, so you do not finish construction only to discover that the kitchen has no door.

Do not let anti-slop become a new template

Rejecting the same bad habits can easily create another set of shared habits. Everyone avoids purple gradients today, then reaches for the same editorial type, oversized headings, and offset grids tomorrow. Hallmark's theme catalog offers a starting point, but it does not know why your brand exists.

Record the choices that prove useful during the trial in your project's own DESIGN.md:

type scale and permitted font weights
spacing tokens and maximum content width
color anchors, contrast, and prohibited colors
component ownership and eight interaction states
brand voice, realistic data lengths, and prohibited patterns

Hallmark should follow this project language rather than overwrite it. External guardrails can already help with a one-off campaign page. For a product that must be maintained for years, your own tokens, components, and states are the assets that compound.

How to choose among Hallmark, Anthropic prompts, taste-skill, and your own DESIGN.md

Approach	Best suited to	Main trade-off
Hallmark	Managing new builds, audits, redesigns, and studies with four verbs	Comprehensive rules, but you must resolve their priority against existing standards
Anthropic cookbook	Improving a single prompt without installing a skill	Lightweight, but not a complete audit workflow
taste-skill	Landing pages, portfolios, and redesigns	Its official scope explicitly excludes dashboards, data tables, and multistep UI
Your own DESIGN.md / design system	Long-lived branded products and team collaboration	Slower to organize upfront, with more controllable consistency later

This is not a quality ranking because there is no independent A/B test using the same brief. If you need a one-page campaign site tonight, trial the cookbook or Hallmark. If the product already has a complete component library, improve your own documentation first and treat Hallmark as an audit adviser.

57 gates do not equal usability: build a two-layer acceptance matrix

The official README currently states that Hallmark has 57 slop-test gates. That number represents the coverage of Hallmark's own rules, not accessibility, conversion, task completion, or satisfaction. A polished hero is particularly weak evidence because it avoids the least attractive moments of a real product.

Test layer	What you must test	Passing criteria
Hallmark rule layer	anti-patterns, tokens, structure, self-checks	A person has addressed the audit punch list
Content states	real copy, long strings, empty, error, loading	Key information is not truncated, and each state is understandable
Viewport	320, 375, 414, 768 px, and desktop	No horizontal scrolling, and the core action remains visible
Interaction	keyboard, focus, disabled, reduced motion	The flow can be completed without a mouse
User task	Complete one real core task	The task succeeds, recovery is possible, and errors offer a way forward

Hallmark's own skill currently requires output to be verified at several narrow screen widths, which is a useful baseline. But code that declares itself verified does not mean you have actually viewed it in the target browsers with real content. A person still needs to perform that final click.

High-risk territory: do not let Hallmark take over these projects

The following are conservative stop conditions for adoption, not blanket exclusions officially listed by Hallmark:

an established design system with strict brand standards
dashboards, data tables, or information-dense admin interfaces
multistep payment, application, medical, or financial flows
products with strict regulatory, accessibility, or audit requirements
routes, component ownership, or data states that cannot be changed freely

If any applies, start with audit-only. An agent can propose a small diff for visual spacing or tokens. Information hierarchy, field removal, error recovery, keyboard order, and regulatory copy require human approval. Do not present another tool's limits as Hallmark's official limits. For example, taste-skill explicitly excludes certain complex UIs, but that tells you only about the scope of that tool.

You can start a trial within an hour, but do not treat the timebox as a promise

You can reserve an hour for today's trial, but that timebox controls your investment. It does not guarantee that installation, auditing, and changes will all be completed. Choose a reversible page and save a before screenshot and Git baseline. If a new page has a reference, use study; for an existing page, start with audit. Adopt only a small set of understandable changes, then run the two-layer acceptance matrix.

Finally, record three columns: recommendations you kept, recommendations you rejected, and rules that belong in DESIGN.md. This record is more useful than saying something "looks more designed," because it tells the next agent which choices belong to your product.

If you are building a one-off landing page, trial Hallmark on a small branch, choose the right verb, and converge quickly. If you maintain a mature product, protect the design system and use the audit punch list only as an outside opinion. Tools will keep changing, but your taste begins to take shape when you know which rules to reject.