\r \r

Figma to Mobile\r

\r Convert Figma designs to mobile UI code with interactive clarification.\r \r Supported: Android Compose, Android XML, iOS SwiftUI, iOS UIKit.\r \r

Prerequisites\r

\r

• FIGMA_TOKEN environment variable set (Figma > Settings > Personal Access Tokens)\r
• Python 3.8+ with requests package\r \r

Trigger & Input\r

\r This skill activates when a user provides a Figma link.\r \r The user may also include inline hints alongside the link, such as:\r

• Target platform: "Android XML", "Compose", "SwiftUI", "UIKit"\r
• Layout preferences: "use ConstraintLayout", "prefer StackView"\r
• Component notes: "the switch is our custom CompactSwitch", "this is a dynamic list"\r
• Any other context about the design\r \r If the user provides hints, respect them and skip the corresponding questions.\r For example, if the user says "Android XML, the 3 cards are a RecyclerView list", do NOT ask about output format or whether the cards are dynamic/static.\r \r

Workflow\r

\r

Step 1: Fetch & Analyze\r

\r When user provides Figma link(s):\r \r

1. Determine the input type:\r \r A. Link without specific node-id (no node-id, or node-id=0-1):\r This link points to the entire page, not a specific frame. Tell the user:\r

   This link points to the whole page. Please select the frame you want in Figma, right-click it, and choose "Copy link to selection", then send that link.\r If you want to convert multiple frames, send multiple links.\r \r B. Single frame link (has specific node-id):\r Run scripts/figma_fetch.py "\x3Curl>" → returns that frame's design data.\r Proceed to analysis.\r \r C. Multiple links (user sends 2+ URLs):\r First, determine the relationship by examining frame names and user context:\r \r

   • Same page, different visual states (e.g. "首页-有banner" and "首页-无banner"): Use --compare mode to fetch all and get a diff summary. Generate multi-state code (conditional visibility, state switching).\r \r
   • Parent page + overlay/drawer (e.g. "首页" + "首页-抽屉-xxx"): Generate each as an independent layout file. Then tell the user the relationship:\r

     Frame 1 ("首页") and Frame 2 ("首页-抽屉") look like a main page + side drawer.\r I've generated two separate layout files. How you wire them together (DrawerLayout, Navigation, etc.) depends on your project architecture.\r \r The Skill's job is generating UI layout code, not deciding architecture (Activity vs Fragment vs Navigation).\r \r

   • Different independent pages (e.g. "首页" + "设置页" + "个人中心"): Process each independently. Fetch them one at a time with a pause between requests to avoid rate limiting. Present a summary of all pages, then ask which to convert first (or convert all sequentially).\r \r
   • Not sure: Ask the user — "These frames look related but I'm not sure how. Are they different states of the same page, a page with an overlay, or independent pages?"\r \r Rate limit protection for multiple links: When fetching multiple nodes, wait 2-3 seconds between requests. Never fire more than 2 requests in parallel.\r \r
2. If the link has no specific node-id, ask the user to re-copy from the specific frame (see A above). Do NOT call the API.\r \r
3. Analyze the structure: identify sections, repeated patterns, component types\r
4. Note INSTANCE nodes — they indicate reusable components. Check variantProperties for component state (e.g. State=Default, Size=Large) — these map to multi-state code\r
5. Note gradient/shadow data — flag for the user if complex\r
6. Apply Figma node interpretation rules before generating code\r \r Detailed interpretation rules: Read references/figma-interpretation.md\r \r

Step 1.5: Structure Summary\r

\r Before asking any questions, present a brief structure summary to the user so they can confirm your understanding:\r \r

I see: [navigation bar with back button + title] → [2 content sections: user profile card, settings list (8 items)] → [bottom action button]. Total ~25 nodes.\r \r Keep it to 2-3 lines. Mention:\r

• Major sections identified (nav bar, content areas, footer)\r
• Repeated patterns ("8 similar list items", "3 tab labels")\r
• Notable elements (gradients, complex illustrations, stacked cards)\r \r If the user says "that's wrong" or corrects the structure, adjust understanding before proceeding to Step 2.\r \r If the structure is simple and obvious (e.g., a single card with a few text fields), skip this step.\r \r

Step 2: Confirm & Clarify\r

\r Question priority (strict order — ask earlier questions first):\r \r

1. Output format (MUST ask first unless user already specified)\r → Android XML / Compose / SwiftUI / UIKit\r This determines all subsequent analysis phrasing and code output.\r \r
2. Structural ambiguities (only ask what you're genuinely unsure about)\r → "These N items look similar — dynamic list or fixed layout?"\r → "This area: single image asset or icon-on-background combo?"\r \r
3. Component choices (only if platform-relevant)\r → "Any custom components to use? (otherwise I'll use platform defaults)"\r \r Rules for questions:\r

• Skip any question the user already answered via inline hints\r
• Max 3-5 questions total, fewer is better\r
• Each question gives concrete options with one-line pros/cons\r
• Every question includes an open option: "or tell me more about this"\r
• Use natural language, no JSON or technical dumps\r
• If everything is clear (user gave full context + simple structure), skip Step 2 entirely\r \r Confidence guide — when to ask vs. when to just generate:\r
• ≥3 sibling nodes with similar structure → likely a list → ASK (dynamic vs static)\r
• INSTANCE nodes sharing same componentId → reusable component → MENTION but can default\r
• Single clear hierarchy, no ambiguity → high confidence → SKIP questions, go to Step 3\r
• Gradient/complex shadow in design → MENTION in summary ("I see a gradient here, I'll approximate it as X")\r \r

Step 2.5: Project Scan (optional but recommended)\r

\r If the target project is available locally, run a project scan:\r \r

python scripts/project_scan.py /path/to/project --json --output scan-report.json\r
```\r
\r
**How to use scan results in code generation**: Read `references/scan-usage.md`\r
\r
### Step 3: Generate Code\r
\r
After user confirms (or if no questions needed), generate code files.\r
\r
**Detailed generation rules**: Read `references/generation-rules.md`\r
\r
If multiple files are needed, output each with a clear filename header:\r
```\r
📄 activity_notification_settings.xml\r
[code]\r
\r
📄 item_expert_notification.xml\r
[code]\r
```\r
\r
### Step 4: Iterate & Capture Feedback\r
\r
After showing code, ask briefly:\r
> Matches the design? Any adjustments?\r
\r
**The user can then give feedback to refine the output.** Common iterations:\r
- "间距大了" → adjust specific spacing\r
- "Switch 换成我们的 CustomSwitch" → swap component\r
- "把标题栏去掉" → remove section\r
- "换成 Compose 版本" → regenerate in different format\r
- "颜色不对，这里应该是 #333333" → fix specific values\r
\r
Continue iterating until the user is satisfied. Each round only regenerates the changed parts, not the entire file (unless the user asks for full regeneration).\r
\r
**Feedback capture (automatic):**\r
Whenever the user corrects your generated output, log the correction to `feedback-log.md` in the project root (create if it doesn't exist). Each entry follows this format:\r
\r
```\r
## YYYY-MM-DD HH:MM\r
- **Platform**: Android XML / Compose / SwiftUI / UIKit\r
- **Figma node type**: (e.g., FRAME with icon, Tab bar, Button group)\r
- **Issue**: Brief description of what was wrong\r
- **Before**: What the agent generated (snippet or description)\r
- **After**: What the user wanted (snippet or description)\r
- **Rule candidate**: (optional) If this correction suggests a general pattern rule, note it here\r
```\r
\r
Log entries should be:\r
- **Concise** — only the relevant diff, not entire files\r
- **Categorized** — always include platform and Figma node type for later analysis\r
- **Actionable** — focus on the mapping error, not cosmetic preferences (e.g., "user prefers 16dp" is not a rule; "VECTOR compositions should be single ImageView" is)\r
\r
Do NOT log:\r
- One-off personal preferences (specific color choices, naming conventions)\r
- Corrections to non-mapping issues (typos, import statements)\r
- Feedback the user explicitly says is project-specific, not general\r
\r
Periodically (or when asked), run `scripts/feedback_analyze.py` to identify patterns and generate rule candidates.\r
\r
## Error Handling\r
\r
- **FIGMA_TOKEN not set** (script outputs `FIGMA_TOKEN_NOT_SET`) → do NOT ask user to run commands. Instead:\r
  1. Tell the user you need a Figma Personal Access Token\r
  2. Tell them where to get it: Figma → avatar (top-left) → Settings → Security → Personal Access Tokens\r
  3. Ask them to paste the token in chat\r
  4. Once they provide it (starts with `figd_`), write it to the project root `.env` file: `echo 'FIGMA_TOKEN=figd_xxx' >> .env`\r
  5. Retry the figma_fetch command — it will read from `.env` automatically\r
- **FIGMA_TOKEN invalid** (API returns 403/401) → token may have expired or been revoked. Ask user to regenerate and paste new token. Update `.env` file.\r
- **Invalid URL** → show valid URL example: `https://www.figma.com/design/\x3CfileKey>/\x3Cname>?node-id=\x3Cid>`\r
- **API error** → show error message, suggest checking network/proxy\r
- **Node too large (>200 children)** → suggest selecting a smaller frame\r
- **Depth auto-increased** → the script auto-retries with deeper depth if it detects truncated children. Inform user if this happens ("I needed to fetch deeper to get all details").\r