Diagram Design

図を生成して終わらず、Plan → Build → Review → Refine で制作する。見た目の整然さと、内容の正確性・読める大きさ・理解しやすさを分けて扱う。

適用範囲と担当

• 通常は設計から修正・再確認まで行う。計画のみの依頼は Plan、レビューのみの依頼は Review に限定し、対象を変更しない。
• 親が目的、掲載条件、情報の採否、担当範囲、最終判断を持つ。分業する場合は描画担当だけが図のソースを書き、レビュー担当は読取専用にする。
• 既存の reviewer を使う場合、進行・独立性・共通の判定方法はその Skill に従う。本 Skill は図固有の設計と確認観点を追加し、別のレビューワークフローを重ねない。
• 相対参照はロード済みの本 Skill の実体ディレクトリから解決する。対象プロジェクトの cwd や未確認の HOME を起点にしない。

1. Plan — 描く前に情報を編集する

依頼と掲載先から次を短く整理する。小さな図では会話内のメモで足り、別の計画書は作らない。

項目	決める内容
読者と問い	誰が、この図で何を理解・比較・判断するのか
主張	読後に残す内容を1文で書く。結論をデータより強くしない
掲載条件	掲載場所、実際の表示幅、モバイルの有無、納品形式
必須情報	主張を支える要素・関係・数値と、その根拠
図外へ移す情報	実装詳細、補足、コード、出典の詳細を置く本文・キャプション・別図

• 1図1つの中心的な問いに絞る。概要、動作例、実装仕様を同じ図へ詰め込まない。主張を変える必須条件や数値は、見栄えのために削らない。
• 箱を並べる前に関係を決める。処理順はフロー、差は共通尺度の比較、構成は階層・接続、数量はデータ図にする。文章を箱へ移すだけで済ませない。
• タイトル、主要要素、補足の優先順位を決める。色・矢印・線種は意味に対応させ、配色や箱数を一律に固定しない。
• 表示幅は掲載先の既存レイアウトを優先する。不明な Web 図は、仮の確認幅としてデスクトップ 720 CSS px、モバイル 360 CSS px を置き、その仮定を明記して進める。スライドや印刷物にはこの値を流用しない。
• Web 図の初期目安は表示時の主要ラベル 16 CSS px 以上、補足 14 CSS px 以上とする。普遍的な合格基準ではなく、掲載先の書式と実画像で調整する。収まらなければ情報の削減・分割・縦配置を先に検討する。

2. Build — ソースだけでなく掲載状態まで作る

• ユーザー指定と既存の制作環境を優先し、利用可能な描画・画像生成ツールを使う。正確な数値やラベルが必要な図は、再編集・再描画できる既存の手段を使い、データと表示の対応を残す。
• 計画から図を作り、実際にレンダリングした画像を取得する。SVG・HTML・描画コード・生成プロンプトを読んだだけで見たことにしない。
• 掲載幅に合わせたプレビューを作る。掲載先を操作できる場合は実ページへ組み込んだ状態でも確認する。原寸画像の拡大表示だけで済ませない。
• 書き出し解像度と表示サイズを区別する。高解像度化は、縮小後の文字サイズや情報密度の問題を解決しない。横長図をそのままモバイルへ縮めず、分割や縦配置で読める構造にする。
• 実行できた機械的確認だけを記録する。DOM・ベクター情報を取得できれば表示時の文字サイズ、境界外へのはみ出し、文字と図形の重なり、コントラスト等を確認する。ラスタ画像だけから全項目を自動検査できたと主張しない。
• タイトル・キャプション・出典表示も掲載物の一部として整える。必要な補足を図外へ出す場合、その文章も納品に含める。

3. Review — 完成画像を批判的に読む

レビュー実行者は 図のレビュー手順 を読み、描画した画像を実際に開いて確認する。

• 利用可能なら、生成担当とは別の画像を読める担当・コンテキストに渡す。渡すものは対象画像、掲載条件、元の要件、照合に必要なデータ・出典、実際に掲載するキャプションとする。
• 作者の設計弁明、生成過程、「分かりやすくできた」という自己評価、先に出た評価の結論は渡さない。レビュー担当には最初に画像から読み取った主張・関係を述べさせ、その後で要件と照合させる。
• 独立した担当を起動できない場合は、同じ担当で工程を分けて画像レビューを行い、独立レビューではないと明記する。画像を読めない場合、コード上の確認だけで視覚レビュー済みにしない。
• 問題は箇所、観察した事実、読者への影響、最小修正、戻す工程を具体化する。「ごちゃごちゃしている」「もっと洗練させる」だけで修正を依頼しない。

4. Refine — 問題が生じた工程へ戻る

問題	戻す工程と修正
主張が読めない、概要と詳細が混在、情報が多すぎる	Plan：優先順位を直し、本文へ移すか別図へ分割する
数値・単位・因果関係・比較条件が誤っている	Plan：根拠を照合して内容を直し、描き直す
文字が小さい、重なる、切れる、視線が迷う	Build：字級・余白・配置を直す。収まらなければ Plan へ戻る
書き出しや掲載による欠落、フォント代替、縮小崩れ	Build：実際の出力・掲載経路を直す

• 親は指摘を実画像と要件で照合して採否を決める。批判的レビューは欠点の捏造や、好みだけの全面作り直しではない。
• 修正後は再レンダリングし、変更した掲載サイズと関連箇所を再確認する。旧画像の評価を新画像へ転用しない。設計を変えた場合は図全体の主張・構造も読み直す。
• 情報過多を小さい文字、注釈の追加、キャンバスの高解像度化で押し込まない。
• 誤読、判読困難、内容の誤りを解消したら終了する。任意の装飾改善だけで反復しない。未解決の問題や実行できなかった確認は、その範囲を残して報告する。

納品

最終画像、存在する編集用ソース、必要なキャプション・出典、確認した表示幅とレビュー結果を簡潔に渡す。作成、画像確認、掲載先での確認を区別し、未実行の工程を完了扱いにしない。

失敗から一般化できる改善が見つかっても、今回の図の修正と共有 Skill の変更を混同しない。Skill 更新が依頼範囲に含まれる場合だけ、再発を防ぐ具体的な操作として正本へ反映する。