菜单
Figma MCP サーバーの公式知識ベース。get_design_context や get_screenshot 等のツール仕様、デザインコンテキスト取得、セットアップ、Flutter プロジェクト固有ルール（デザイントークン、フォント、アセット管理）を参照したい時に使用する。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | figma-mcp-guide |
| description | Figma MCP サーバーの公式知識ベース。get_design_context や get_screenshot 等のツール仕様、デザインコンテキスト取得、セットアップ、Flutter プロジェクト固有ルール（デザイントークン、フォント、アセット管理）を参照したい時に使用する。 |
| user-invocable | false |
Figma 公式 MCP サーバーの知識ベース。UI 実装ワークフローで Figma デザインからコンテキストを取得する際のリファレンス。
| 項目 | Remote MCP | Desktop MCP |
|---|---|---|
| エンドポイント | https://mcp.figma.com/mcp | http://127.0.0.1:3845/mcp |
| コンテキスト指定 | リンクベース（URL / nodeId 必須） | 選択ベース（Figma で選択したレイヤーを自動認識） |
| Figma Desktop | 不要 | 必須（起動 + Dev Mode 有効化） |
| レート制限 | プランに依存（後述） | Dev/Full seat: Tier 1 API と同等 |
# リモートサーバー
claude mcp add --transport http figma https://mcp.figma.com/mcp
# グローバル設定の場合
claude mcp add --transport http figma https://mcp.figma.com/mcp --scope user
# デスクトップサーバー
claude mcp add --transport http figma-desktop http://127.0.0.1:3845/mcp
認証: /mcp → figma 選択 → Authenticate → Allow Access
全 13 ツール。詳細は tools-reference.md を参照。
| ツール | 用途 | 推奨順序 |
|---|---|---|
get_design_context | レイアウト・スタイル情報を React + Tailwind 形式で取得 | 1. 最初に実行 |
get_metadata | ノード構造の XML 概要（大規模デザイン向け） | 2. 必要時 |
get_screenshot | スクリーンショット取得（レイアウト忠実性の確認） | 3. 視覚確認 |
get_variable_defs | 色・spacing・typography の変数・スタイル抽出 | 4. トークン確認 |
| ツール | 用途 |
|---|---|
get_code_connect_map | Figma ノード ID とコードコンポーネントのマッピング取得 |
add_code_connect_map | マッピング追加 |
get_code_connect_suggestions | マッピング候補の自動検出・提案 |
send_code_connect_mappings | マッピング送信 |
create_design_system_rules | エージェント向けデザインシステムルール生成 |
| ツール | 用途 | 備考 |
|---|---|---|
generate_figma_design | UI → Figma デザインレイヤー変換 | Claude Code 専用・リモートのみ |
get_figjam | FigJam 図を XML 形式で取得 | FigJam 対応 |
generate_diagram | Mermaid → FigJam 図生成 | Flowchart, Gantt, State, Sequence |
whoami | 認証ユーザー情報取得 | リモートのみ |
プロジェクト固有のルール（デザイントークン、フォント、アセット管理等）は project-rules.md を参照。
| Phase | 役割 | リファレンス |
|---|---|---|
| Phase 6 | Figma → デザイン仕様書作成 | prepare-figma スキル |
| Phase 8 | 仕様書 → 実装設計書作成 | impl-design-rules.md |
| Phase 11 | 実装設計書 → UI 実装 | ui-implementation-rules.md |
| Phase 12 | 実装後の三点突合検証 | ui-review-rules.md |
server: user-figma-remote-mcp (または figma-dev-mode-mcp-server)
arguments: {
nodeId: "<nodeId>",
fileKey: "<fileKey>",
clientLanguages: "dart",
clientFrameworks: "flutter"
}
get_design_context はデフォルトで React + Tailwind 形式 で出力する。これは MCP サーバーの設計上の仕様。
clientFrameworks で対象を指定可能| 形式 | 例 | 用途 |
|---|---|---|
| URL 形式 | 9474-146965 | Figma URL のクエリパラメータ |
| API 形式 | 9474:146965 | MCP / REST API の nodeId |
変換: ハイフン - → コロン : に置換
https://www.figma.com/design/<fileKey>/<FileName>?node-id=<int1>-<int2>
→ fileKey: <fileKey>
→ nodeId: <int1>:<int2>
| プラン | Dev/Full 座席（日/分） | View/Collab 座席 |
|---|---|---|
| Enterprise | 600/日, 無制限/分 | 6/月 |
| Organization | 200/日, 20/分 | 6/月 |
| Pro | 200/日, 15/分 | 6/月 |
| Starter | 6/月 | 6/月 |
get_design_context の注意点visible=false の未使用子 node がツリーに残ることが多い。構造データだけで実装対象と判断しないget_screenshot と突合: スクリーンショットに写っているものだけが「表示されている UI」。写っていなければ実装・YAML に含めない（条件付き表示は状態バリエーション表で別記）visible 属性で確認可能<div> として出力される等get_metadata で個別にノードタイプを確認 するellipse = 円形, rectangle = 四角形Figma の Variable 名・Style 名だけを根拠に色を変更してはならない。 同じノードに複数の似た色変数が定義されていることがあり、名前から実装対象を推測すると誤判定する。
必須プロセス:
get_screenshot で実描画を確認 — 実際にレンダリングされた色を目視する（変更前後の差を把握できる粒度で）get_variable_defs で候補を全件取得 — そのノードに紐づくすべての Variable / Style を一覧化する// Figma の Variable XXX 準拠 / Style 名 YYY は別用途 のように、なぜそのコードを採用したかを明示するこのルールはアイコン色・テキスト色・ボーダー色・背景色など、すべての色変更に適用する。
関連（実装側のルール）: Figma 値を Flutter 実装に落とし込む際のルール（既存デザイントークンを再発明しない／フォントサイズが異なるテキストの baseline 揃え 等）は Figma MCP ツールの話ではなく 実装規約のため、
impl-issueスキルの phase-11-typography-mapping.md と phase-11-ui-implementation.md に記載している。
| 問題 | 対策 |
|---|---|
| Web/React コードが返される | プロンプトでフレームワーク指定、Code Connect 設定、カスタムルール追加 |
| ツールが読み込まれない | MCP 接続確認、Desktop アプリ再起動、/mcp で状態確認 |
| node-id エラー | URL から最新 nodeId を取得（画面設計書の nodeId は古い可能性） |
| レート制限超過 | プランのアップグレード、一括取得の活用 |
msg-sys 通信基盤（常駐 Codex セッションとの Stop フック経由の非同期往復）の上で、 Codex とのレビュー依頼・所見受領・修正・完了判定を駆動する。3モード（依頼/受信/再開）を持つ。 依頼モードのトリガー句: "msg-reviewでレビュー依頼", "Codexとレビュー往復したい", "常駐Codexにレビューを依頼", "msg-reviewを実行して", "Codexセッションにコードレビューを頼みたい"。 受信モードの起動契機（トリガー句ではなくメッセージ本文の形式で成立）: Stop フックが差し戻した メッセージ本文の先頭が `[msg-review] <種別> review_id=<review_id> round=<n>` である。 再開モードのトリガー句: "msg-reviewを再開したい", "レビューの往復上限到達通知が来た、状況を確認して", "review_idの未解決所見を要約して", "msg-reviewの続きを確認したい"。
設計書から実装戦略を策定し、タスクを抽出して YAML 計画書を作成・更新する。レビュー+自動修正→commit まで一貫実行。 トリガー: "計画書作成", "計画開始", "start plan", "start planning"
計画書からタスクを選び、実装・レビュー・計画更新まで一貫して実行する。 トリガー: "実装開始", "タスク実行", "start implement"
コード・文書をレビューし、品質問題の発見から修正まで自動化できる。重大度 🔴🟡🟢 で分類。 --auto で修正まで一貫実行。code/requirement/design/plan/uxui/generic の6種別に対応。 トリガー: "レビュー", "review", "レビューして", "確認して"
GitHub Issue を軽量実装で進めるか forge の SDD フロー（start-requirements/start-design/start-plan）に委ねるかを判定するスキル。feature namespace の要否も判定する。トリガー：「このIssueをトリアージして」「Issueの進め方を判定して」「#N はどう進めるべきか判定して」
GitHub Issue の実装を準備から完了まで一貫して行う。triage の判定調査結果（仕様書・ルール・類似PR・既存コードの特定）を引き継ぎ、実装計画の策定・Issue への解決内容記載・実装・レビューまで進める。UI Issue の場合は Figma デザイン仕様書・実装設計書の作成、UI 実装、実装レビューまでカバーする。 `/anvil:triage-issue` が軽量実装と判定した Issue に対して Skill ツール経由でのみ起動される（ユーザーからの直接起動は不可）。