Figma → Android XML High-Fidelity Implementation

Use this skill when the user asks to implement, restore, convert, review, or refine Android XML View-system UI from a Figma design, especially when they care about high visual fidelity.

This skill is not a one-shot Figma-to-code generator. It enforces this workflow:

1. Read and normalize the Figma design.
2. Extract Android resources and component mappings.
3. Generate resources first.
4. Generate XML layout second.
5. Add only the minimal Kotlin/ViewBinding code needed.
6. Validate with build/lint when possible.
7. Iterate using screenshot differences.

Do not switch to Jetpack Compose unless the user explicitly asks.

Core Principles

• Treat Figma as a design specification, not as absolute-positioned code.
• Prefer Android resource references over hardcoded values.
• Prefer ConstraintLayout for complex screens and shallow hierarchy.
• Preserve spacing, typography, corner radius, image scale type, component states, and system-bar assumptions.
• Never hide uncertainty. If Figma data, assets, fonts, or states are missing, state the gap and choose the least risky implementation.
• Do not generate a giant final layout before producing the design specification and resource plan.

Required First Step

Before editing files, inspect the project and the Figma input.

Project inspection

Check, as available:

• Gradle modules and Android plugin setup.
• Whether the screen uses Activity, Fragment, ViewBinding, DataBinding, or legacy manual binding.
• Existing res/values/colors.xml, dimens.xml, styles.xml, themes.xml, strings.xml.
• Existing custom widgets, base layouts, adapters, drawable naming conventions, and typography resources.
• ConstraintLayout, RecyclerView, AppCompat, and Material Components availability.
• minSdk, targetSdk, and whether edge-to-edge / WindowInsets handling is already present.

Figma inspection

Use configured Figma MCP tools when available. Read, if possible:

• design context
• metadata
• variables / styles
• component names and variants
• selected frame screenshot
• asset export information

If Figma MCP is unavailable or incomplete, use any provided screenshot/specs and mark missing values as assumptions. Do not invent exact colors, fonts, or dimensions when they are not available.

Output Gate 1: Design Spec Report

Before writing code, output a concise implementation report with these sections:

1. Target screen

   • Frame name and size
   • Android baseline width assumption, for example 360dp, 375dp, 390dp, 393dp, or project-defined width
   • Whether the Figma frame includes status bar / navigation bar
   • Scroll behavior

2. Resource tokens

   • Colors → proposed @color/... names
   • Spacing → proposed @dimen/space_* names
   • Sizes → heights, widths, icon sizes, image sizes
   • Radius → proposed @dimen/radius_* names
   • Typography → text appearances, font family, size, weight, line height, letter spacing
   • Elevation / shadow approximation

3. Layout structure

   • Root layout choice
   • Major sections
   • Reusable item layouts
   • RecyclerView / ScrollView / NestedScrollView decisions

4. Component mapping

   • Figma Button/Input/Card/TopBar/ListItem/etc. → Android view or custom component
   • States: default, pressed, disabled, selected, error, loading

5. Assets

   • Images to export
   • Icons to convert to VectorDrawable
   • Image scale type: centerCrop, fitCenter, centerInside, etc.

6. Risks / assumptions

   • Missing fonts
   • Unknown system bars
   • Unknown responsive behavior
   • Missing states
   • Ambiguous image crop or shadow

Only after this report should implementation begin.

Implementation Order

Phase 1: Resources first

Create or update resources before page XML:

• res/values/colors.xml
• res/values/dimens.xml
• res/values/styles.xml
• res/values/strings.xml when static strings are needed
• res/drawable/bg_*.xml shape drawables
• res/drawable/selector_*.xml state selectors
• res/drawable/ic_*.xml vector drawables when icons are available

Rules:

• All colors must be referenced through @color/....
• All layout dimensions, margins, paddings, icon sizes, corner radii, and text sizes must be referenced through @dimen/..., unless the project convention intentionally keeps common values inline.
• Use clear token names, not Figma layer names.
• Reuse existing resources if semantically equivalent.
• Do not duplicate near-identical colors or dimens without explaining why.

Recommended naming:

<color name="color_bg_page">#FFFFFF</color>
<color name="color_text_primary">#111827</color>
<color name="color_text_secondary">#6B7280</color>
<color name="color_brand_primary">#2563EB</color>

<dimen name="space_4">4dp</dimen>
<dimen name="space_8">8dp</dimen>
<dimen name="space_12">12dp</dimen>
<dimen name="space_16">16dp</dimen>
<dimen name="radius_12">12dp</dimen>
<dimen name="height_button_48">48dp</dimen>
<dimen name="text_size_16">16sp</dimen>
<dimen name="line_height_24">24sp</dimen>

Phase 2: Text styles

Define reusable text styles in styles.xml when the project has no better convention.

Use TextAppearance.App.* for reusable text appearances and Widget.App.* for widgets/components.

Text fidelity rules:

• Set android:includeFontPadding="false" unless the project convention or design requires default font padding.
• Preserve fontFamily, textSize, lineHeight, textColor, textStyle, and letterSpacing when available.
• If exact font files are missing, use the closest available font and explicitly report the gap.
• For multi-line text, preserve line height and max lines when specified.

Example:

<style name="TextAppearance.App.Title20">
    <item name="android:fontFamily">@font/inter_semibold</item>
    <item name="android:textSize">@dimen/text_size_20</item>
    <item name="android:textColor">@color/color_text_primary</item>
    <item name="android:includeFontPadding">false</item>
</style>

Phase 3: Drawable and selector resources

For Figma fills, strokes, and corners, create shape drawables:

<shape xmlns:android="http://schemas.android.com/apk/res/android">
    <solid android:color="@color/color_bg_card" />
    <corners android:radius="@dimen/radius_16" />
    <stroke
        android:width="@dimen/stroke_1"
        android:color="@color/color_border_default" />
</shape>

For buttons and stateful components, use selectors rather than runtime hacks:

• selector_button_primary.xml
• selector_input_border.xml
• selector_card_background.xml

Approximate Figma shadows carefully. XML View shadows are limited; use elevation for Material-like shadows, drawable layers for simple shadows, or document that an exact shadow requires a custom drawable/view.

Phase 4: Layout XML

Use ConstraintLayout as the default root for complex screens.

Layout rules:

• Root screen: usually android:layout_width="match_parent" and android:layout_height="match_parent".
• Inside ConstraintLayout, use 0dp for dimensions that should stretch between constraints. Do not use child match_parent inside ConstraintLayout unless there is a project-specific reason.
• Use wrap_content for text height unless fixed height is explicitly required.
• Avoid translating Figma absolute x/y positions into a pile of fixed margins.
• Avoid excessive nested LinearLayout hierarchies.
• Use LinearLayout only for simple vertical/horizontal groups where it improves clarity.
• Use FrameLayout for overlays, badges, scrims, or stacked content.
• Use RecyclerView for repeating content and create separate item_*.xml files.
• Use NestedScrollView only when the whole page scrolls and there is no large/repeating list.
• Add tools: preview attributes for design-time content, not runtime behavior.
• Keep IDs meaningful: titleText, primaryButton, bannerImage, contentRecyclerView.

Constraint rules