메뉴
Figma デザインからデザイン仕様書を作成する subagent スキル。PAT で対象フレームを特定し、MCP で詳細取得、PAT で精度補完。画面設計書の nodeId を信頼せず Figma で検証する。YAML レイアウト定義から AI 理解プレビューを自動生成し、Figma SS と並べて検証する。impl-issue の Phase 6 から呼び出される。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | prepare-figma |
| description | Figma デザインからデザイン仕様書を作成する subagent スキル。PAT で対象フレームを特定し、MCP で詳細取得、PAT で精度補完。画面設計書の nodeId を信頼せず Figma で検証する。YAML レイアウト定義から AI 理解プレビューを自動生成し、Figma SS と並べて検証する。impl-issue の Phase 6 から呼び出される。 |
| user-invocable | false |
| allowed-tools | Bash(curl *), Bash(echo *), Bash(jq *), Bash(python3 *), Bash(uv *), Bash(bash *), Bash(mkdir *), Bash(command *), Bash(which *), Bash(brew *), Read, Write, Edit, Glob, Grep, AskUserQuestion, Skill(resolve-figma-node), Skill(figma-mcp-guide), mcp__figma-dev-mode-mcp-server__get_design_context, mcp__figma-dev-mode-mcp-server__get_metadata, mcp__figma-dev-mode-mcp-server__get_screenshot, mcp__figma-dev-mode-mcp-server__get_variable_defs |
Figma デザインからデザイン仕様書（What: 何を作るか）を作成する subagent スキル。
作成するもの: デザイン仕様書（specs/design/{id}/デザイン仕様書.md）
作成しないもの: 実装設計書（How: どう作るか）— ルール文書・類似PR・既存コードの調査後に作成するため
オーケストレータ（impl-issue Phase 6）から以下を受け取る：
ei-gum_ホームタブ画面_LIMITED ITEMSタブ）重要: 1 画面につき 1 ディレクトリ。画面 ID をディレクトリ名にして、配下に仕様書・画像・プレビューをまとめる。複数画面を扱う Issue でファイルが混ざらないようにするため。
specs/design/
└── {id}/ # 画面 ID（例: fh-ccu）
├── デザイン仕様書.md # 永続成果物（YAML レイアウト定義を含む）
├── images/ # Figma スクリーンショット類
│ ├── 全体.png # メイン SS（正）
│ ├── 仕様注釈.png # 補足画像（任意、用途名で識別）
│ ├── スクロール時.png # 補足画像（状態バリエーション等）
│ └── ...
└── previews/ # AI 理解プレビュー類（誤り検出用）
├── preview.png # 撮影 PNG
├── preview.yaml # 抽出された YAML（中間生成物、gitignore 推奨）
└── preview.html # レンダリング用 HTML（中間生成物、gitignore 推奨）
命名規則:
{id}_{画面名} のように長くしない）。画面 ID で一意性が担保される。デザイン仕様書.md 固定。ディレクトリ名で画面が特定されるため接頭辞は不要。images/全体.png 固定。補足画像は images/{用途}.png（仕様注釈、スクロール時、空状態など、用途を端的に表す名前）。previews/preview.* 固定。PAT で特定 → MCP で詳細取得 → PAT で補完 の 3 段階。
ユーザーが「Figma Desktop を開いている」「対象フレームを選択した」と明示した場合は、 Desktop MCP の現在選択ノード取得を先に試す。
推奨順序:
get_screenshot / get_design_context を確認Desktop MCP が失敗した場合でも、失敗理由（未選択 / Dev Mode 権限不足 / resource inaccessible）を記録すること。
resolve-figma-node スキルを使用。画面設計書の nodeId を信頼せず Figma 側で検証する。
結果として nodeId、Figma URL、フレーム名、サイズを確定する。
| ツール | 用途 | 実行順序 |
|---|---|---|
get_design_context | レイアウト・スタイル情報（React+Tailwind 形式） | 1. 最初 |
get_metadata | ノード構造概要（マスク/クリッピング確認） | 2. 個別要素確認 |
get_screenshot | スクリーンショット（視覚確認） | 3. 目視確認 |
get_variable_defs | デザイントークン（色・spacing・typography） | 4. 必要時 |
| 用途 | 推奨 | 理由 |
|---|---|---|
| デザイン情報取得 | MCP | 構造化された情報を取得可能 |
| 変数・スタイル取得 | MCP | get_variable_defs が便利 |
| スクリーンショット | MCP | get_screenshot で直接取得 |
| アセットダウンロード（SVG/PNG） | REST API | MCP にはエクスポート機能なし |
| 大規模な一括取得 | REST API | 複数ノードを一度に指定可能 |
重要:
# 画像エクスポート（単体）
curl -s -H "X-Figma-Token: $FIGMA_PAT" \
"https://api.figma.com/v1/images/{fileKey}?ids={nodeId}&format=svg"
# 複数アセットの一括ダウンロード（レート制限の節約に有効）
curl -s -H "X-Figma-Token: $FIGMA_PAT" \
"https://api.figma.com/v1/images/{fileKey}?ids={id1},{id2},{id3}&format=svg"
MCP の get_screenshot が使えない場合の代替手段:
FILE_KEY="{Figma URL から抽出}"
NODE_ID="{node-id、ハイフンをそのまま使用}"
EXPORT_URL=$(curl -s -H "X-Figma-Token: $FIGMA_PAT" \
"https://api.figma.com/v1/images/${FILE_KEY}?ids=${NODE_ID}&format=png&scale=2" \
| python3 -c "import sys, json; d=json.load(sys.stdin); print(list(d['images'].values())[0])")
curl -s -o specs/design/{id}/images/全体.png "$EXPORT_URL"
prepare-figma が呼ばれた = Figma からの取り込みが必要、なので このスキルに入った直後 に依存ツールの有無を確認する。 AI は勝手にインストールしない。不足があればユーザーに判断を仰ぐ。
| ツール | 必須度 | 用途 | チェックコマンド |
|---|---|---|---|
| Google Chrome / Chromium | 必須 | プレビュー PNG 撮影 | command -v google-chrome || command -v chromium || ls "/Applications/Google Chrome.app" 2>/dev/null |
uv（推奨）または PyYAML 入り Python3 | 必須 | YAML→HTML 変換 / PNG トリミング | command -v uv || python3 -c "import yaml, PIL" 2>/dev/null |
uv が無い場合自動インストールはしない。以下を AskUserQuestion でユーザーに尋ねる：
プレビュー生成に `uv`（Python script runner）が必要ですが、見つかりませんでした。
どうしますか？
選択肢:
- A. 私（AI）が `brew install uv` を実行してインストールします
→ ユーザーがこれを選んだ場合のみ、AI は次のコマンドを Shell で実行する:
brew install uv
- B. ユーザーが手動でインストールします（インストール後に「再開」と言ってください）
→ AI は待機。再開シグナルが来たら Step 0 から再チェック
- C. プレビュー生成をスキップして YAML だけ書きます
→ 視覚比較ループは行わない。仕様書末尾に「プレビュー未生成」と明記する
- D. 中断（このタスクを止める）
Linux ユーザーの場合、A の代替として curl -LsSf https://astral.sh/uv/install.sh | sh を提示する。
同様に AskUserQuestion で尋ねる（自動インストールはしない）：
プレビュー撮影に Chrome / Chromium が必要ですが見つかりませんでした。
どうしますか？
選択肢:
- A. ユーザーが手動でインストールします
- B. 環境変数 CHROME_BIN で別パスを指定する
- C. プレビュー生成をスキップ
- D. 中断
ログに「Step 0 OK: uv=found, chrome=found」と一行だけ出して即 Step 1 へ進む。
オーケストレータから受け取ったファイルパスで画面設計書を Read で読み込む。
読み込むファイル（パスはオーケストレータから受け取り済み）:
{id}_{画面名}.md — メインの画面設計書{id}_{画面名}_確認・調整事項.md — 補足資料（存在する場合）読み込む内容:
resolve-figma-node スキルを呼び出す:
Desktop で対象が選択済みと分かっている場合は、まず nodeId なしで試す。 失敗した場合のみ nodeId 指定に切り替える。
get_design_context(nodeId) — レイアウト・スタイル情報get_metadata(nodeId) — 大規模デザインの場合、ノード構造概要get_screenshot(nodeId) — スクリーンショット（必ず取得し目視確認）get_design_context はマスク/クリッピング情報を正確に反映しない場合があるget_metadata で個別確認ellipse = 円形、rectangle = 四角形get_variable_defs(nodeId) — デザイントークン確認スクリーンショット確認で特に見るもの:
MCP の出力が不正確・不十分な場合:
packages/design_ui/res/assets/ の既存アセットを確認# SVG ダウンロード
curl -s -H "X-Figma-Token: $FIGMA_PAT" \
"https://api.figma.com/v1/images/{fileKey}?ids={nodeId}&format=svg" \
| jq -r '.images["{nodeId}"]'
# → URL を取得して curl -o でダウンロード
# PNG（2x）ダウンロード
curl -s -H "X-Figma-Token: $FIGMA_PAT" \
"https://api.figma.com/v1/images/{fileKey}?ids={nodeId}&format=png&scale=2"
references/design-spec-template.md のテンプレートに従って作成。
必須記載事項:
specs/design/{id}/images/全体.png に保存して相対パスで参照）出力先: specs/design/{id}/デザイン仕様書.md
仕様書中の YAML から AI 理解プレビュー PNG を自動生成する。 この PNG を Figma SS と並べて目視比較することで、AI の構造理解の誤りを早期発見する のが目的。
mkdir -p specs/design/{id}/previews
bash "${CLAUDE_PLUGIN_ROOT}/skills/prepare-figma/scripts/render_preview.sh" \
specs/design/{id}/デザイン仕様書.md \
specs/design/{id}/previews \
preview
成功すると以下の 3 ファイルが生成される:
specs/design/{id}/previews/preview.yaml — 抽出された YAMLspecs/design/{id}/previews/preview.html — レンダリング用 HTMLspecs/design/{id}/previews/preview.png — 撮影された PNG仕様書には PNG を相対パスで埋め込み、Figma SS と並べる（幅 320px で表示）:
## 視覚比較
| Figma（正） | AI 理解（プレビュー） |
| ----------------------------------------------------- | ------------------------------------------------------------ |
| <img src="./images/全体.png" alt="Figma" width="320"> | <img src="./previews/preview.png" alt="Preview" width="320"> |
前提条件: Step 0 で確認済みの想定。 万一 Step 0 をスキップしていてここでエラーが出た場合は、インストールを勝手に実行せず Step 0 に戻ること。 詳細は scripts/README.md 参照。
目的: AI 自身が Figma SS と AI プレビュー PNG を見比べて構造的な誤りを発見し、YAML を直して再レンダリングすることを 構造差異がゼロになるまで繰り返す。
このループの趣旨は単なるドキュメント比較ではなく、「AI が自分の理解を画像で外部化し、自分で答え合わせをする」自己検証。 ユーザーに渡す前に AI が必ず実行する。
両画像を Read する
specs/design/{id}/images/全体.pngspecs/design/{id}/previews/preview.png差異を分類しながらリスト化する
各領域について、以下の 3 つのいずれかに分類する：
| 分類 | 判定基準 | 扱い |
|---|---|---|
| 🔴 構造誤り | パーツ自体の有無、配置、サイズ感、形状の違い | YAML 修正対象 |
| 🟡 データなし許容 | アバター画像、ステータスバー、タブコンテンツ、ボトムナビ等の「データを持たないので Preview が placeholder になっている」箇所 | 無視 |
| 🟢 ダミーデータ許容 | 「山田太郎」vs「名前名前」、行数や文字数の違い、自己紹介の長さ違い等 | 無視 |
構造誤りの典型例（実際に発見されたパターン）:
構造誤りでない例:
🔴 構造誤りがあれば YAML を修正する
仕様書 MD 内の preview: YAML ブロックを直接 Edit する。
修正例（実例）:
# Before（誤り: 20×90 全体がアイコン placeholder になる）
- id: favorite_button
width: 20
height: 90
type: icon
label: "♥"
# After（正: 20×90 の container に 20×20 アイコンを上端配置）
- id: favorite_button_area
width: 20
height: 90
layout: vertical
align: start
children:
- id: heart_icon
width: 20
height: 20
type: icon
label: "♥"
プレビューを再生成する
bash "${CLAUDE_PLUGIN_ROOT}/skills/prepare-figma/scripts/render_preview.sh" \
specs/design/{id}/デザイン仕様書.md \
specs/design/{id}/previews \
preview
1 に戻る
この時点で初めて、ユーザーレビュー（impl-issue Phase 7）に進む資格を得る。
視覚比較ループと並行して、画面設計書 および デザイン仕様書の他セクション（カラー表、フォント表、アクション一覧 等）も整合性確認する。 矛盾があれば仕様書テキストを修正する。
デザイン仕様書は「何を作るか」の文書。Flutter のクラス名やコードは書かない。
レイアウトは preview: YAML ブロックで構造化して記述する。
これがプレビュー画像生成の唯一の入力なので、YAML が正確であれば prevew も正確に出る。
children: で表現width: fill / hug / Npx で Figma Auto Layout 制約を再現layout: vertical | horizontal で並び方向を指定（Figma の stack（オーバーレイ配置）は現時点で未対応 — 子要素を重ねるレイアウトはプレビュー再現できない。詳細は references/preview-yaml-schema.md を参照）スキーマの詳細は references/preview-yaml-schema.md を参照。
hug contents: 内容に応じた幅（intrinsic width）fill: 残りの幅を埋める（Expanded）fixed {n}px: 固定幅以下の条件を 両方満たす場合 に限り、Figma から取得したコードをデザイン仕様書に記載してよい:
get_design_context の CSS/スタイル定義、SVG パスデータ等通常のスタイル（単色、標準的なパディング等）は数値で記載し、コードは書かない。
Figma MCP エラー時:
PAT / MCP で数値が取れていても、スクリーンショットで見た目を確認していないレイアウトは「確定」とみなさない。
以下をすべて満たした場合のみ「Figma と完全一致確認済み」と表現してよい:
上記のいずれかが未実施の場合は、 「Figma を確認して仕様化済み」「仕様に沿って実装済み」「完全一致は未確認」 のように分けて報告する。
resolve-figma-node で必ず検証するget_design_context → get_metadata（必要時）→ get_screenshotget_design_context の生成コードを鵜呑みにする — マスク/クリッピング情報を正確に反映しない場合がある。形状が重要な要素は個別に get_metadata で確認必須render_preview.sh の実行は必須。生成された PNG を Figma SS と並べて見比べないと AI の理解違いが残る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 ツール経由でのみ起動される（ユーザーからの直接起動は不可）。