About figma-swiftui
A routing skill for translating between Figma designs and SwiftUI code in either direction. It directs work to the relevant reference and provides shared guidance for reading Figma context and mapping iOS design patterns.
Key features
- 01Route design-to-code and code-to-design tasks
- 02Clarify ambiguous translation direction
- 03Read Figma structure with `get_design_context`
- 04Map iOS semantic colors and SF Symbols
- 05Recognize common iOS interface patterns
Use cases
- 01Build SwiftUI screens from Figma frames
- 02Send SwiftUI views or tokens to Figma
- 03Resolve ambiguous Figma and Swift file requests
MCP support
Uses Figma MCP's `get_design_context` to read design structure, with Swift and SwiftUI specified as the client language and framework. For code-to-design work, it directs use of `use_figma` after loading the stated skills.
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/figma-swiftuiin Claude Code to confirm it loaded.
Bundled filesreferences/code-to-design.mdreferences/design-to-code.md
Details
From the project READMEFigma ↔ SwiftUI
Translation between Figma designs and SwiftUI code, both directions. This file is a router — actual guidance lives in the references below.
Pick the direction
| Direction | Trigger | Reference |
|---|---|---|
| Design → code | User wants SwiftUI in their iOS project from a Figma file/frame | references/design-to-code.md |
| Code → design | User wants to push SwiftUI views / screens / tokens into a Figma file | references/code-to-design.md |
If the request is ambiguous — a Figma URL and .swift files both present, no verb makes it clear — ask the user which direction before loading a reference.
Shared context (applies to both directions)
These points hold regardless of direction; the direction-specific references assume them.
get_design_contextis the read tool for Figma. PassclientLanguages: "swift"andclientFrameworks: "swiftui"so the response is framed as Swift. URL → tool args:figma.com/design/:fileKey/:fileName?node-id=:nodeId→ usefileKey, replace-with:innodeId. Forfigma.com/design/:fileKey/branch/:branchKey/:fileName, usebranchKeyasfileKey.- The React+Tailwind in
get_design_contextoutput is a structural reference, not a literal source. It approximates the visual. Never transliterateposition: absolute/ pixel frames /mix-blend-modestacks into SwiftUI or into Figma — the screenshot is the source of truth in both directions. - iOS HIG semantic colors are tokens, not hex.
var(--backgrounds/primary, …),var(--labels/secondary, …),var(--separators/non-opaque, …)etc. map toColor(.systemBackground),Color.secondary,Color(.separator)in SwiftUI, and to variables in a semantic collection in Figma. Keep the mapping; drop the literal RGBA. - SF Symbols round-trip by name in both directions — never by codepoint. Design → code:
get_design_contextsubstitutes Figma's SF Symbol glyph runs back into<SFSymbol>{Image(systemName: "...")}</SFSymbol>wrappers in the response. Use those names verbatim. Code → design: callfigma.util.getSfSymbolCharacter(name)insideuse_figmato convert a symbol name to the matching character — never look up codepoints by hand. - Recognize the underlying iOS pattern, not the literal node / view name. The same patterns recur in both directions: large title + back chevron + trailing action =
NavigationStackchrome; bottom row of icon+label pairs =TabView; repeating same-height rows with leading/trailing chrome =List. Match those system patterns rather than rebuilding them from primitives. - For code → design,
use_figmais the API. Always loadfigma-usebefore anyuse_figmacall. If the task involves building a full screen, also loadfigma-generate-design; if it involves building components or a design system, also loadfigma-generate-library.
References
| Doc | When to load |
|---|---|
| references/design-to-code.md | Translating a Figma design / frame into SwiftUI |
| references/code-to-design.md | Pushing SwiftUI views / screens / tokens into Figma |