Skip to main contentfigma-to-compose
Figmaデザインから高精度Jetpack Composeコードを生成するスキル。推測を排除し、Figma APIから正確な値を取得することで、95%以上の準拠率を実現。バイブコーディングを禁止し、Figma仕様に忠実な実装を保証する。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Un comando directo omite el prompt de revisión. Revisa el origen antes de ejecutarlo.
npx skills add https://github.com/xtone/ai_development_tools --skill figma-to-composeEl comando permanece en una sola línea. Desplázate horizontalmente para revisarlo antes de copiarlo.
¿Prefieres una copia local? Descarga los archivos que SkillsMP tiene disponibles ahora.
SOC
Basado en la clasificación ocupacional SOC
Explorador de archivos
7 archivos| name | figma-to-compose |
| description | Figmaデザインから高精度Jetpack Composeコードを生成するスキル。推測を排除し、Figma APIから正確な値を取得することで、95%以上の準拠率を実現。バイブコーディングを禁止し、Figma仕様に忠実な実装を保証する。 |
Figma To Compose - 高精度UI生成スキル
目的
FigmaデザインからJetpack Composeコードを95%以上の準拠率で自動生成する。
推測を完全に排除し、Figma APIから取得した正確な値のみを使用することで、デザイナーの意図を100%反映した実装を実現する。
使用タイミング
このスキルは以下の場合に自動的に起動する：
- ユーザーがFigma URLを提供した時
- "Figmaから〜を生成"、"Compose画面を作成"のような指示があった時
/figma-to-compose コマンドが実行された時
核心原則：推測とバイブコーディングの完全禁止
絶対禁止事項
1. 推測による実装の禁止
❌ 悪い例：デザインを見て「8dpくらいだろう」と推測
RoundedCornerShape(8.dp)
✅ 良い例：get_code でFigmaから正確な値を取得
RoundedCornerShape(4.dp)
2. バイブコーディングの禁止
バイブコーディングとは：Figmaで明示的に指定されていない要素を勝手に追加・変更する行為
❌ 禁止される行為：
- Figmaで指定されていない角丸を勝手に追加
- Figmaで指定されていない文字サイズの変更
- Figmaで指定されていないレイアウト調整
- Figmaで指定されていないColor/Padding/Marginの追加
- 「見た目が良いから」という理由での独自改変
✅ 正しい実装：
- Figmaで明示的に指定された部分のみを実装
- 仕様が不明な場合は、ユーザーに確認を求める
- 全ての値がFigma由来であることを証明できる状態を保つ
3. 魔法の数字（ハードコード値）の禁止
❌ 悪い例：
val dividerStartPadding = 92.dp
private object LayoutDimensions {
val imagePadding = 10.dp
val imageWidth = 72.dp
val imageSpacing = 10.dp
val dividerStartPadding = imagePadding + imageWidth + imageSpacing
}
4. Figma要素の省略禁止
省略とは：Figmaに存在する要素を「不要」と判断して実装しないこと
- Figmaに存在する要素を「不要」と判断して省略する
- 「システムUIが描画する」という理由で空間を確保しない
- 「見た目に影響しない」という理由でスペーサーを省略する
- Figmaの全ての要素に対応するCompose要素を作成
- 描画しない要素でも、スペースは確保する
- 不明な場合はユーザーに確認を求める
Spacer(modifier = Modifier.height(52.dp))
❌
Column(modifier = Modifier.fillMaxSize()) {
LockScreenClock(...)
}
✅
Column(modifier = Modifier.fillMaxSize()) {
Spacer(modifier = Modifier.height(52.dp))
LockScreenClock(...)
}
5. 固定サイズ優先の原則
Flexboxのgrow/shrinkより、Figmaから直接取得した固定値を優先する。
❌ 悪い例：grow/shrinkをweight()に変換
Column {
Box(modifier = Modifier.weight(1f)) { Cards() }
Surface { MessageArea() }
}
✅ 良い例：スクリーンショットから実測して固定値を使用
Column {
Box(modifier = Modifier.weight(1f)) { Cards() }
Surface(modifier = Modifier.height(264.dp)) { MessageArea() }
}
- Figmaコードの
pb-[24px]等の値と、スクリーンショットの実際の見た目が異なる場合がある
growによってスペースが拡張されている可能性- スクリーンショットからピクセル計測して検証する
6. padding位置の注意
Surfaceの背景を端まで伸ばす場合、paddingの位置に注意。
❌ 悪い例：Surfaceの外側にpadding → 背景が途切れる
Surface(
modifier = Modifier
.fillMaxWidth()
.padding(bottom = 24.dp)
) {
Content()
}
✅ 良い例：内側でpadding調整 → 背景が端まで伸びる
Surface(
modifier = Modifier.fillMaxWidth()
) {
Column(
modifier = Modifier.padding(bottom = 24.dp)
) {
Content()
}
}
実行フロー（必須順序）
Phase 0: 既存コードベースの確認（Figma確認前・必須）
重要: Figmaデータを取得する前に、プロジェクトの既存実装を必ず確認する。
この手順を省略すると、既存の共通コンポーネントや確立されたパターンを無視した実装になるリスクがある。
Step 0-1: 類似コンポーネントの検索
Grep: "AppScreen" or "Screen" in ui/
Grep: "[ComponentName]" similar patterns
Grep: "AppScreen" → ImageBasedAppScreen, WebViewAppScreenなどを発見
Step 0-2: 共通コンポーネントの確認
以下のシステムUI要素は、ほぼ確実に共通コンポーネントが存在する：
| 要素 | 検索パターン | よくある場所 |
|---|
| ステータスバー | StatusBar | ui/components/ |
| ナビゲーションバー | NavigationBar, BottomBar | ui/components/ |
| ツールバー | Toolbar, TopBar | ui/components/ |
| ローディング | Loading, Progress | ui/components/ |
Grep: "StatusBar" in ui/components/
ls ui/components/
Step 0-3: 既存パターンの踏襲
同種の画面（例：XxxAppScreen）が存在する場合、必ずそのパターンを踏襲する：
fun ExistingAppScreen(
onBack: () -> Unit,
onUserInteraction: () -> Unit = {},
overlayMode: Boolean = false
)
fun NewAppScreen(
onBack: () -> Unit,
onUserInteraction: () -> Unit = {},
overlayMode: Boolean = false
)
Step 0-4: 動作仕様の確認（Figmaに表現されない仕様）
Figmaはビジュアルのみを表現する。以下の動作仕様は既存コードから確認：
| 仕様タイプ | 確認方法 | 例 |
|---|
| ナビゲーション | 類似画面のパラメータ確認 | onBack, overlayMode |
| ジェスチャー | 類似画面の実装確認 | スワイプで戻る、ドラッグ操作 |
| アニメーション | 遷移処理の確認 | フェードイン、スライド |
| 状態管理 | ViewModel/StateHolderの確認 | UiState、イベント処理 |
SwipeToDismissBox(
state = dismissState,
onDismissed = onBack,
...
)
Phase 1: Figma仕様の抽出（効果測定の基盤）
Step 1-1: URL解析
入力例：https://www.figma.com/design/[file-id]?node-id=[node-id]&m=dev
抽出：
- file-id: デザインファイルID
- node-id: コンポーネントID（例：29434-393401）
Step 1-2: Figma MCP Tools呼び出し（必須順序）
重要: このスキルは Figma MCP Tools を使用することを前提としています。
-
get_code - 最優先・必須：正確な値とスタイル情報の取得
Tool: get_code
Parameters:
node_url: https://www.figma.com/design/[file-id]?node-id=[node-id]
-
get_image - 推奨：ビジュアル確認
Tool: get_image
Parameters:
node_url: https://www.figma.com/design/[file-id]?node-id=[node-id]
-
get_metadata - 任意：ノード構造の概要把握
Tool: get_metadata
Parameters:
node_url: https://www.figma.com/design/[file-id]?node-id=[node-id]
-
親コンテナの確認 - 必須：レイアウト文脈の把握
コンポーネント単体だけでなく、親ノードも必ず確認する
親のgap、grow、shrinkが子要素のレイアウトに影響する
- ✅ Figma MCP Toolsがメインアプローチ
- ✅
get_code を省略してはならない（準拠率95%以上の鍵）
- ✅ 親コンテナも必ず確認（gap、grow、shrinkの影響を把握）
- ⚠️ MCP接続失敗時のみ、直接API呼び出しにフォールバック（詳細は
references/figma-api-patterns.md 参照）
❌ コンポーネント単体（node-id: 21:3665）だけ見て実装
→ 親コンテナ（node-id: 21:3294）のgap-[64px]を見落とし
→ レイアウトが崩れた
✅ 親ノードもget_codeで確認
→ 親のgap: 64px、子のgrow/shrink設定を把握
→ 正確なレイアウト実装
Step 1-3: Figma仕様レポートの生成
## Figma Design Specification Report
### Node: [Component Name] ([node-id])
### Generated: [timestamp]
#### Colors (Figma仕様)
- primaryColor: rgba(0,116,196,1.0) → Color(0xFF0074C4)
- secondaryColor: rgba(102,102,102,1.0) → Color(0xFF666666)
- backgroundColor: rgba(245,245,245,1.0) → Color(0xFFF5F5F5)
#### Typography (Figma仕様)
- titleText: fontSize=17px, fontWeight=700, lineHeight=1.35
- bodyText: fontSize=15px, fontWeight=500, lineHeight=1.4
#### Layout (Figma仕様)
- padding: 20px → 20.dp
- cornerRadius: 4px → 4.dp
- gap: 10px → 10.dp
このレポートは効果測定のBefore/After比較に使用される。
Phase 2: 検証（推測・バイブコーディングの排除）
チェックリスト
コードとスクリーンショットの照合（重要）
Figmaコードの値と、スクリーンショットの実際の見た目が異なる場合がある。
Figmaコード: pb-[24px]
スクリーンショット: ボタン下のスペースがもっと大きい
原因: growによってスペースが拡張されている
- スクリーンショットからピクセル計測して検証
- 乖離がある場合は実測値を優先
- 固定値（例:
height(264.dp)）で実装
ユーザーに確認：
"Figmaで[要素名]の[プロパティ]が確認できませんでした。
以下のいずれかをお選びください：
1. Figmaで該当箇所を確認して値を教えてください
2. この要素は実装しない（Figma仕様外のため）
3. デフォルト値を使用（Material Design 3準拠）"
Phase 3: Compose生成
注意: システムUI要素の扱い
Figmaデザインにはしばしばステータスバー、ナビゲーションバーなどのシステムUI要素が含まれます。これらは：
- 描画: システムが行うため、Compose側での描画は不要
- スペース: 必ず確保する（Spacer または padding）
Spacer(modifier = Modifier.height(52.dp))
この処理を省略すると、後続のコンテンツが上に詰まり、デザインとの不一致が発生します。
Step 3-1: Color定数生成
Figma仕様のrgba値をAndroid Color形式に変換：
object [ComponentName]Colors {
val primaryColor = Color(0xFF0074C4)
val secondaryColor = Color(0xFF666666)
val backgroundColor = Color(0xFFF5F5F5)
}
rgba(R, G, B, A) → Color(0xAARRGGBB)
例：rgba(0,116,196,1.0) → Color(0xFF0074C4)
↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑
R G B A A R G B
Step 3-2: Typography定数生成
Figma仕様のフォント設定をTextStyleに変換：
object [ComponentName]Typography {
val titleText = TextStyle(
fontSize = 17.sp,
fontWeight = FontWeight.Bold,
lineHeight = 22.95.sp
)
val bodyText = TextStyle(
fontSize = 15.sp,
fontWeight = FontWeight.Medium,
lineHeight = 21.sp
)
}
Figma fontWeight → Compose FontWeight
100 → FontWeight.Thin
200 → FontWeight.ExtraLight
300 → FontWeight.Light
400 → FontWeight.Normal
500 → FontWeight.Medium
600 → FontWeight.SemiBold
700 → FontWeight.Bold
800 → FontWeight.ExtraBold
900 → FontWeight.Black
Step 3-3: Layout定数生成（計算式ベース）
private object LayoutDimensions {
val imagePadding = 10.dp
val imageWidth = 72.dp
val imageSpacing = 10.dp
val cornerRadius = 4.dp
val dividerStartPadding = imagePadding + imageWidth + imageSpacing
}
Step 3-4: Composable関数生成
@Composable
fun [ComponentName](
modifier: Modifier = Modifier
) {
Card(
modifier = modifier,
shape = RoundedCornerShape(LayoutDimensions.cornerRadius),
colors = CardDefaults.cardColors(
containerColor = [ComponentName]Colors.backgroundColor
)
) {
Row(
modifier = Modifier.padding(LayoutDimensions.imagePadding),
horizontalArrangement = Arrangement.spacedBy(LayoutDimensions.imageSpacing)
) {
}
}
}
@Preview
@Composable
private fun [ComponentName]Preview() {
MaterialTheme {
[ComponentName]()
}
}
Step 3-5: SVGアセットのインポート
複雑なSVG（グラデーション、複数パス、クリップパス等）は手動変換を避け、Android Studioの機能を使用する。
推奨: Android Studio の New Vector Asset を使用
手順:
1. FigmaからSVGをエクスポート
2. Android Studio → File → New → Vector Asset
3. Local file → SVGを選択 → インポート
- パス変換ミスを防止
- グラデーション（
<aapt:attr>）の自動生成
- クリップパスの正確な変換
- 座標系の自動調整
- 単純な図形（矩形、円、単一パスの三角形など）
- 動的に色を変更する必要がある場合
- 複雑なSVGパスを目視で手動変換する
- 座標系の変換を推測で行う
❌ 三角形のSVGパス M12 20L0 0H24L12 20Z を
誤って M12,0L24,20H0L12,0Z に変換
→ 吹き出しのしっぽが上下逆になった
✅ Android Studio の Vector Asset でインポート
→ 正確なパス変換を保証
Phase 4: 準拠率レポート生成
生成したComposeコードとFigma仕様を照合：
## Implementation Compliance Report
### Component: [ComponentName]
### Generated: [timestamp]
#### Color Compliance: 100% ✅
- primaryColor: ✅ Color(0xFF0074C4) (Figma一致)
- secondaryColor: ✅ Color(0xFF666666) (Figma一致)
- backgroundColor: ✅ Color(0xFFF5F5F5) (Figma一致)
#### Typography Compliance: 100% ✅
- titleText: ✅ 17.sp, FontWeight.Bold, lineHeight=22.95.sp (Figma一致)
- bodyText: ✅ 15.sp, FontWeight.Medium, lineHeight=21.sp (Figma一致)
#### Layout Compliance: 100% ✅
- padding: ✅ 10.dp (Figma一致)
- cornerRadius: ✅ 4.dp (Figma一致)
- gap: ✅ 10.dp (Figma一致)
#### Unauthorized Elements: 0 ✅
- 勝手な角丸追加: なし
- 勝手なサイズ変更: なし
- Figma未指定の要素追加: なし
### Overall Compliance Score: 100%
デザイントークンの解釈
CSS → Android Compose変換ルール
padding: 20px;
border-radius: 4px;
font-size: 15px;
line-height: 1.35;
gap: 10px;
.padding(20.dp)
.rounded(4.dp)
fontSize = 15.sp
lineHeight = 20.25.sp // 15 * 1.35
Arrangement.spacedBy(10.dp)
よくある間違いと対策
1. 角丸（Corner Radius）のハルシネーション
問題：デザインを見て「これは8dpくらい」と推測してしまう
- 必ず
get_code でFigmaの実際の値を確認
rounded-[Npx] または border-radius: Npx の記述を探す- 不明な場合は再度Figmaデータを問い合わせる
❌ shape = RoundedCornerShape(8.dp)
✅ shape = RoundedCornerShape(4.dp)
2. スペーシング値の不正確さ
gap-N、p-N、padding: Npx などのCSSクラスを確認get_code で正確な値を読み取る
3. フォントサイズとline-heightの計算ミス
fontSize = 15.sp
lineHeight = (15 * 1.35).sp
実装パターン（ベストプラクティス）
dividerの実装パターン
if (isLastItem) {
HorizontalDivider(
color = colors.divider,
thickness = 1.dp,
)
} else {
Box(
modifier = Modifier
.fillMaxWidth()
.padding(start = LayoutDimensions.textStartPosition)
) {
HorizontalDivider(
color = colors.divider,
thickness = 1.dp,
)
}
}
検証手順
1. Figmaデータの取得と検証
2. 実装後の確認
トラブルシューティング
Q: Figmaの値が不明確な場合
A: より大きなコンポーネントや親要素の get_code (MCP Tool) を実行して文脈を取得
Q: 複雑なレイアウトの実装方針が分からない場合
A: 既存の類似コンポーネントのパターンを参考にする
Q: デザインとプレビューが一致しない場合
A: Figmaの get_image (MCP Tool) とプレビューの並列表示で詳細比較
Q: Figma MCP接続が失敗する場合
- MCP接続確認: Claude Code MCPの状態を確認
- フォールバック: 直接API呼び出しに切り替え（詳細は
references/figma-api-patterns.md 参照）
注意: 基本的にはFigma MCP Toolsを使用してください。直接APIアクセスはMCP接続失敗時の代替手段です。
Q: ステータスバーやナビゲーションバーなどのシステムUI要素がある場合
A: 描画は省略可能だが、スペースは必ず確保する。
- ❌ 完全に省略 → レイアウトが崩れる（後続コンテンツが上に詰まる）
- ✅
Spacer(52.dp) でスペース確保 → レイアウト維持
Column(modifier = Modifier.fillMaxSize()) {
Spacer(modifier = Modifier.height(52.dp))
MainContent(...)
}
効果測定
Before（口頭指示）vs After（スキル使用）の比較
口頭指示: "〇〇画面のArticleCardを作って"
→ 生成されたCompose
→ Figma仕様との差分を計算
→ 準拠率: 例えば60%
/figma-to-compose https://figma.com/.../node-id=29434-393401
→ 生成されたCompose
→ Figma仕様との差分を計算
→ 準拠率: 目標95%以上
準拠率の計算方法
詳細は scripts/compliance-calculator.py を参照。
準拠率 = (Figma一致項目数 / Figma仕様項目総数) × 100
項目例：
- Color値の一致
- フォントサイズの一致
- fontWeightの一致
- line-heightの一致
- paddingの一致
- marginの一致
- corner radiusの一致
- レイアウト構造の一致
段階的精度向上
Phase 1（初期実装）: 基本的な値の正確性
- Color/Typography/Layoutの正確な変換
- 目標準拠率: 80%
Phase 2（改善）: 構造の忠実性
Phase 3（最適化）: エッジケース対応
- dividerパターン、条件分岐等
- 目標準拠率: 95%以上
まとめ
- 推測禁止：必ずFigmaから正確な値を取得
- バイブコーディング禁止：Figma仕様外の要素を追加しない
- 段階的アプローチ：get_code → 検証 → 生成 → レポート
- 相対レイアウト：ハードコード値ではなく計算式ベースの実装
- 効果測定：準拠率レポートで品質を可視化
- 検証徹底：実装後のビジュアル確認を怠らない
これらのプラクティスに従うことで、Figmaデザインに正確に準拠した高品質なUI実装が可能になる。
互換性
Agent Skills (Open Standard)
- Claude Code ✅
- GitHub Copilot ✅
- VS Code ✅
- Cursor (Nightly) ✅
- OpenAI Codex ✅
.claude/skills/ ディレクトリに配置することで、上記すべてのツールで使用可能です。
更新履歴
| 日付 | 内容 |
|---|
| 2026-01-06 | Phase 0（既存コードベース確認）追加、チェックリスト強化（docomo-home-ui-mock FB反映） |
| 2025-12-23 | Agent Skills対応（互換性セクション追加） |
| 2025-12-XX | 初版作成 |
