Best frontend design skills for AI agents

Ask an agent for a landing page and you get a landing page. It will be responsive, it will pass a linter, and anyone who looks at it will know what made it. The tells are consistent enough that the people writing design skills now list them by name — Inter, purple-to-blue gradients, identical card grids, a small tracked eyebrow over every section, and the warm near-white background that clidey's copy of impeccable flatly calls "The cream / sand / beige body bg is the saturated AI default of 2026." None of that is a taste problem. It is a sequencing problem: the agent makes every design decision at the instant it writes CSS, and with nothing committed beforehand it lands on the median of everything it has ever read.

The skills worth installing move that decision earlier, or check the result afterwards. What surprised me while reading them is how little the name on the file tells you about which of those you are getting. A skill called frontend-slides can hand your agent either of two opposite rules about the one thing that decides whether a deck holds its shape on someone else's screen — and the files carrying those opposite rules ship the same trigger description, word for word.

Top picks

skill	publisher	license	verdict	updated
impeccable	pbakaus	Apache-2.0	Top pick — current text, needs its whole directory	2026-07-28
impeccable	clidey	Apache-2.0	Also read — older text, ban list written out in full	2026-07-27
impeccable	theexperiencecompany	MIT	Rival — same name, preflight gate table	2026-05-28
design-review	julianoczkowski	Apache-2.0	Top pick — grades the render, not the source	2026-07-06
frontend-design	AkaraChen	MIT	Top pick — states its upstream, gates on context	2026-07-27
frontend-slides	zarazhangrui	MIT	Top pick — fixed-stage decks	2026-06-23
frontend-slides	gooseworks-ai	MIT	Rival — deprecated in its own text	2026-07-23
frontend-slides	xu-xiang	MIT	Rival — Chinese port, opposite geometry	2026-03-05
slideshow	heygen-com	Apache-2.0	Top pick — decks as running compositions	2026-07-28
Slideshow	chmonitor	GPL-3.0	Rival — near-twin under copyleft	2026-07-27

Impeccable: take the copy from the repository it is named after

pbakaus's impeccable is a router. Version 4.0.3 sorts design work into named jobs — shape, critique, audit, polish, bolder, quieter, distill, harden, animate, colorize, typeset, layout, clarify, adapt, optimize — each pointing at its own reference file, with a live mode for picking elements in a running browser and a doctor command that reports drift between the project's design artifacts and what the current version expects. It also states a rule worth stealing whatever else you install: verify in bounded passes and then stop, because open-ended self-QA burns the user's money.

The catch is structural. This copy runs node .agents/skills/impeccable/scripts/context.mjs, then loads reference/craft-floor.md, which "carries the quality floor, the absolute bans, and the reflexes no detector catches." Copy the SKILL.md on its own and you have a table of contents with nothing behind it. Install the directory.

The older impeccable text is the one with the rules inside it

clidey's copy carries the same name and the same trigger description, but it is version 3.8.0 and a different document. The floor is inline rather than referenced: contrast minimums of 4.5:1 for body text and 3:1 for large, a 65–75ch line-length cap, a display letter-spacing floor at -0.04em, a semantic z-index scale instead of arbitrary 999s, and a match-and-refuse ban list covering side-stripe borders, gradient text, decorative glassmorphism, the hero-metric template and the tracked eyebrow.

It also names defects at a specific generator rather than in the abstract: the 1px-border-plus-wide-shadow ghost card, border-radius of 32px or more on cards, hand-drawn SVG filler, diagonal stripe backgrounds. That specificity is the value here, and it is also the limit — those passages are aimed at one agent's habits, so read them as a checklist to steal from rather than as universal law.

design-review: the pass that looks at the pixels

Most design skills tell an agent how to build. julianoczkowski's design-review is about looking at what got built, and it refuses to do that from source alone: "Code review alone is insufficient — you need to see what the user sees." It drives a browser to capture full-page screenshots at 1280×800, 768×1024 and 375×812, plus hover, focus, error, empty and dark-mode states — preferring a Playwright MCP server, falling back to the Cursor IDE browser, and, if neither is there, asking you to shoot those viewports by hand rather than proceeding blind. It saves them under .design/<feature-slug>/screenshots/ with filenames that encode what they show, then grades the build against the brief's named philosophy.

The output is a prioritised list — must fix, should fix, could improve — with findings pointing at specific screenshot filenames, so a fix is traceable to the thing that prompted it. One caveat before you install the set: its companion design-flow will not run this phase for you. The guided sequence ends at build, and review happens only when you ask for it.

frontend-design: the copy that tells you where it came from

AkaraChen's frontend-design does the familiar job — commit to a bold direction, then write real code — but two things make it the copy to reach for. Its front matter states the skill it is based on instead of leaving you to guess, and it opens with a hard gate: before any design work the agent must have audience, use cases and brand tone confirmed, and it is explicitly barred from inferring them from the repository, because "Code tells you what was built, not who it's for or what it should feel like."

The trade-off is that the gate is real. With no design context in your instructions and no .impeccable.md in the project root, the skill sends the agent off to run a separate teach command before it will build anything. That is the right behaviour and it is also a first-run detour, so seed the context file if you want it to work on the first try.

Slides: zarazhangrui's fixed stage is the one that survives a phone

This is the disagreement worth knowing about. zarazhangrui's frontend-slides makes deck geometry non-negotiable — "Every deck uses a 1920×1080 slide canvas scaled as a whole to the viewport." It letterboxes where it must, and "Do not use responsive breakpoints to rearrange slide content for phones." Type is authored at fixed sizes on that canvas, so what you approved is what the room sees.

Its same-named siblings go the other way. gooseworks-ai's copy sets the rule as "Each slide = exactly one viewport height (100vh/100dvh)" and scales every font and gap with clamp(); xu-xiang's Chinese port carries the same viewport-height rules and credits the author it learned from. Reflowing decks look fine on a laptop and rearrange themselves on a phone. Take the fixed stage unless you genuinely want reflow — and note that gooseworks-ai's own text opens with "This skill is superseded by goose-graphics." The successor is goose-graphics, from the same publisher, and it is a different proposition: a render pipeline that treats slides as one output format among several, with styles fetched from a central library at run time rather than bundled — so if the reflowing deck was what you wanted, that is where it now lives.

HyperFrames slideshow: when the deck needs to be a program

heygen-com's slideshow is not an HTML-file generator. A deck here is a composition — scenes carrying data-composition-id, GSAP timelines, and one JSON island declaring slide order, presenter notes, fragment hold-points and hotspots that branch off the main line. You serve it rather than open it; presenter mode is on the P key and opens a separate audience surface, and the file spends real space on sharing that surface over Meet or Zoom without freezing it.

Two caveats, both from the text. It confirms intent before authoring on purpose, and says why: "building the wrong deliverable type is a quality failure, not a creative call." And "Do not hyperframes render a slideshow into a single MP4" — a deck has no master-root composition, so a render resolves the first one and silently truncates. That is the trap you would have walked into alone.

Is "frontend design" one job, or several?

Several, and the sets that admit it hold up best. design-flow spells the sequence out: clarify the thinking, write the brief, define information architecture, generate tokens, break the brief into tasks, then build — with review as a separate seventh phase invoked deliberately. The middle four write files under .design/<feature-slug>/ — brief, information architecture, tokens, tasks — so the next phase has something to obey instead of something to infer. (The opening interview produces no file, by design: it is there to make you say what you want out loud.)

That structure is the real fix for generic output. design-tokens, for example, will not start clean if a Tailwind config, a theme file or a :root block already exists — it extends what is there and fills the gaps, such as a missing dark palette, and it insists dark mode be authored rather than inverted. A single do-everything design skill has to make all of those calls silently while it types. A split set makes them one at a time, in writing, where you can argue with them.

How do you tell which skill you are holding?

Names are not namespaced, and community publishing copies files freely. A skill called impeccable can be a slim router that loads bundled reference files, a copy that writes its quality floor and its bans out in the file itself, or a preflight gate table that makes the agent print a pass/fail line before it is allowed to touch a file. Those are different documents with different behaviour, and the trigger description they ship is in some cases identical, word for word — which is the field your agent routes on. The description will not save you. Four checks that will:

• Read the front matter. Version numbers differ between copies of one name, and the lower number is sometimes the more complete document.
• Look for a provenance key. AkaraChen's copy states its basis in its licence line; xu-xiang's slides skill carries an origin key and thanks the author it learned from by name; frontend-slides-editable does the plainest version of all, opening with "This skill is a copy of the frontend-slides skill extended with the editable deck runtime" and telling you to use the original if you do not want the editor; frontend-dev lists its upstream sources outright — and, less obviously, ships scripts that call one vendor's asset-generation APIs, a dependency worth noticing before you install.
• Check whether the file is the skill. If it routes to reference/ files and scripts/, the file on its own does nothing.
• Check the licence at the repository, not only in the file. Run that check on AkaraChen's frontend-design — the copy praised above for its honesty — and the two disagree: the front matter says "Apache 2.0. Based on Anthropic's frontend-design skill." while the repository the file ships in is MIT. That is not a reason to distrust the skill; the attribution is the valuable half of that line and it is still the clearest in the set. It is a reason to treat a licence written inside a SKILL.md as a claim rather than a fact, on the very copy where you would least expect to have to. chmonitor's Slideshow is close enough to heygen-com's to be mistaken for it, yet it is offered under GPL-3.0 rather than Apache-2.0 — and it is missing the parts of heygen-com's text that keep you out of trouble, the render warning among them.

The same logic runs past the browser. pbakaus's impeccable loads native-platform guidance when the project calls for it and keeps separate native variants of its audit and adapt references, which is the right instinct: a design floor for a phone app is a different document from a design floor for a landing page.

What to install

The failure underneath all of this is an agent that commits to nothing and therefore defaults to everything. So commit on its behalf, then check the result. For web work, take pbakaus's impeccable for the command surface and read clidey's copy for the inline ban list you will want to keep either way. If you would rather have the decision split into stages you can inspect, julianoczkowski's set does exactly that, and design-review earns its place alongside whatever else you run, because it is built around looking at the render rather than the source. For decks, zarazhangrui's frontend-slides gives you a presentation that will not rearrange itself in front of an audience, and heygen-com's slideshow is the one to reach for when the deck needs branching, presenter notes and a live present mode.

And whatever you install, open the file before you trust the name on it. The name is only the topic. The publisher and the body are the skill.