Objective
Work beyond Figma by connecting tools.
Demonstrate knowledge of code editors by linking Figma with Cursor through MCPs.
Why
Documentation is one of the most tedious parts of a design system, but also one of the most necessary for development to actually use it. A DS that isn’t used fails. Notion makes that use easier: no account required and no learning curve.
AI can take that documentation into Notion through MCPs (Model Context Protocol), the “universal USB cable” that connects AI to other applications.
The experiment
To run this test, I used a small design system of my own called Aegis, designed to evolve toward components that AI can use directly.
The skill
A skill is a set of instructions that tells the AI how to do a job the same way every time, without explaining it from scratch each time. Here it connects Figma (where you work) with Notion (where the documentation lives) through Cursor: you describe in plain language what to document, and the agent reads Figma, organizes the information, and writes it into Notion.
How it works
-
Open Figma
The AI accesses the Figma file.
-
Discover what’s there
Locate variables (color, typography, and spacing tokens) and components.
-
Minimal questions
Language, color format, whether you want a local copy, and so on.
-
Set up Notion
Create the main page, indexes, and sections.
-
Fill with real data
Complete foundations and components with data from the file, not invented values.
-
Close and review
Run summary and automatic review ready.
Foundations come from Figma’s variables table.
Components are documented by looking at the live piece (variants, states, bound variables) and an embedded Playground or Showcase view when it exists.
How it was built
The process was iterative: ask for too much, get something generic, and narrow it down until it respected the real structure of the design system.
I started with foundations only, to lock in the basics: what to ask, how to organize Notion, how to pull tokens without inventing values.
From there came two key adjustments: separate foundations and components because they are not documented the same way, and reduce the number of questions, which created friction. The skill moved to inferring the file’s scope on its own.
On large files, it also stopped re-reading Figma at every step: now it discovers once, saves progress, and fills Notion from that copy.
With stronger rules in place, I tried the skill on a more demanding case: an accordion from a more mature library. New failures showed up there (ignored documentation, raw colors instead of variables), which finished locking in the rules: respect the structure, read the live component, and document only the changes between variants.
Failing was useful because it showed where AI adds speed and where human judgment is still required. Those failures we all know AI tends to make are what led to the next step: the hook.
The hook
A script Cursor runs when the agent finishes a turn, because the AI “finishing” does not mean the documentation is complete. It reads the run summary and writes a message: what looks good, what was not completed, and what remains pending. It only runs when the skill finishes.
Pros and cons
Pros
Speeds up a first documentation draft.
Forces written rules that used to live only in the team’s heads.
Fits a Cursor → human review → Notion workflow.
The hook closes the loop: it documents and says what’s missing.
Cons
Without a well-scoped DS, it invents structure and vocabulary.
Notion embed and sync still need care around permissions and public URLs.
Result
The experiment is documented in Notion: foundations, the Button, and process notes.
It goes beyond “export Figma to Notion”: it is a skill and hook system that documents with real data and, at the end, reviews what was fulfilled and what was not.