Figma's AI agent used to answer one-off requests. Now it can build reusable skills, saved capabilities it can repeat, and connect to outside sources like Notion, GitHub, and other tools your work already lives in. That's a bigger shift than another feature, because it moves the agent from a thing you ask for a result to a thing you teach to do a job your way, again and again, with context from beyond the design file. This piece covers what agent skills are, how they differ from prompting, what connecting the agent to your other tools actually changes, and the governance question that comes with it. Because these capabilities are recent and still expanding, the specifics may keep evolving, but the strategic reading holds regardless.
If you read about the earlier version of Figma's agent, this is the expanded picture; the foundational guide to using the Figma AI agent covers where it started, and this covers where it went.
Skills versus prompts: from asking to teaching
Figma's AI agent used to answer one-off requests.
The distinction that matters is between prompting the agent and giving it a skill. A prompt is a one-time instruction that produces a one-time result; you re-specify everything each time you want the job done. A skill is a saved, reusable capability, you define what it should do and the rules it should always follow, once, and then invoke it repeatedly, getting consistent results without re-describing the job.
The shift is from asking to teaching. In practice, you ask the Figma agent to create a skill based on the context in a file, packaging up a repeatable workflow, then invoke that skill with a slash command whenever you need it. You can also publish skills to the Figma Community, where dozens are already available to browse, add, or remix, and even copy and paste them as markdown files. Instead of explaining the same task every time, you teach it once and it applies that every time you call it. The value is consistency and compounding: a well-built skill applies your standards automatically, rather than depending on you remembering to specify them each round. This is the same idea as the concept of reusable Figma skills, now with the agent able to build and run them.
What connecting the agent to your tools changes
The second half of the shift is connection. When the agent can reach outside the design file, into a documentation source, a code repository, a data source, it can act with context it never had, and that changes what it can usefully do.
Concretely, the updated agent connects to external tools including Notion, Slack, GitHub, and Atlassian, so it can pull real content and context into design work rather than inventing it, reference the actual state of things that live elsewhere, and bridge the gap between the design file and the systems around it. The design file stops being an island. The practical wins are things like working with real content from your documentation instead of placeholders, or referencing the real components and structure in a codebase, so the agent's output fits reality instead of approximating it.
The honest caveat is that a connection is only as useful as the context on the other end is clean and relevant, and a connected agent acting on messy or wrong external context produces confident, wrong output. The connections are powerful in proportion to how well-organized the systems they reach into are.
Building a skill worth having
The best skills, like the best generative plugins, are specific, repetitive, and particular to how your team works, the jobs a generic tool can't do because it doesn't know your standards.
The principle for building a good skill is the same as for prompting well, encode the judgment up front, but more so, because a skill's rules apply to every future run. A skill that generates assets needs its constraints, the tokens, the formats, the things to avoid, baked in once so every run inherits them, which means the specificity you'd put into a single strong prompt gets front-loaded into the skill definition. A vague skill produces vague output forever; a well-specified one turns your standards into something the agent applies automatically, which is exactly the compounding value of the brief as the real deliverable, applied to a reusable capability.
The governance question skills create
Reusable skills and outside connections introduce a real question most teams haven't thought about: who owns a skill, and who's accountable for what it does at scale.
A one-off prompt produces one result a person reviews. A skill produces many results, repeatedly, potentially across a team, which means a flaw in the skill propagates, quietly, into everything it touches. If a shared skill has a subtle problem, off-brand output, a missing state, an accessibility gap, it doesn't fail once; it fails every time it runs, everywhere it's used, until someone notices. That changes review from a per-output act to a per-skill responsibility.
The practical response is to treat skills like shared infrastructure rather than personal shortcuts. A skill that a team relies on needs an owner who keeps it correct as standards change, and a review before it's trusted for shared use, the same human-in-the-loop discipline that governs any AI output, described in building review gates for AI design. Connections raise the stakes further, because a skill acting on external systems can reach beyond the design file, so anything with real consequences deserves a deliberate check on what it can access and do. It helps that Figma gives admins controls here, including the ability to disable AI tools across a team or organization, and that new agent conversations are visible by default to teammates with edit access, which at least makes shared use less of a black box. The convenience is real; so is the need to govern it.
The compounding value of a skill library
The real payoff of agent skills shows up over time, as a team accumulates them. One skill saves the re-specification of one task; a library of well-built skills means a growing share of your recurring work carries your standards automatically, so the agent's baseline output gets steadily more on-brand and complete without anyone re-explaining it each time. This compounds the way a component library does: early on it's a few pieces, and eventually it's the encoded judgment of the team, applied by default. The teams that treat skills as an asset to build deliberately, rather than one-off conveniences, end up with an agent that produces good work by default, which is a meaningfully different position from prompting from scratch every time and a real competitive edge over teams still doing exactly that.
Getting started: your first skill
The way in is to notice repetition. The next time you catch yourself explaining the same task to the agent in the same way, that's a skill waiting to be made, because you've already got the specification, you're just re-typing it. Turn that one recurring instruction into a skill, encode the rules you always give, and run it a few times to confirm it holds. Start with something low-stakes and clearly bounded rather than an ambitious multi-step capability, so you learn how skills behave before you rely on one for anything consequential. Once you've built one and seen it repeat reliably, the pattern becomes obvious, and you'll start noticing skill candidates everywhere in your recurring work, which is how a useful library begins to form.
Start Monday
Identify one task you explain to the agent the same way every time, and turn it into a skill this week, encoding the rules you always specify so you stop repeating them. Run it across two different files to confirm it's consistent. That one skill teaches you the shift from asking to teaching, and shows you both the compounding value and the governance responsibility that comes with a capability that repeats. If you connect the agent to an outside tool, start with a low-stakes read-only connection so you learn what it enables before trusting it with anything consequential.
The agent building its own skills and reaching into your other tools moves it from a helper you instruct each time to a capability you teach once and rely on, with context from beyond the design file. That's a genuine step up in leverage, and it comes with a genuine step up in responsibility, because a skill applies your judgment, or your mistakes, at scale. Teach it well, govern the shared ones, and it becomes a compounding asset rather than a propagating risk.