Design tokens have a settled job: carry typed, reusable values between design and implementation systems. Design skills have a less settled job: tell an agent how to behave when it makes, edits, or reviews an interface. The distinction is useful. Tokens tell a system what a color or radius is. A skill can tell an agent to inspect existing components, preserve a product’s hierarchy, ask an intake question, or avoid a familiar visual habit.
The container for these instructions is spreading quickly. A SKILL.md file usually begins with YAML Ain’t Markup Language (YAML) frontmatter, especially a name and a dense description, followed by Markdown guidance. The description is not decorative. It helps an agent decide when to load the skill. The body is usually free-form. It may include a checklist, a visual scale, a workflow, examples, scripts, or bundled references.
That flexibility explains the growth. It also explains why the design-skill category is not consolidated. Our open source software (OSS) survey describes it as “like 2019-era CSS framework proliferation, pre-consolidation.” That is a useful phrase because it does not say the work is unserious. It says several different answers are being tested at once.
First principles
A skill is text that an agent loads into its context when a task seems to match. Three facts about that mechanism shape the rest of this essay.
- The description decides loading. The agent reads a short frontmatter description and judges whether the skill applies. A broad description loads the skill often, including when it should not.
- A loaded skill is one instruction among several. It sits beside the repository’s code, its tokens, its
DESIGN.md, and any other loaded skill. Unless something declares an order, the agent has to guess which one wins. - Every value in a skill has a source, named or not. A spacing scale was taken from a product, copied from a preset, or made up. The agent cannot tell which unless the file says so.
So a design skill is only as safe as its declarations: what it covers, where its values come from, and what it yields to. A shared contract is simply those declarations, written the same way in every skill.
The container is already huge
The general-purpose skill ecosystem is large. anthropics/skills had 177,692 stars as of September 2026. obra/superpowers had 290,299. The projects are not design-only, but they supply much of the shared context in which design skills are packaged and distributed.
Specific design projects have traction too. Nutlope/hallmark, described as an “anti-AI-slop” design skill, had 29,049 stars as of September 2026. Owl-Listener/designer-skills had 2,724. julianoczkowski/designer-skills had 560. These are evidence that people want agents to carry taste and process, not just code completion context.
But stars do not show convergence on a design-native format. A landing-page playbook, a broad design-research collection, a component installation guide, and an “anti-slop” set of guardrails can all be delivered in a SKILL.md file while carrying incompatible assumptions about scope, inputs, outputs, and overrides.
The container has won attention. The contract inside it has not.
One file can mean several things
Elaya’s ai-design-skills demonstrates both the value and the ambiguity. As of September 2026, it had 2,302 stars and 159 forks. The repository contains exactly one skill, landing-page-design, and its three commits all date to its creation day, 2026-07-29. The file is dense and concrete. It gives an agent intake questions, page structure, copy rules, fonts, a spacing scale, radius logic, colors, and motion values.
Its frontmatter description is intentionally broad: use the skill whenever building, editing, styling, reviewing, or writing copy for a landing page, marketing site, web user interface (UI), section, component, or prototype. The skill can be copied or renamed for Claude Code, Cursor, Codex, Windsurf, or Cline. That is an effective distribution trick. One Markdown file reaches multiple environments.
It is not, in the strict sense, a richly packaged skill with scripts and progressive references. It is a single file wearing several hats. It has hard-coded visual guidance and no shared schema for saying where those tokens come from, what project facts override them, or whether the values are generic defaults rather than an existing product system.
That does not make it bad. It makes it one type of artifact: an opinionated landing-page operating manual. The current format does not force a skill to reveal that scope clearly enough for automatic composition with another skill.
TypeUI makes a different choice. It has a command-line interface (CLI), a hosted Model Context Protocol (MCP) server, a public registry, and more than 70 named “skins” in the research. Its template splits agent-facing rules into SKILL.md and human-facing rationale into an optional DESIGN.md. Its style presets include names such as Minimal, Brutalism, Glassmorphism, Neon, Claymorphism, and Editorial. These are deliberately not extractions from a particular product. They are stylistic presets.
This is a different job again. A preset may help an agent escape a default software as a service (SaaS) look. It should not silently override a product’s first-party tokens. A skill format that does not state whether it is a generic style, a product-specific implementation guide, or an extraction leaves that conflict to a model’s guess.
Taste is not a token, but it needs inputs
The appeal of a design skill is obvious. Agents often have enough ability to produce an interface and too little context to make it feel like it belongs. A skill can turn a vague instruction like “make it polished” into a working sequence: inspect the existing system, identify hierarchy, pick values from declared tokens, preserve accessibility, choose motion deliberately, and review against a concrete checklist.
The risk is that a generic skill becomes a replacement design system. It can confidently prescribe a font, rounded cards, spacing, or a motion curve that conflicts with the project. The more general its auto-invocation description, the more likely it is to load when it should yield to local evidence.
This is why skills need an override policy. A good rule is not merely “follow this skill.” It says what wins when the repository already contains a first-party DESIGN.md, a Design Tokens Community Group (DTCG) token source, component source, or product-specific accessibility requirements. It says whether the skill may introduce values or only arrange existing ones. It says whether it is a creative starting point, a strict implementation contract, or a review checklist.
The same problem appears with motion. transitions.dev distributes an installable skill alongside a CLI and copy-paste transition catalog. It teaches agents to choose transitions, find ad hoc animation values, and align them to a scale. It does not publish a formal token format or state a relationship to the browser View Transitions application programming interface (API), Motion, or the GreenSock Animation Platform (GSAP). A narrow skill can still be useful. But an agent needs to know whether it is installing a preferred recipe collection or adopting a project-wide motion specification.
A minimal shared schema
The field does not need a heavy design-skill standard to get better. It needs a few declarations that make skills composable and reviewable. Velofy intends to propose a minimal profile with four required ideas.
First, scope: what work does this skill cover? A landing page, product UI, motion review, component installation, research, or a specific product? Scope should include exclusions. A generic landing-page skill should say that it is not the source of truth for a repository’s existing brand tokens.
Second, token_source: where do the values come from? This can name a first-party DESIGN.md, a DTCG JavaScript Object Notation (JSON) file, Cascading Style Sheets (CSS) variables, a Figma source, a generic preset, or no token source. A source path or Uniform Resource Locator (URL) is more useful than the word “brand.” It lets the agent resolve conflicts using evidence.
Third, override_policy: what has priority when this skill conflicts with local code or another skill? A safe default is that first-party project files and accessibility requirements override a generic preset. The field can also say whether a skill may add new visual values or only select from the existing system.
Fourth, description: a short, explicit auto-invocation description. This exists today in many skill files, but it is often optimized only for broad triggering. It should state the trigger, the scope, and the condition that makes the skill inappropriate.
Additional fields can be useful: author, license, version, compatibility, inputs, outputs, and a reference list. The first four address the immediate failure mode. They answer: when should this load, what evidence does it use, and what does it defer to?
Distribution is not the same as governance
The ecosystem already knows how to distribute a skill. TypeUI provides a CLI and hosted MCP server. Sona UI has a layered agent-discovery surface: llms.txt, a JSON manifest, catalog, OpenAPI, and a shadcn-registry-installed skill. Refero provides an installable skill and a paid MCP path. transitions.dev uses npx skills add and a CLI. These are useful delivery mechanisms.
They do not create agreement about skill contents. A registry can make it very easy to install a file that is too broad, stale, proprietary, or unlicensed. The OSS survey notes that anthropics/skills itself had no LICENSE file as of September 2026. A developer should not assume that a public skill can be redistributed or embedded simply because it is easy to fetch.
The Elaya repository illustrates another form of uncertainty. A high star count and a single stagnant file do not tell a team whether the rules have been reviewed, maintained, or tested against changing tool behavior. A skill needs versioning and a source of truth just as component code does. It does not need a corporation to be useful, but it should not borrow the authority of popularity alone.
The right kind of consolidation
Consolidation should not mean one visual style wins. It should mean an agent can tell the difference between a product-specific system and a generic taste guide. It should mean a maintainer can inspect why a skill loaded and what it was allowed to override. It should mean a preset that encourages a particular aesthetic cannot quietly replace tokens that belong to a product.
The mature token layer offers a useful lesson. DTCG does not decide whether a product should use blue or orange. It gives implementations a shared way to represent the choice. Design skills need an equivalent modest agreement about metadata and precedence, not a universal theory of taste.
Until that exists, the safest practice is local and plain. Keep first-party tokens in a first-party source. Keep a product DESIGN.md close to the code. Treat generic skills as proposals or operating manuals. Require them to identify their scope and override behavior. Review them as behavior-changing inputs, because that is what they are.
What Velofy is doing next
Velofy intends to draft a small design-skill metadata profile with scope, token source, override policy, and an explicit auto-invocation description. We intend to treat generic presets as distinct from first-party product guidance. Velofy has no design-skill registry, package, or MCP server today. Any future distribution work will be described as a proposal until it is available.