excalidraw-diagram

Name: excalidraw-diagram
Author: coleam00

github.com/coleam00デザイン・UI5.1k8.6k 回インストール34 週間前に更新

リポジトリ

excalidraw-diagram について

excalidraw-diagramは、ExcalidrawのJSONファイルを作成するデザインスキルです。概念、プロセス、技術アーキテクチャを説明する用途に向け、関係性を視覚的に示し、技術図では具体例とレンダリング確認を重視します。

主な機能

01Excalidraw JSONファイルの生成
02関係性に応じた視覚表現の選択
03技術図への具体的な根拠の追加
04共通カラーパレットの使用
05複雑な図のセクション別作成
06図のレンダリングと確認

活用シーン

01システム構成やプロトコルの流れの説明
02実データ例を含む技術図の作成
03概念間の因果関係の可視化
04大規模な図の分割作成と検証

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/coleam00/excalidraw-diagram-skill --skill excalidraw-diagram

インストール後、Claude Code で/excalidraw-diagramを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

README.md

.gitignore

references/

element-templates.md

render_excalidraw.py

pyproject.toml

render_template.html

json-schema.md

color-palette.md

詳細

Excalidraw 図の作成

情報をただ表示するのではなく、視覚的に論旨を伝える.excalidraw JSON ファイルを生成します。

セットアップ： ユーザーがこのスキルのセットアップ（レンダラー、依存関係など）を求めた場合は、手順について README.md を参照してください。

カスタマイズ

色とブランド固有のスタイルは、すべて1つのファイルにまとめられています： references/color-palette.md。図を生成する前に必ず読み、図形の塗りつぶし、線、テキストの色、根拠となる成果物の背景など、色の選択すべてにおいて唯一の情報源として使用してください。

このスキルで独自のブランドスタイルの図を生成するには、color-palette.md を編集してください。このファイルのそれ以外の内容はすべて、汎用的なデザイン手法と Excalidraw のベストプラクティスです。

基本理念

図は表示するのではなく、論旨を伝えるべきです。

図は書式付きのテキストではありません。言葉だけでは表現できない関係性、因果関係、流れを示す視覚的な論証です。形そのものが意味を表しているべきです。

同型性テスト： テキストをすべて取り除いても、構造だけで概念が伝わるでしょうか？そうでなければ、設計し直してください。

学習テスト： この図から具体的なことを学べるでしょうか、それとも単にボックスにラベルを付けているだけでしょうか？優れた図は、実際の形式、実際のイベント名、具体例を示して、人に何かを教えます。

深さの評価（最初に実施）

設計する前に、この図に必要な詳細レベルを判断してください。

シンプル／概念図

次の場合は抽象的な形を使用します。

メンタルモデルや理念を説明する
対象者が技術的な詳細を必要としない
概念そのものが抽象概念である（例：「関心の分離」）

包括的／技術図

次の場合は具体例を使用します。

実際のシステム、プロトコル、アーキテクチャを図にする
図を教育や説明に使用する（例：YouTube 動画）
対象者が実際の構成要素の姿を理解する必要がある
複数の技術がどのように統合されるかを示す

技術図には、根拠となる成果物を必ず含めてください（以下を参照）。

調査の義務（技術図の場合）

技術的な図を描く前に、実際の仕様を調査してください。

プロトコル、API、フレームワークを図にする場合：

実際の JSON／データ形式を調べる
実際のイベント名、メソッド名、API エンドポイントを確認する
構成要素が実際にどのようにつながるかを理解する
汎用的なプレースホルダーではなく、実際の用語を使用する

悪い例：「プロトコル」→「フロントエンド」良い例：「AG-UI がイベント（RUN_STARTED、STATE_DELTA、A2UI_UPDATE）をストリーミング」→「CopilotKit が createA2UIMessageRenderer() を介してレンダリング」

調査によって、図の正確性と教育的価値が高まります。

エビデンス成果物

エビデンス成果物は、図が正確であることを証明し、閲覧者の理解を助ける具体例です。技術図にはこれらを含めてください。

エビデンス成果物の種類（図に適したものを選んでください）：

成果物の種類	使用する場面	表示方法
コードスニペット	API、連携、実装の詳細	暗色の長方形＋構文に合わせて色付けしたテキスト（エビデンス成果物の色についてはカラーパレットを参照）
データ／JSON の例	データ形式、スキーマ、ペイロード	暗色の長方形＋色付きのテキスト（カラーパレットを参照）
イベント／ステップのシーケンス	プロトコル、ワークフロー、ライフサイクル	タイムライン形式（線＋点＋ラベル）
UI モックアップ	実際の出力／結果の提示	実際の UI を模した入れ子の長方形
実際の入力内容	システムに入力される内容の提示	サンプル内容が見える長方形
API／メソッド名	実際の関数呼び出し、エンドポイント	プレースホルダーではなく、ドキュメントに記載された実際の名前を使用

例：ストリーミングプロトコルの図では、次のようなものを示せます。

仕様に記載された実際のイベント名（「イベント 1」、「イベント 2」だけではなく）
接続方法を示すコードスニペット
ストリーミングされるデータの実際の形式

例：データ変換パイプラインの図では、次のようなものを示せます。

サンプル入力データ（「入力」ではなく、実際の形式）
サンプル出力データ（「出力」ではなく、実際の形式）
関連する場合は中間状態

重要な原則は、物事の名前だけでなく、実際の見た目を示すことです。

マルチズームアーキテクチャ

包括的な図では、複数のズームレベルを同時に扱います。国境と道路名の両方が表示された地図のようなものだと考えてください。

レベル 1：概要フロー

パイプラインやプロセス全体を一目で把握できる、簡略化された概要です。多くの場合、図の上部または下部に配置します。

例：入力 → 処理 → 出力 または クライアント → サーバー → データベース

レベル 2：セクションの境界

関連するコンポーネントをまとめたラベル付きの領域です。これにより視覚的な「部屋」が生まれ、何がひとまとまりなのかを閲覧者が理解しやすくなります。

例：役割別（バックエンド／フロントエンド）、フェーズ別（セットアップ／実行／クリーンアップ）、またはチーム別（ユーザー／システム／外部）にまとめる

レベル 3：セクション内の詳細

各セクションに含めるエビデンス成果物、コードスニペット、具体例です。図の教育的価値はここにあります。

例：「バックエンド」セクションの中に、「API レスポンス」とラベル付けしたボックスだけでなく、実際の API レスポンス形式を示す

**包括的な図では、3 つすべてのレベルを含めることを目指してください。**概要が背景を示し、セクションが構造を整え、詳細が理解を深めます。

悪い例と良い例

悪い例（表示するだけ）	良い例（意味を伝える）
ラベル付きの同じ大きさのボックスが 5 つ	各コンセプトの形状が、その振る舞いを反映している
カードのグリッドレイアウト	視覚的な構造が概念上の構造と一致している
テキストを飾るアイコン	形状そのものが意味を表している
すべてに同じコンテナを使用	コンセプトごとに異なる視覚表現を使い分けている
すべてをボックスに入れる	必要な箇所だけにコンテナを使い、テキストを自由に配置する

シンプルな図と包括的な図（必要なものを見極める）

シンプルな図	包括的な図
汎用的なラベル：「入力」→「処理」→「出力」	具体的：入力／出力が実際にどのようなものかを示す
名前付きのボックス：「API」「データベース」「クライアント」	名前付きのボックスに、実際のリクエスト／レスポンスの例を追加
「イベント」または「メッセージ」というラベル	仕様にある実際のイベント名／メッセージ名を示すタイムライン
「UI」または「ダッシュボード」の四角形	実際のUI要素とコンテンツを示すモックアップ
説明に約30秒	教材として約2～3分
見る人は構造を理解する	見る人は構造と詳細の両方を理解する

シンプルな図は、抽象的な概念や簡単な概要を示す場合、または対象者がすでに詳細を知っている場合に適しています。技術アーキテクチャ、チュートリアル、教育コンテンツ、または図自体に説明させたい場合は、包括的な図が必要です。

コンテナーと自由配置のテキスト

**すべてのテキストを図形で囲む必要はありません。**基本的にはテキストを自由配置します。コンテナーは目的がある場合にのみ追加してください。

コンテナーを使う場合	テキストを自由配置する場合
セクションの焦点となる場合	ラベルや説明である場合
他の要素と視覚的にまとめる必要がある場合	補足情報やメタデータである場合
矢印をつなぐ必要がある場合	近くにあるものを説明する場合
図形自体に意味がある場合（判断を示すひし形など）	タイポグラフィだけで十分な階層を作れる場合
システム内の独立した「もの」を表す場合	セクションのタイトル、サブタイトル、注釈である場合

階層を作るタイポグラフィ：フォントサイズ、ウェイト、色を使って、ボックスを使わずに視覚的な階層を作ります。28pxのタイトルを四角形で囲む必要はありません。

コンテナーテスト：ボックスで囲んだ要素ごとに、「これは自由配置のテキストとして成り立つか？」と考えてください。成り立つなら、コンテナーを取り除きます。

デザインプロセス（JSONを生成する前に実施）

ステップ0：必要な深さを判断する

何よりも先に、次のどちらが必要かを判断します。

シンプル／概念的：抽象的な図形、ラベル、関係性（メンタルモデル、哲学）
包括的／技術的：具体例、コードスニペット、実データ（システム、アーキテクチャ、チュートリアル）

包括的な図が必要な場合：まず調査します。実際の仕様、形式、イベント名、APIを調べてください。

ステップ1：深く理解する

内容を読みます。概念ごとに、次の点を確認してください。

この概念は何をするのか？（何であるかではなく）
概念間にはどのような関係があるか？
中心となる変換や流れは何か？
これを理解するために、何を見ればよいか？（読むだけではなく）

ステップ2：概念をパターンに対応させる

概念ごとに、その振る舞いを視覚的に表すパターンを選びます。

概念が…	使用するパターン
複数の出力を生成する	ファンアウト（中心から放射状に伸びる矢印）
複数の入力を1つにまとめる	収束（漏斗、合流する矢印）
階層や入れ子構造を持つ	ツリー（線と自由配置のテキスト）
一連の手順である	タイムライン（線、点、自由配置のラベル）
ループする、または継続的に改善する	スパイラル／サイクル（開始点に戻る矢印）
抽象的な状態やコンテキストである	クラウド（重なり合う楕円）
入力を出力に変換する	組み立てライン（前→処理→後）
2つのものを比較する	横並び（対比を伴う並列配置）
フェーズに分ける	間隔／区切り（セクション間の視覚的な分離）

ステップ3：多様性を確保する

複数の概念を含む図では、主要な概念ごとに異なる視覚パターンを使用してください。均一なカードやグリッドは使わないでください。

ステップ4：流れをスケッチする

JSONを作成する前に、図の中で視線がどう動くかを頭の中でたどります。視覚的に明確なストーリーが必要です。

ステップ5：JSONを生成する

ここで初めて、Excalidrawの要素を作成します。大きな図の扱い方については、以下を参照してください。

ステップ 6：レンダリングと検証（必須）

JSON を生成した後、図が適切に見えるまで、レンダリング・確認・修正のループを必ず実行してください。これは任意ではありません。詳しい手順については、以下のレンダリングと検証セクションを参照してください。

大規模／包括的な図を作成するための戦略

包括的または技術的な図では、JSON を必ずセクションごとに作成してください。 ファイル全体を一度に生成しようとしてはいけません。これは厳守すべき条件です。Claude Code の1回の応答には約32,000トークンの出力制限があり、包括的な図は一度に生成すると簡単にこの制限を超えてしまいます。仮に制限を超えないとしても、すべてを一度に生成すると品質が低下します。あらゆる面で、セクションごとに作成する方が優れています。

セクションごとのワークフロー

フェーズ 1：各セクションを作成する

JSON のラッパー（type、version、appState、files）と最初のセクションの要素を含むベースファイルを作成します。
編集1回につき1つのセクションを追加します。 各セクションは個別の作業として作成し、時間をかけて取り組みます。レイアウトや間隔、このセクションを既存の内容にどう接続するかを慎重に検討してください。
説明的な文字列 ID（例："trigger_rect"、"arrow_fan_left"）を使用し、セクション間の参照を読み取りやすくします。
シード値はセクションごとに名前空間を分けます（例：セクション 1 では 100xxx、セクション 2 では 200xxx）。これにより衝突を防げます。
作業を進めながら、セクション間のバインディングを更新します。 新しいセクションの要素を以前のセクションの要素にバインドする必要がある場合（例：セクション間を接続する矢印）、同時に以前の要素の boundElements 配列も編集します。

フェーズ 2：全体を確認する

すべてのセクションを配置したら、JSON 全体を読み、次の点を確認します。

セクション間の矢印は両端で正しくバインドされていますか？
全体の間隔はバランスが取れていますか？あるセクションは窮屈で、別のセクションには余白が多すぎる、といった状態になっていませんか？
ID とバインディングはすべて、実際に存在する要素を参照していますか？

レンダリングする前に、配置やバインディングの問題を修正してください。

フェーズ 3：レンダリングと検証

ここで、「レンダリングと検証」セクションに記載されたレンダリング・確認・修正のループを実行します。JSON からはわかりにくい視覚的な問題、つまり重なり、切り抜き、構成のバランスの悪さを見つける段階です。

セクションの分け方

図の計画にある自然な視覚的まとまりに沿って、セクションを計画してください。大規模な図は、たとえば次のように分割できます。

セクション 1：入口／トリガー
セクション 2：最初の判断またはルーティング
セクション 3：主要コンテンツ（ヒーローセクション。単独で最も大きなセクションになることがあります）
セクション 4-N：残りのフェーズ、出力など

各セクションは個別に理解できるようにします。つまり、要素、内部の矢印、隣接するセクションへの相互参照を含めます。

やってはいけないこと

図全体を1回の応答で生成しないでください。 出力トークンの制限に達し、途中で切れた壊れた JSON が生成されます。図が制限内に収まる場合でも、セクションに分ける方が良い結果になります。
コーディングエージェントを使って JSON を生成しないでください。 エージェントはこのスキルのルールについて十分なコンテキストを持たず、調整にかかる手間が利点を打ち消してしまいます。
Python のジェネレータースクリプトを書かないでください。 テンプレート化や座標計算は便利に思えるかもしれませんが、間接的なレイヤーが加わり、デバッグが難しくなります。説明的な ID を使った手書きの JSON の方が保守しやすくなります。

視覚パターンライブラリ

ファンアウト（1対多）

中央の要素から複数の対象に矢印を伸ばします。用途：ソース、PRD、根本原因、中央ハブ。

収束（多対1）

複数の入力を矢印で1つの出力にまとめます。用途：集約、ファネル、統合。

  ○ ↘
  ○ → □
  ○ ↗

ツリー（階層）

親子関係を線でつなぎ、分岐させます（ボックスを使わず、テキストを独立して配置します）。用途：ファイルシステム、組織図、分類体系。

  label
  ├── label
  │   ├── label
  │   └── label
  └── label

幹と枝には line 要素を使い、ラベルには独立して配置したテキストを使います。

スパイラル／サイクル（継続的なループ）

要素を順番に配置し、矢印で開始点に戻します。用途：フィードバックループ、反復プロセス、進化。

  □ → □
  ↑     ↓
  □ ← □

クラウド（抽象的な状態）

さまざまなサイズの楕円を重ねます。用途：コンテキスト、メモリ、会話、精神状態。

アセンブリライン（変換）

入力 → 処理ボックス → 出力を、変換の前後が明確になるように配置します。用途：変換、処理、変換。

  ○○○ → [PROCESS] → □□□
  chaos              order

横並び（比較）

視覚的なコントラストをつけた、並行する2つの構造です。用途：前後比較、選択肢、トレードオフ。

ギャップ／区切り（分離）

セクション間に視覚的な余白や障壁を設けます。用途：フェーズの変更、コンテキストのリセット、境界。

構造としての線

ボックスではなく、線（タイプ：line。矢印ではありません）を主要な構造要素として使います。

タイムライン：一定間隔で小さな点（10～20px の楕円）を配置した垂直線または水平線。各点の横にラベルを自由に配置します
ツリー構造：垂直の幹線と水平の枝線を使い、ボックスを使わずにテキストラベルを自由に配置します
区切り線：セクションを分ける細い破線
フローの背骨：ボックス同士をつなぐのではなく、要素が関連付けられる中央の線

Timeline:           Tree:
  ●─── Label 1        │
  │                   ├── item
  ●─── Label 2        │   ├── sub
  │                   │   └── sub
  ●─── Label 3        └── item

線と自由配置のテキストを使うと、ボックスとその中に収めたテキストを使うより、すっきりとした図になることがよくあります。

形状の意味

表すものに応じて形状を選びます。形状を使わない方法もあります。

概念の種類	形状	理由
ラベル、説明、詳細	なし（自由配置のテキスト）	タイポグラフィで階層を表現できます
セクションタイトル、注釈	なし（自由配置のテキスト）	フォントサイズや太さで十分です
タイムライン上のマーカー	小さな`ellipse`（10～20px）	コンテナーではなく、視覚的な目印になります
開始、トリガー、入力	`ellipse`	柔らかく、起点のような印象です
終了、出力、結果	`ellipse`	完了や到達点を表します
判断、条件	`diamond`	一般的な判断記号です
プロセス、アクション、ステップ	`rectangle`	アクションを囲みます
抽象的な状態、コンテキスト	重なり合う`ellipse`	曖昧で、雲のような印象です
階層ノード	線とテキスト（ボックスなし）	線で構造を表します

ルール：コンテナーを使わないことを基本とします。意味を持たせる場合にのみ形状を加えます。テキスト要素のうち、コンテナーに入れるものは30％未満を目指します。

色で意味を表す

色は装飾ではなく、情報を表します。色はすべてreferences/color-palette.mdから選びます。意味を表す形状の色、テキスト階層の色、エビデンスアーティファクトの色は、すべてここで定義されています。

主な原則：

開始、終了、判断、AI、エラーなど、それぞれの意味に対応する塗りつぶし色と線の色の組み合わせがあります
自由配置のテキストは、階層を表すために色を使います（タイトル、サブタイトル、詳細はそれぞれ異なるレベルです）
エビデンスアーティファクト（コードスニペット、JSONの例）は、それぞれに対応する暗い背景と色付きテキストの配色を使います
コントラストを確保するため、必ず明るい塗りつぶし色に暗い線の色を組み合わせます

新しい色を独自に作らないでください。 既存の意味カテゴリに当てはまらない場合は、Primary/NeutralまたはSecondaryを使います。

モダンな美しさ

すっきりとしたプロフェッショナルな図を作成するには、次の点を参考にしてください。

ラフさ

roughness: 0 — すっきりとしたシャープなエッジです。モダンな図や技術図に使います。
roughness: 1 — 手描き風で有機的な印象です。ブレインストーミングやカジュアルな図に使います。

ほとんどのプロフェッショナルな用途では、0を既定値とします。

線の太さ

strokeWidth: 1 — 細く、エレガントです。線、区切り線、控えめな接続に適しています。
strokeWidth: 2 — 標準的です。形状や主要な矢印に適しています。
strokeWidth: 3 — 太く、目立ちます。強調が必要な場合に限り、メインのフロー線や重要な接続に使います。

不透明度

すべての要素で、必ずopacity: 100を使います。 透明度ではなく、色、サイズ、線の太さで階層を表現します。

形状の代わりに小さなマーカーを使う

大きな形状ではなく、次のような用途に小さな点（10～20px の楕円）を使います。

タイムラインのマーカー
箇条書きの記号
接続ノード
自由配置のテキストの視覚的な目印

レイアウトの原則

サイズで階層を表す

ヒーロー：300×150 — 視覚的な目印となる最重要要素
プライマリ：180×90
セカンダリ：120×60
小：60×40

余白＝重要度

最も重要な要素の周囲には、最も広い余白（200px以上）を設けます。

フローの方向

視線を誘導します。通常、シーケンスは左から右または上から下へ、ハブ＆スポーク型は放射状に配置します。

必要な接続

配置だけでは関係性を示せません。A と B が関連している場合は、矢印を付ける必要があります。

テキストのルール

重要：JSON の text プロパティには、読み取り可能な単語のみを含めます。

{
  "id": "myElement1",
  "text": "Start",
  "originalText": "Start"
}

設定：fontSize: 16、fontFamily: 3、textAlign: "center"、verticalAlign: "middle"

JSON 構造

{
  "type": "excalidraw",
  "version": 2,
  "source": "https://excalidraw.com",
  "elements": [...],
  "appState": {
    "viewBackgroundColor": "#ffffff",
    "gridSize": 20
  },
  "files": {}
}

要素テンプレート

各要素タイプ（テキスト、線、点、長方形、矢印）のコピー＆ペースト用 JSON テンプレートについては、references/element-templates.md を参照してください。各要素の意味上の用途に基づいて、references/color-palette.md から色を選んでください。

レンダリングと検証（必須）

JSON だけでは図を評価できません。Excalidraw JSON を生成または編集した後は、必ず PNG にレンダリングし、画像を確認して、問題がなくなるまで繰り返し修正してください。これはワークフローの重要な一部であり、最後の確認作業ではありません。

レンダリング方法

cd .claude/skills/excalidraw-diagram/references && uv run python render_excalidraw.py <path-to-file.excalidraw>

これにより、.excalidraw ファイルと同じ場所に PNG が出力されます。次に、PNG を実際に確認するために Read ツールを使用してください。

繰り返しの手順

最初の JSON を生成した後、次のサイクルを実行します。

1. レンダリングして確認 — レンダリングスクリプトを実行し、PNG を Read します。

2. 最初に考えた構想と照合 — 不具合を探す前に、レンダリング結果をステップ 1～4 で設計した内容と比較します。次の点を確認してください。

視覚的な構成は、計画した概念的な構成と一致していますか？
各セクションには、意図したパターン（分岐、収束、タイムラインなど）が使われていますか？
図の中で、設計した順序どおりに視線が流れますか？
視覚的な階層は適切ですか？主役となる要素が目立ち、補助的な要素が小さくなっていますか？
技術図の場合、根拠となる資料（コードスニペット、データの例）は読みやすく、適切な位置に配置されていますか？

3. 視覚上の欠陥を確認

テキストがコンテナーで切れている、またはコンテナーからはみ出している
テキストや図形がほかの要素と重なっている
矢印が要素を避けずに、その上を通っている
矢印が誤った要素に到達している、または何もない場所を指している
ラベルの位置が曖昧で、説明対象と明確に結び付いていない
均等に配置すべき要素の間隔が不均等
余白が多すぎるセクションと、窮屈すぎるセクションが隣り合っている
レンダリングサイズで読むにはテキストが小さすぎる
全体の構図が偏っている、またはバランスが取れていない

4. 修正 — 見つかった問題をすべて解決するよう JSON を編集します。よくある修正方法は次のとおりです。

テキストが切れている場合は、コンテナーの幅を広げる
x／y 座標を調整して、間隔と配置を整える
矢印が要素を避けて通るように、points 配列に中間地点を追加する
ラベルを説明対象の要素に近づける
セクション間の視覚的な重みのバランスを取るため、要素のサイズを変更する

5. 再レンダリングして再確認 — レンダリングスクリプトをもう一度実行し、新しい PNG を Read します。

6. 繰り返す — 図が構想の確認（ステップ 2）と欠陥の確認（ステップ 3）の両方を通過するまで、サイクルを繰り返します。通常は 2～4 回の反復が必要です。重大な不具合がないからといって、1 回で終わらせないでください。構図を改善できる場合は、さらに改善してください。

終了条件

次の条件を満たしたら、サイクルを終了します。

レンダリングされた図が、計画段階で考えた概念的なデザインと一致している
テキストが切れておらず、重なっておらず、読みやすい
矢印が適切な経路を通り、正しい要素に接続している
間隔が一貫していて、構図のバランスが取れている
注意書きを添えなくても、安心して人に見せられる

初回セットアップ

レンダリングスクリプトがまだセットアップされていない場合：

cd .claude/skills/excalidraw-diagram/references
uv sync
uv run playwright install chromium

品質チェックリスト

深さと根拠（技術図では最初に確認）

調査済み：実際の仕様、形式、イベント名を調べましたか？
根拠となる資料：コードスニペット、JSON の例、または実際のデータは含まれていますか？
複数のズームレベル：概要のフロー、セクションの境界、詳細が含まれていますか？
抽象より具体：ラベル付きのボックスだけではなく、実際の内容が示されていますか？
教育的価値：見る人が具体的な知識を得られますか？

概念

同型性：それぞれの視覚的構造は、対応する概念の振る舞いを反映していますか？
論拠：図は、テキストだけでは伝えられない何かを示していますか？
多様性：主要な概念ごとに、異なる視覚パターンを使用していますか？
均一なコンテナを使わない：カードのグリッドや同じ大きさのボックスを避けていますか？

コンテナの扱い

コンテナは最小限に：ボックス内の要素を、ボックスを使わずテキストとして配置できませんか？
構造としての線：ツリーやタイムラインのパターンでは、ボックスではなく線とテキストを使っていますか？
タイポグラフィの階層：フォントサイズと色で視覚的な階層を作り、ボックスの必要性を減らしていますか？

構造

接続：すべての関係が矢印または線で示されていますか？
流れ：目で追える明確な視覚的経路がありますか？
階層：重要な要素は、より大きく、またはより孤立して配置されていますか？

技術

テキストの整理：textには読み取れる単語だけが含まれていますか？
フォント：fontFamily: 3
ラフネス：すっきりとしたモダンなスタイルの場合はroughness: 0（手描き風が求められている場合を除く）
不透明度：すべての要素でopacity: 100（透明度なし）
コンテナの比率：テキスト要素の30％未満をコンテナ内に配置していますか？

視覚的な検証（レンダリング必須）

PNGにレンダリング済み：図をレンダリングし、目視で確認しましたか？
テキストのはみ出しなし：すべてのテキストがコンテナ内に収まっていますか？
要素の重なりなし：図形とテキストが意図せず重なっていませんか？
均等な間隔：類似する要素の間隔は一定ですか？
矢印の接続先が適切：矢印は他の要素と交差せず、意図した要素に接続していますか？
書き出しサイズで読みやすい：レンダリングされたPNGでテキストを判読できますか？
バランスの取れた構成：大きな空白や、要素が密集しすぎた領域はありませんか？

Markdown 対応

ログインしてコメント

基本情報

作者: coleam00
リポジトリ: coleam00/excalidraw-diagram-skill
カテゴリ: デザイン・UI
インストール数: 8,592
GitHub スター: 5,127

問題を報告