Codex Skills vs Plugins: What Designers Actually Need

The short version

Codex has two ideas that sound similar until you use them:

• Skills are reusable instructions. They teach Codex how to do a task the same way every time.
• Plugins are installable bundles. They can package skills, app integrations, MCP servers, and prompts together.

From repeated task to reusable setup

Start with the instruction. Add connected tools only when the workflow needs them. Package the whole setup as a plugin when it needs to be installed or shared.

Skill How to do the job

Instructions, examples, review rules

plus

Tools Where context comes from

Apps, MCP servers, files, browser

then

Plugin Installable bundle

Skills, app setup, prompts, config

Guide Repeated workflow Something you do often enough to stop re-explaining

• Layer 01 Mapped Skill How to do the job
• Layer 02 Mapped App Where to get or send data
• Layer 03 Mapped MCP Special tools the agent can call
• Layer 04 Mapped Plugin The installable bundle

For designers, this distinction matters because most of your first wins are skills, not plugins.

You do not need to package a whole ecosystem to get value. You need one repeatable workflow Codex can run without you pasting the same 400-word prompt every week.

The clean distinction

Question	Skill	Plugin
What is it?	A reusable playbook	An installable bundle
What does it contain?	Instructions, examples, reference files	Skills, app connections, MCP config, prompts
Best first use	One repeated task	A repeated setup across tools
Designer example	Review this UI against our taste rules	Review UI using browser, Figma, and design-system docs
Risk	Too vague, too broad	Too much setup too early

If a workflow fits in a markdown checklist, start with a skill.

If the workflow needs Gmail, Slack, Google Drive, Figma, GitHub, Linear, browser automation, or a custom MCP server, you are probably moving toward a plugin.

Five designer skills worth creating first

1. UI quality review

Use this when Codex has generated a page, prototype, or component and you want a senior designer pass before you look at it.

Create a skill called ui-quality-review.

It should review a URL, screenshot, or generated UI for:
- visual hierarchy
- spacing and density
- typography fit
- interaction clarity
- generic AI design patterns
- mobile layout issues

Return only the top 7 issues with severity and concrete fixes.
Do not rewrite the whole design unless asked.

2. Component spec writer

Use this when a design-system component needs docs.

Create a skill called component-spec.

It should read a component file, screenshot, or Figma description and write:
1. What this component is for
2. When to use it
3. When not to use it
4. Props or variants
5. Accessibility notes
6. Content guidelines
7. Examples

Use short practical language. No marketing copy.

3. Token drift audit

Use this when your design system has code tokens, Figma exports, or raw CSS drift.

Create a skill called token-drift-audit.

It should find:
- raw colors outside token files
- repeated spacing values
- semantic tokens that bypass primitives
- component-specific tokens that should be shared
- mismatches between naming convention and actual names

Return a table with issue, location, severity, and suggested fix.

4. Design QA browser pass

Use this when Codex can open your local app or preview URL.

Create a skill called design-qa-browser-pass.

It should open the page in a browser and inspect:
- desktop, tablet, and mobile layout
- overflow and clipped text
- focus states
- hover states
- empty/loading/error states if available
- obvious accessibility issues

Take screenshots when possible.
Return a concise QA report.

5. Changelog from diff

Use this when engineers shipped design-system changes and you need human-readable release notes.

Create a skill called ds-changelog.

It should read a git diff or changed files and write:
- user-facing changes
- breaking changes
- migration notes
- component/token names affected
- one short announcement paragraph

Write for product designers and frontend engineers.

How to make a good skill

The fastest way is not to write the perfect skill from scratch. The fastest way is:

1. Ask Codex to do the task manually.
2. Correct the output until it is good.
3. Say: “Turn this workflow into a reusable skill.”
4. Inspect the generated skill.
5. Run it on a second example.
6. Edit the skill when it misses something.

This is the same move you already use as a designer: prototype first, systematize second.

Bad skill vs good skill

Bad:

Make my designs better.

Good:

Review a SaaS settings page for scannability.

Focus only on:
- grouping
- labels
- hierarchy
- dangerous actions
- empty/error states

Return:
- max 5 findings
- severity
- evidence from the screen
- one concrete fix per finding

Do not comment on brand style unless it blocks usability.

The second prompt is boring. That is why it works.

When a skill should become a plugin

A skill becomes a plugin candidate when the workflow is no longer just instructions.

Criterion	Skill Best pick Start here	Plugin Package later
Only needs instructions	Best	Overkill
Needs app access	Limited	Best
Shared across a team	Okay	Best
Needs MCP setup	Limited	Best
One personal workflow	Best	Usually too much

Skill example

“Review this pricing page against our visual quality rubric.”

No external data. No setup. Skill.

Plugin example

“Every Friday, read new Linear issues tagged design-system, check linked PRs in GitHub, open preview URLs in a browser, and write a summary to Slack.”

That needs multiple tools and recurring setup. Plugin.

The designer plugin ideas worth exploring

Do not build all of these now. Keep them as a roadmap.

Design system weekly pulse

Includes:

• GitHub access
• Linear or Jira access
• browser check skill
• changelog skill
• Slack summary

Output: “What changed this week, what needs design review, what is risky.”

Figma-to-code QA pack

Includes:

• Figma access
• browser automation
• screenshot comparison instructions
• design QA skill

Output: “Where the implementation does not match the design intent.”

Research-to-content pack

Includes:

• browser/research access
• docs or Notion access
• writing voice skill
• image generation skill if needed

Output: “Draft a guide, outline, examples, and visual asset brief.”

Inbox-to-opportunity triage

Includes:

• Gmail or Outlook
• research skill
• spreadsheet or document output

Output: “Which inbound messages matter, why, and what to do next.”

How not to overbuild

The trap is turning every workflow into infrastructure. Designers do this too. We create naming systems before we have names, dashboards before we know the metric, plugins before the skill has proven itself.

Use this order:

1. Prompt once.
2. Repeat manually.
3. Skill the workflow.
4. Automate the skill.
5. Plugin the setup if other people need it.

A practical first skill

Start with a UI quality review skill. It is broad enough to be useful and narrow enough to test.

Paste this into Codex:

Create a Codex skill called ui-quality-review.

Purpose:
Review a URL, screenshot, or generated UI before I ship it.

Use when:
- I ask for design QA
- I ask you to review generated UI
- I ask whether a page feels polished

Review lenses:
1. Hierarchy: can the primary action and page purpose be understood in 3 seconds?
2. Layout: spacing, alignment, density, and responsive behavior
3. Typography: size, line length, truncation, overflow
4. Interaction: hover, focus, disabled, loading, empty, and error states
5. Taste: generic AI patterns, random gradients, decorative clutter, vague CTAs

Output:
- Top 7 findings max
- Severity: Blocking, High, Medium, Low
- Evidence: what you observed
- Fix: one concrete instruction

Rules:
- Do not redesign the whole page.
- Do not praise the work before findings.
- Do not include generic advice.
- Prefer specific selectors, elements, labels, and screen areas.

Then run it against one page:

Use ui-quality-review on http://localhost:4321/pricing.
Open it in a browser if available.
Check desktop and mobile widths.

How to improve the skill after one run

After Codex returns the report, edit the skill with one of these:

Good catch. Update the skill so it always checks button text for vague labels like "Submit", "Continue", and "Learn more".

This is too broad. Update the skill so it only returns issues that can be fixed in less than 30 minutes.

You missed mobile overflow. Update the skill so mobile width is mandatory whenever a browser is available.

Skills become good through use. The first version is never the final version.

Exercise

Turn one repeated prompt into a Codex skill

1. Pick one workflow

2. Run it manually

3. Convert it

4. Test on a second input

You are done when the skill returns the same shape of useful report on two different inputs.