flutter-figma-handoff
Skill1 starsChanged 39 days agoMITView on GitHub
Turns a Material 3 Figma handoff into Flutter code — variables into a seeded ColorScheme, components mapped to widgets. Triggers: 'implement this Figma screen in our Flutter app', 'sync the app theme with Figma'.
In this repository23 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- harness-auditSkill
- skill-benchSkill
- ask-biginSkill
- bigin-harness-setupSkill
- contract-syncSkill
- debug-workflowSkill
- discovery-workflowSkill
- epic-workflowSkill
- go-scaffoldSkill
- knowledge-distillSkill
- model-routerSkill
- napkinSkill
- next-scaffoldSkill
- nodejs-scaffoldSkill
- nuxt-marketing-scaffoldSkill
- nuxt-scaffoldSkill
- nuxt-ui-figma-handoffSkill
- project-scaffoldSkill
- session-handoffSkill
- sprint-distillSkill
- task-workflowSkill
- write-testsSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 33
Use the Figma MCP tools (search for them via ToolSearch if deferred) against the URL to pull the node's local variables and …
- Very specific: line 39
Look each one up in references/flutter-mapping.md.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
flutter-figma-handoff
Design and mobile dev share one base: Google's Material 3 Design Kit on Figma Community, which is the same design system Flutter's widgets implement. Nothing is forked and nothing is authored — the kit is the shared vocabulary, and this skill resolves a frame built from it into widgets that already exist.
When not to use
- A frame not built from the M3 kit. Free-drawn UI has nothing to resolve against; that's a plain design-to-code task, and the honest answer is to say so rather than guess which widget was meant.
- Nuxt UI / web work — that's
nuxt-ui-figma-handoff, a separate skill with a separate theme model. - Cupertino or a custom design system. Out of scope, per
references/flutter-mapping.md.
Step 1: Get the Figma link and the Flutter version
This needs a real Figma file or frame URL, not a description of it — the URL is what resolves the actual node's variables and component variants instead of inferring them secondhand. If the user hasn't given one, ask before doing anything else.
Then read the version the repo pins:
flutter --versionBoth matter, and the second is the one people skip. The kit tracks the Material spec, which runs ahead of the framework, so a component can exist in Figma a year before its widget ships. Every mapping decision below is relative to this version.
Step 2: Read the design
Use the Figma MCP tools (search for them via ToolSearch if deferred) against the URL to pull the node's local variables and component/variant names. That is ground truth; prefer it over reading a screenshot.
If the connector isn't authorized, say so plainly and offer the fallback rather than stalling: an exported variables JSON plus the component names, or screenshots plus a written list of which kit components each frame uses. Ask for the URL either way — it's useful context even when the MCP can't reach it.
Step 3: Resolve every component
Look each one up in references/flutter-mapping.md.
A component with no row is a stop, not a judgement call. Report the component name, the Flutter version you checked against, and the two ways forward: redraw with a component that maps, or accept a hand-built widget as a deliberate exception recorded in the ADR. Never quietly build a custom-painted lookalike — that is the failure this skill exists to prevent, and it looks like success right up until the design system moves.
Step 4: Emit the theme
Tokens go through the seeded scheme, not a hand-written ColorScheme:
node ${CLAUDE_SKILL_DIR}/scripts/emit_theme.mjs --seed '#6750A4' \
[--overrides tokens.json] [--font 'Inter'] [--out lib/core/design/app_theme.dart]tokens.json is { "light": { "<role>": "#rrggbb", ... }, "dark": { ... } }, using Flutter's own ColorScheme role names. The script rejects an unknown role rather than dropping it — a silently ignored token is a design that quietly didn't apply — and rejects the three roles Flutter retired in 3.22, naming the replacement.
Seed plus explicit overrides, deliberately. The design side owes one seed colour and only the roles it genuinely diverges on; Flutter derives the rest. The trade is real and worth saying out loud in your summary: changing the seed moves roles nobody edited. That is correct behaviour, not a regression — and it is why the emitted file has a fixed role order, so the diff stays reviewable.
Step 5: Build the screen
Compose the mapped widgets. Two rules from the Flutter profile that this step must not break:
- Theme values come from
Theme.of(context).colorScheme, never a hardcodedColor(0x...)in a widget. The emitted file is the only place colours are literal. - Widgets live in
features/<feature>/presentation/; the theme lives incore/design/. A screen does not reach into another feature's presentation layer.
Step 6: Summarize
Say four things, and don't skip the third:
- Which components were mapped, and to which widgets.
- What the theme emitter wrote, and how many explicit overrides there were.
- Anything that did not map, and what you did about it.
- That a seed change produces a wide theme diff by design, if the seed changed.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

