Generating a design option is no longer the hard part. The hard part is producing an option that belongs to the product: correct components, credible content, accessible states and the visual restraint the team would expect from itself. Figma’s custom agent skills are interesting because they frame that challenge as reusable practice rather than prompt-writing theatre.
A skill stores a repeatable way of working. It can tell the agent where to look for components, which checks to run, how to handle exceptions and when to ask for judgment. That lets a team improve one shared workflow over time instead of re-explaining its standards in every chat.
Prompts request an output; skills define a practice
A prompt usually describes the immediate result: redesign this settings screen, create three hero directions, check this flow. A skill can describe how the work should happen: inspect existing variables, use approved components, preserve content hierarchy, test contrast, create mobile states, and document any necessary exceptions.
That makes skills closer to a lightweight operating system for design work. They can hold the team’s definition of done, not just its visual style. The most valuable instructions may be procedural: when to reuse, when to extend, when to ask, and how to verify the result.
The competitive advantage is not access to an agent. It is the quality of the judgment and context that the team can repeatedly give it.
Design systems become executable context
Figma’s canvas tools can operate with components and variables, while skills provide sequencing and conventions. The examples announced by Figma include generating libraries from code, applying a design system, syncing tokens with drift detection and producing screen-reader specifications from UI specs.
This changes the role of design-system documentation. A page that only explains what a button looks like is insufficient. Teams need rationale, allowed variation, content rules, accessibility expectations and examples of misuse. Clear documentation helps people today and becomes higher-quality context for agents tomorrow.
Start with narrow, observable workflows
The temptation is to create one enormous skill that promises to design an entire product. Narrow skills are easier to evaluate. A content-quality check, responsive-state audit or token-drift review has a visible input, a bounded procedure and an output that a designer can verify.
- Choose a frequent task with a clear before-and-after state.
- Write the steps as if onboarding a thoughtful new teammate.
- Reference source-of-truth components and variables, not copied values.
- Define when the agent must stop and ask for judgment.
- Review real runs and update the skill when it fails predictably.
Consistency is not determinism
Figma correctly notes that model outputs remain non-deterministic. A skill improves consistency; it does not guarantee identical results. Product teams still need review, versioning and ownership. A skill that touches a design system should be treated like a shared tool: changes need testing, examples and a responsible maintainer.
Teams should also avoid turning today’s conventions into permanent constraints. Good design systems evolve. The skill should communicate principles and preferred patterns while leaving room for an intentional exception that can be discussed and documented.
The designer’s role expands
Writing a useful skill requires design judgment, systems thinking, content clarity and enough technical understanding to describe inputs and checks. That combination looks a lot like design engineering. The work is not handing creativity to a machine; it is making a team’s craft legible and reusable.
As generation becomes common, durable quality will come from the surrounding system: trusted components, explicit principles, strong critique and workflows that preserve intent from canvas to code. A perfect one-off prompt cannot provide that. A well-maintained practice can. See my approach to design systems and implementation ↗
