Codex Frontend Design Skill: Pair It With Real Components

You installed a Codex frontend design skill, asked for a pricing page, and got a nicer page than before: better type, fewer purple gradients. Then you asked for the settings screen, and Codex wrote a second button component with a different radius and a spinner it made up on the spot. That is what a taste skill does on its own. This post explains what a frontend design skill is, where Codex loads skills from, which ones you can find on GitHub, and how to pair one with a real component registry, an MCP server and an AGENTS.md block so Codex builds from components you own.

We checked every path and setting below against OpenAI's Build skills docs (opens in a new tab) (the old developers.openai.com/codex/skills address redirects there) and Cursor's skills docs (opens in a new tab) on November 6, 2026. Both change often, so check them again if you read this months later.

What is a Codex frontend design skill?

A skill is a folder with a SKILL.md file. The file starts with YAML frontmatter that must include name and description, followed by instructions in Markdown. Optional folders hold scripts/, references/ and assets/, and an optional agents/openai.yaml sets UI metadata, the invocation policy and tool dependencies. Codex skills follow the open agent skills specification (opens in a new tab), so the same folder works in other agents that read the format.

A frontend design skill is one whose instructions are about UI: how to pick a visual direction, which fonts and colors to avoid, how to lay out a hero, what to check before calling a screen done. Nothing about the format is special to frontend work. It is a prompt that Codex loads at the right moment.

How Codex uses it, from the docs:

• At startup Codex reads only each skill's name, description and file path. That list uses at most 2% of the model's context window by default (8,000 characters when the window is unknown), and skills.max_context_tokens can raise it to 10,000 tokens.
• Explicit use: type $ to mention a skill in your prompt, or run /skills in Codex CLI or the IDE extension.
• Implicit use: Codex picks a skill by itself when your task matches its description. Then it reads the whole SKILL.md.

That makes the description the most important line in the file. OpenAI's advice is to front-load the main use case and the trigger words, because Codex shortens descriptions when many skills are installed.

Where does Codex load skills from?

From four scopes. This is the table from OpenAI's docs, shortened:

Codex follows symlinked skill folders and picks up changes on its own; if a new skill does not show up, restart Codex. Some community READMEs on GitHub still tell you to copy skills into ~/.codex/skills, which older Codex builds read. The current docs list only the .agents/skills folders above, so use those.

To turn a skill off without deleting it, add an entry to ~/.codex/config.toml:

[[skills.config]]
path = "/Users/you/.agents/skills/frontend-design/SKILL.md"
enabled = false

The same folders matter if you also use Cursor. Its docs say it loads .agents/skills and ~/.agents/skills, plus .codex/skills and .claude/skills for compatibility. A cursor frontend design skill and a Codex one can be the same folder.

Which frontend design skills are on GitHub?

Two sources are worth reading at the source: Anthropic's frontend-design skill, which works in Codex as is, and OpenAI's curated Codex skills, which have no general frontend design skill. Most community lists that come up for a frontend design skill on GitHub point back to the first one. What we found on November 6, 2026:

• Anthropic's frontend-design, in the anthropics/skills (opens in a new tab) repository. Its description promises guidance for "distinctive, intentional visual design" when you build or reshape UI. The body asks the model to ground the design in the product's subject, pick an aesthetic direction, and avoid the defaults that make generated pages look alike. It is written for Claude, and it works in Codex as is because the format is the same.
• OpenAI's curated skills, in openai/skills (opens in a new tab). The folder holds 39 skills. Eight are for Figma (figma-implement-design, figma-create-design-system-rules and others), two are for Playwright, and none is a general frontend design skill. The repository now says it is deprecated and points to openai/plugins (opens in a new tab).
• Community packs of UI design skills for Codex, often bundled with deploy, testing and docs skills. Read any of them before you install it: a skill is instructions your agent follows, and a skill with scripts/ can run code.

Which one is the better choice depends on the job. For a one-off landing page with no design system behind it, Anthropic's skill is a good pick, because it pushes the model away from the generic look. For an app with fifty screens it pulls the wrong way: a skill that asks for a distinctive choice on every screen gets you fifty distinctive screens.

Why does a design skill alone still invent components?

Because a skill is text. It can say "use one accent color" or "check the page at 390px", but it cannot tell Codex that your project already has a Button with a loading prop, a Card with a selectable mode, or a sign-in screen with a code view. With nothing to pick from, Codex does what it always does: it writes a component from memory, and writes it again a little differently on the next screen.

Three pieces close that gap, and each does one job:

The skill is what decides the order: search the registry first, read the props, install with the CLI, then apply the taste rules to layout and copy. The component library MCP guide covers the server side of this for every agent.

How do I pair a design skill with a registry in Codex?

In three steps: connect the registry's MCP server and rules file, add the library's own skill, then write your taste rules as a second skill that sends Codex to the registry first. The example uses our library, Wingo UI, because its CLI writes the Codex config for you; the same steps work with any registry that has an MCP server.

Step 1: Connect the MCP server and the AGENTS.md block

npx wingo-ui@latest login
npx wingo-ui@latest agents install codex

login saves an API key (a free account needs only an email). agents install codex writes a [mcp_servers.wingo-ui] table to ~/.codex/config.toml and a marked rules block to ~/.codex/AGENTS.md. The rules tell Codex to call search_components, get_component and get_block before it writes UI, to install with npx wingo-ui@latest add <slug...>, and to use semantic tokens. The full walkthrough, with the HTTP and stdio variants and the trust rules for project config, is in our Codex MCP setup guide.

Step 2: Add the library's skill

For Codex the CLI writes the config and the AGENTS.md block, not a skill. The skill file is a public download, so copy it into your user skills folder:

mkdir -p ~/.agents/skills/wingo-ui
curl -fsSL https://wingo-ui.com/agents/SKILL.md -o ~/.agents/skills/wingo-ui/SKILL.md

Its description names the screens and components it covers (sign-in, settings, pricing, tables, dialogs, OTP input), so Codex can match it to a UI task by itself. The body is the workflow: check for updates, search before you write, start whole screens from a block, configure through props, check 390px and 1440px in light and dark. npx wingo-ui@latest agents update refreshes the AGENTS.md block; for this copied file, run the curl line again.

Step 3: Write the taste part as your own skill

Keep your taste rules in a separate, small skill that knows about the registry. This one lives in the repository, so your team gets it with the code:

---
name: frontend-design
description: Visual direction for new screens and redesigns in this app (pages, dashboards, forms, marketing sections). Use with the wingo-ui skill. Not for backend or test changes.
---

# Frontend design for this app

1. Build from the library first. Call search_components for every piece; never write a button, card, dialog, field or menu by hand.
2. Change the look through props (variant, tone, size, radius, labels), not new CSS. Neutral tone everywhere, brand tone for the one main action per screen.
3. Layout is where the design happens: one clear focal point per screen, generous spacing, real copy from the product, no lorem ipsum.
4. Step the background at every level: page, then bg-surface, then bg-foreground/5 tiles. Never a card on a fill of the same shade.
5. Before you finish: 390px and 1440px, light and dark, keyboard only. List any handler you left on sample data.

Save it as .agents/skills/frontend-design/SKILL.md at the repository root. Rule 1 is the line a standalone taste skill never has, and it is what turns "make it look good" into "make it look good with what we have". If you also keep Anthropic's skill installed, it is named frontend-design too: rename yours (for example app-design, then mention $app-design), since Codex does not merge two skills with the same name and lists both.

What does Codex build once the pair is set up?

It builds screens from the library's components, installed with the CLI, instead of writing a new card and button for each one. Name the skill and the components in the prompt, so both the skill and the server get used:

$frontend-design Build /pricing for Harbor with two plan cards from the wingo-ui
library. Use get_component for card and button first. The Team plan is the
selected one. Install everything with the CLI and show me the diff.

After get_component, Codex knows the Card has a simple API (title, description, footer, children as the body) and a selected ring, and that the Button takes tone and fullWidth. A good run installs both with npx wingo-ui@latest add card button and writes something close to this:

import { Button } from "@/components/ui/button";
import { Card } from "@/components/ui/card";

export function PlanCards() {
  return (
    <div className="grid gap-4 sm:grid-cols-2">
      <Card
        variant="outline"
        title="Starter"
        description="$0 per month, one project"
        footer={<Button variant="outline" fullWidth>Choose Starter</Button>}
      >
        Up to 3 teammates and 1 GB of storage.
      </Card>
      <Card
        variant="outline"
        tone="brand"
        selected
        title="Team"
        description="$24 per month, unlimited projects"
        footer={<Button tone="brand" fullWidth>Choose Team</Button>}
      >
        Unlimited teammates, 100 GB of storage and priority support.
      </Card>
    </div>
  );
}

The brand tone appears once, on the plan you want people to pick, which is rule 2 of the skill doing its job. The demo below is the same Card with the outline variant, the brand tone and the selected ring, on a listing instead of a plan.

The Button is where hand-written UI usually drifts first: every screen grows its own spinner and its own disabled state. The library's version handles both through loading and loadingText, so Codex has no reason to write one.

For a whole screen, the skill's step "start from a block" sends Codex to get_block. A sign-in prompt such as "Build /login from the login-page block, card layout, password and email code, no social buttons" should end in a Login Page with layout="card", methods={["password", "otp"]} and showProviders={false}, plus your own onSignIn, onSendCode and onVerifyCode. Ask for the list of handlers left on their defaults: without onVerifyCode, the code view accepts 123456 for anyone.

How do I check that Codex uses the skill and the server?

Four commands tell you, and the tool calls in a run confirm it:

• Run /skills in Codex. Both wingo-ui and frontend-design should be listed; if one is missing, check the folder name and the frontmatter, then restart Codex.
• Run codex mcp list in the project folder. The wingo-ui server should show as enabled.
• Run npx wingo-ui@latest agents status to see which rules files are in place.
• Ask Codex one question only the server can answer, such as "Call get_account_status on the wingo-ui server". If it answers with your plan, the key reached the server.

If Codex still writes a component by hand, look at its tool calls. No search_components call means the skill did not load or the prompt did not name it; start the prompt with $frontend-design and try again.

Where should I start?

Set up the free pieces first: npx wingo-ui@latest login, npx wingo-ui@latest agents install codex, the two skill files above, then the plan card prompt. The Button and the Card are free, along with 73 other items. The Login Page is part of Wingo UI Pro ($8 a month, $80 a year or $150 once, see the pricing page), and whole pages live in the templates gallery. The coding agents docs list every file the CLI writes for each agent, and more setups like this one are under Building UI with AI agents, including AGENTS.md vs CLAUDE.md for the rules file and the Cursor shadcn MCP guide for the same job in Cursor.

FAQ

Where does Codex look for skills?

In .agents/skills in the folder where you start Codex and every parent folder up to the repository root, in ~/.agents/skills for your user, in /etc/codex/skills for the machine, and in the skills bundled with Codex. That is the list in OpenAI's skills docs as of November 6, 2026.

Can I use Anthropic's frontend-design skill in Codex?

Yes. It is a plain SKILL.md with a name and a description, the same open format Codex reads, so copying the folder into .agents/skills or ~/.agents/skills is enough. It was written for Claude, so read it once and drop the lines that do not fit your project.

Does OpenAI ship a frontend design skill for Codex?

Not in the curated folder of the openai/skills repository as of November 6, 2026: it holds 39 skills, eight of them for Figma, and none for general frontend design. The repository now marks itself as deprecated and points to openai/plugins.

Does a frontend design skill work in Cursor too?

Yes. Cursor's docs say it loads skills from .agents/skills and ~/.agents/skills, plus .codex/skills and .claude/skills for compatibility, so one skill folder can serve Codex and Cursor.

Why does Codex still write its own components with a design skill installed?

A skill is text: it can describe taste and a workflow, but it cannot list the components you own or their props. Connect a component library over MCP and have the skill tell Codex to search it first, and Codex has something real to pick from.