Agent Skill for Design: How to Package Repeatable Design Work

An agent skill for design is a reusable workflow that tells an agent how to perform a specific design job: audit a screen, produce UI variants, inspect a Figma file, review accessibility, compare implementation against a reference, or turn a product brief into a constrained direction. It is not a generic "make this look better" prompt. It is a packaged design procedure with inputs, taste constraints, source artifacts, and completion evidence.

That distinction matters because design work fails when the agent has taste without context. A good design skill tells the agent which product surface it is judging, what user goal matters, which design system rules apply, which artifacts are authoritative, and what proof should come back. The useful unit is not "design expertise" in the abstract. It is a repeatable design job with a first inspection path and a reviewable result.

That is the same distinction Skillfully uses in What Is an Agent Skill?: a prompt asks for an answer, while a skill defines a reusable operating procedure. Design is a strong candidate because teams repeat the same judgment loops every week: review this screen, check this flow against the system, produce a few directions from this brief, or verify that the build still matches the intent.

Official skill systems encourage this kind of packaging. OpenAI describes Codex skills as reusable workflow packages with SKILL.md, optional scripts, references, and assets, loaded through progressive disclosure (OpenAI Codex skills). Anthropic frames skills as a way to capture procedural knowledge that agents can apply in real work (Anthropic engineering). Its Claude Code skill docs make the practical trigger simple: create a skill when you keep pasting the same checklist or multi-step procedure into chat (Claude Code skills). For design, that procedural knowledge is usually a mix of critique method, product context, accessibility expectations, and tool discipline.

Most design skills should map to one repeatable job. "Design the app" is too broad. "Review the admin billing settings screen for enterprise usability and return blocking issues, polish issues, and component-level fixes" is usable because the agent can inspect a bounded surface and return evidence.

Design job	Better skill scope	Completion evidence
Screen audit	Review one product screen for hierarchy, density, affordances, and accessibility risk	Findings grouped by severity with exact elements named
Flow critique	Walk a login, checkout, onboarding, or setup flow and find decision friction	Step-by-step issues, user intent, and the failed affordance
Design production	Generate three UI directions from a brief and existing design rules	Variant rationale, component choices, and tradeoffs
Implementation QA	Compare a built page against a Figma frame or screenshot reference	Screenshot evidence, mismatch list, and fix priority
Design system work	Convert a repeated UI pattern into component guidance	States, usage rules, examples, and "do not use when" rules

The boundary is important. A screen-audit skill should not drift into brand strategy. A variant-production skill should not silently invent missing product requirements. A design-system skill should not rewrite the whole product surface because one dropdown is inconsistent.

If you are writing the skill from scratch, start with the same contract discipline described in How to Write an Agent Skill That Actually Works: one job, trusted inputs, first source to inspect, completion evidence, stop rules, and a feedback path.

Use this contract before you write the long instructions:

• Trigger: use when a specific product surface needs design critique, production guidance, or implementation QA.
• Required inputs: screenshot, URL, Figma link, user goal, product context, and design system constraints. Mark which inputs are required and which are optional.
• First inspection path: inspect the current surface or source design before suggesting replacements.
• Evaluation axes: hierarchy, information scent, affordance clarity, accessibility, responsiveness, interaction states, copy density, and system consistency. For critique skills, map findings to recognizable UX heuristics such as visibility of system status, consistency, error prevention, and recognition over recall (NN/g heuristics).
• Out of scope: brand reinvention, unrelated flows, speculative features, and redesigns that ignore existing components.
• Output: severity-ranked issues, concrete fixes, screenshots or source references when available, and any variants requested.
• Stop rules: stop if there is no inspectable artifact, if the task needs a decision the brief does not provide, or if design-system source is unavailable.

The contract matters more than the flourish. A strong design skill sounds more like a senior designer's review checklist than a moodboard prompt.

Anthropic's bundled frontend-design skill is a concrete example of that pattern: it requires a design plan, subject-specific choices, critique before build, and a second critique after implementation (frontend-design skill). Impeccable takes a more productized angle, giving agents commands around layout, typography, color, adaptation, and polish so the user can direct visual work with shared vocabulary rather than vague taste words (Impeccable). The lesson for your own skill is not to copy either one. It is to decide which design job needs repeatable language.

Design skills improve when they can look at the same artifacts the team uses. If a skill can access tool context, say exactly when to use it.

For Figma work, the useful skill is not "use Figma." It is more specific: read the selected frame, identify components and variables, compare the built screen against the source, and name mismatches in language an engineer can act on. Figma's MCP server gives agents design context for implementation work, so a design skill should name when Figma is the source of truth and when the live product is the source of truth (Figma MCP server).

For browser QA, the skill should require a live URL or local route, capture screenshots at the viewports that matter, and inspect interaction states. Playwright supports screenshots and visual comparisons, which makes it useful for implementation QA when a skill needs repeatable evidence instead of vibes (Playwright screenshots, Playwright visual comparisons). This does not mean every design skill needs automation. It means the skill should distinguish "I looked at a screenshot" from "I exercised the live page."

For accessibility, the skill should separate automated checks from judgment. Tools such as axe can catch many common violations, and Storybook documents accessibility tests as a first QA line for rendered components (Storybook accessibility tests). They still do not prove the flow is understandable, reachable, or keyboard-friendly. WCAG 2.2 gives concrete criteria for issues such as focus appearance, target size, contrast, and keyboard operation, so a design skill should cite those checks when they matter instead of saying "looks accessible" (WCAG 2.2).

---
name: design-screen-audit
description: Review one product screen for usability, visual hierarchy, accessibility risk, and component consistency. Use when given a screenshot, URL, or Figma link. Do not use for brand strategy or unconstrained visual exploration.
---

Required input: screenshot, URL, or Figma frame.
Useful context: audience, user goal, product area, design system, and known constraints.

1. Identify the page state, primary user goal, and primary action.
2. Inspect the current artifact before proposing changes.
3. Evaluate hierarchy, affordances, density, responsive behavior, keyboard/focus risk, contrast risk, and component consistency.
4. Separate blocking usability issues from polish.

Return:
1. Blocking usability issues
2. Visual hierarchy issues
3. Accessibility risks
4. Component consistency issues
5. A prioritized fix list with exact UI elements named
6. Any assumptions or missing artifacts

Stop if there is no inspectable artifact.

That is more useful than a style prompt because it gives the agent a review method. Later runs can be judged by whether the audit found real issues, whether the fixes were actionable, and whether the same issue recurred.

Implementation QA is one of the best uses for a design skill because the task has a clear source, a clear target, and concrete evidence.

---
name: figma-build-design-qa
description: Compare a built screen against a Figma frame and return design mismatches. Use when given both a Figma source and a live URL or local route.
---

Required inputs: Figma frame and inspectable route.

1. Read the Figma source first and note layout, spacing, type scale, color tokens, interaction states, and responsive expectations.
2. Open the built route and capture desktop and mobile screenshots.
3. Compare the build against the source. Do not recommend unrelated redesigns.
4. Group findings by severity: blocking mismatch, visible polish issue, acceptable deviation.

Return exact elements, observed mismatch, expected behavior, and verification step.
Stop if either the source design or built route is missing.

This skill has a different shape from a critique skill. It does not ask the agent to decide what the product should become. It asks the agent to check whether the implementation matches an already-approved intent. That narrower job is easier to trust.

Design-system work needs even stricter boundaries because small component guidance can affect many screens.

---
name: component-pattern-review
description: Review a proposed UI pattern against an existing design system. Use for repeated components, empty states, tables, settings panels, and form patterns.
---

Inspect existing components before inventing a new one.
Return:
- current closest component
- states required: default, hover, focus, disabled, loading, error, empty
- accessibility notes
- when to use this pattern
- when not to use this pattern
- migration risk for existing screens

The tradeoff is speed versus governance. A loose design-production skill can generate more directions quickly, but it may create variants that the system cannot absorb. A component-pattern skill is slower and more constrained, but it protects consistency when many teams will reuse the result.

A design skill should not treat accessibility as a final sentence. It should say what the agent checks and what evidence it can realistically provide.

Good accessibility instructions are concrete:

• Check whether keyboard focus can be seen and follows the interaction order.
• Flag small tap targets against WCAG 2.2 target-size expectations.
• Flag text or control colors that appear likely to fail contrast, then verify if tooling is available.
• Check whether error, loading, empty, and disabled states are visible and understandable.
• Name the affected element, not just the general principle.

This is especially important for design skills because visual polish can hide functional failure. A beautiful combobox that cannot be reached by keyboard is not a successful component. A subtle error state that only relies on color is not a good form pattern. A dense dashboard that looks "professional" but hides the primary action has failed the user's job.

Automated accessibility tooling is useful, but the skill should not overclaim. The right output is usually "automated check found these issues, manual review found these risks, and these items need human confirmation." That is a better design review than a confident but unsupported pass/fail.

• Does the skill name the design artifact it needs?
• Does it distinguish critique, production, and implementation QA?
• Does it tell the agent which design system or product conventions to respect?
• Does it require concrete evidence instead of aesthetic adjectives?
• Does it include accessibility and responsive behavior as first-class checks?
• Does it name tool use clearly: Figma source, browser route, screenshot, or automated check?
• Does it separate blocking issues from polish?
• Does it avoid inventing product strategy that was not in the brief?
• Does it stop when source context is missing?

The practical test is whether the output helps a team make a decision or change a product surface. "Make this cleaner" is not enough. A strong design skill should name the broken visual hierarchy, the affected component, the accessibility risk, and the next concrete change.

If the team is using Skillfully to publish and improve skills, this is also where feedback matters. A design skill is not finished because it produced one good review. It should collect the recurring misses: vague findings, missing artifacts, overbroad redesign suggestions, false accessibility confidence, or recommendations that do not fit the design system. That is why How to Test an Agent Skill Before You Publish It is especially relevant for design work: taste has to become observable.

Do not use a design skill when the problem is actually product strategy, brand positioning, or visual exploration with no constraints. Use a design skill when the work repeats and quality can be inspected: audits, handoff checks, system consistency reviews, accessibility reviews, and production variants from a known brief.

There are real tradeoffs:

• Use a prompt for a one-off aesthetic suggestion or a quick naming brainstorm.
• Use a design skill for repeatable critique, QA, or production work where the output can be inspected.
• Use a tool or script when the job is mostly measurement, such as screenshot diffing, contrast calculation, or route crawling.
• Use a human review gate when the recommendation changes product strategy, brand direction, legal claims, or accessibility policy.

The durable rule is simple: if the agent needs taste plus procedure, write a design skill. If it only needs one creative suggestion, use a prompt.

The best design skills do not pretend that design is fully objective. They make judgment easier to inspect.

They name the artifact. They respect the system. They inspect before recommending. They separate user-blocking issues from polish. They cite screenshots, source frames, components, or accessibility criteria. They stop when context is missing.

That is the difference between a clever design prompt and a reusable design workflow. The prompt may produce an interesting answer. The skill gives a team a repeatable way to review, build, QA, and improve product surfaces.