mcpField
F
figure-designer

figure-designer

github.com/hkustdialデザイン・UI11.0k757 回インストール2 週間前に更新
リポジトリ

figure-designer について

figure-designerは、論文の図を計画・監査するためのスキルです。図の形式を提案し、レイアウトやラベル、ツールの指針を示して、共通ルールに沿って品質を確認します。

主な機能

  1. 01論文の主要な図の種類を識別
  2. 02適切な図の形式を提案
  3. 03具体的なレイアウトとラベルを提示
  4. 04図の種類に応じたツールを提案
  5. 05共通ルールに沿って図を監査
  6. 06設計の整合性と重大度を確認

活用シーン

  1. 01論文の動機付け例の計画
  2. 02手法概要図の設計
  3. 03実験結果に合うグラフの選択
  4. 04投稿前の論文図の監査

インストール

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

$npx skills add https://github.com/hkustdial/supervisor-skills --skill figure-designer

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

同梱ファイル

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

references/
design-rules.md
experimental-results.md
motivated-example.md
solution-overview.md
tools.md

詳細

図のデザイン

概要

トップクラスの会議に投稿される論文には、通常6〜8点の図が掲載されます。そのうち、ストーリーを伝えるうえで特に重要なのは、Motivated Example(図1。1ページ目または2ページ目の上部)、Methodologyセクション内のSolution Overview、Experimentsセクション内のExperimental Resultsの図の3点です。査読者は、論文を詳しく読む価値があるかどうかを判断するため、この3点に1分もかけずに目を通します。図が弱ければ、それ以外の部分が優れた論文でも評価を落とします。

このスキルでは、ユーザーの意図(何を伝えたいか)と文脈(研究分野、手法名、投稿先)を受け取り、推奨する図のパラダイム、レイアウトのスケッチ、ラベル付けの指針、ツールの提案、および汎用ルールセット(ベクター形式、フォントサイズ、色覚多様性に配慮した表現、キャプションの自己完結性、誠実な軸の範囲)に基づく品質管理の監査を返します。

このスキルを使う場面

  • 論文用の図を描く前。
  • ユーザーが「図をデザインしたい」「図1を描きたい」「実験結果をプロットしたい」「適切なグラフの種類を選びたい」と依頼したとき。
  • ユーザーが図を描き終え、デザイン監査を希望するとき。
  • ユーザーがどの図の種類やパラダイムを選ぶべきか迷っているとき。
  • 投稿前にカメラレディ用の図を準備するとき。

このスキルを使わない場面

  • ユーザーが論文以外で一般的な作図(棒グラフ、折れ線グラフなど)の支援だけを求めている場合。通常の支援で十分です。
  • 論文の構成がまだ固まっていない場合。まず intro-drafter または tech-paper-template を使い、論文に必要な図を決めてください。
  • ユーザーが完成済みの論文のレビューを希望している場合。pre-submission-reviewer を使ってください。

基本手順

Step 1: 図の種類を特定する

図が中核となる3種類のどれに当たるかを判断します。ユーザーの依頼がいずれにも当てはまらない場合は、補足図(実験結果のガイダンスをベースにします)か、論文に掲載する必要のない図のどちらかです。

モードが figure-audit で、ユーザーが画像のパスを提示している場合は、Step 2に進む前にReadツールで画像を読み込みます。画像を直接確認することで、ユーザーの説明に頼るのではなく、Step 6の汎用ルール監査でフォントの読みやすさ、カラーパレット、ラスター形式かベクター形式かを見分ける手掛かり、チャートジャンクを確認できます。画像が提示されていない場合は、テキストのみのモードで続行し、視覚的な確認が必要なルール(フォントサイズ、ラスター形式の検出、カラーパレット)は、最終監査レポートで「ユーザーによる確認が必要」と記します。

Step 2: パラダイムを推奨する

図の種類に応じて、references/motivated-example.md、references/solution-overview.md、またはreferences/experimental-results.mdを参照してください。

各図の種類には、代表的なパラダイムが2〜3種類あります。ユーザーが伝えたい内容に合うものを選び、他のパラダイムがあまり適していない理由を説明します。

Step 3: レイアウトをスケッチする

レイアウトの説明を作成します。パネルの配置、要素の位置、矢印、色の割り当てを記載します。目標は、このスケッチだけをもとにユーザーが初稿を描けるようにすることです。

Step 4: ラベル付けと注釈の指針を示す
  • 表示する要素にはすべて具体的な名前を付けます(「Module A」「X」「Y」のような名前は使いません)。
  • 重要な箇所(失敗の強調、成功の強調、比較の強調)に注釈を付けます。
  • フォントサイズとカラーパレットを指定します。デフォルトのカラーパレットは、質的データにはColorBrewer、逐次データにはViridisです。
Step 5: ツールを提案する

ツールの比較表と選択のヒューリスティックについては、references/tools.mdを参照してください。

デフォルトの推奨事項:

  • Motivated ExampleとSolution Overview:PowerPoint(下書き)、Figma(仕上げ)。
  • Experimental Results:再利用可能な plot_utils.py スクリプトでMatplotlibまたはSeabornを使用します。
  • LaTeXに組み込む図:TikZまたはPGFPlots。
ステップ 6: 普遍ルールの監査

参照: 普遍ルールの完全なセットについては references/design-rules.md を参照してください。

提案された、または既存のすべての図を以下に対して検証します:

  • エクスポート用のベクター形式 (PDF、EPS、SVG)。
  • 拡大縮小後も 8pt 以上のフォントサイズ。
  • 小さなキャンバス (大きなキャンバスに小さなフォントではない)。
  • 色覚多様性に安全なパレット。色のみによるエンコーディングを行わない。
  • 最初の文で核心となる知見を述べる自己完結型のキャプション。
  • 誠実な軸範囲。
  • 3D 効果なし、チャートジャンクなし。

すべての違反に重要度を付けて報告します。

ステップ 7: インテグリティゲート

以下のインテグリティゲートセクションのチェックを実行します。

ステップ 8: 出力

以下の出力形式で完全な設計を出力します。

インテグリティゲート

[inspection] とタグ付けされた箇条書きは、LLM が自身の出力からチェックします。[user-verify] とタグ付けされた箇条書きは、描かれた図、またはスキルが持たない知識 (論文の文脈、先行する Introduction) のいずれかに依存するチェックであるため、ユーザーによる確認が必要です。

設計を返す前に:

  1. [inspection] パラダイムが図の種類と一致している (motivated example はパイプラインではなく、overview は棒グラフではない)。
  2. [inspection] レイアウトスケッチが、ユーザーがそこから描けるほど具体的である。
  3. [inspection] ラベルがプレースホルダーではなく実際のエンティティ名である。
  4. [inspection] ツールの提案が図の複雑さと一致している (複数アイコンの motivated example に Matplotlib ではなく、20 手法の棒グラフに PowerPoint ではない)。
  5. [inspection] 画像が提供された場合、[user-verify] テキストのみの場合 普遍ルールの監査が実行されている。対処されていない CRITICAL 違反が残っていない。視覚のみのルール (ラスター対ベクター、フォントサイズ、カラーパレット) は、ユーザーが画像を提供した場合にのみチェックできます。
  6. [user-verify] motivated example の場合、その例が Introduction で参照されているものと同じ実行例である (Figure 1 で新しい例が導入されていない)。スキルは Introduction を見ることができないため、ユーザーが確認します。
  7. [inspection] 実験結果の場合、グラフの種類がデータの種類と一致している (時系列は折れ線、複数手法の比較はグループ化棒グラフ、トレードオフは散布図)。

いずれかの [inspection] チェックが失敗した場合、その設計を「ユーザーの注意が必要」とマークします。[user-verify] の項目については、提出前にユーザーが確認すべき項目として提示します。

出力形式

1. 図の種類
  • 種類: <motivated-example または solution-overview または experimental-results>
  • 理由: <一文>
2. パラダイムの推奨
  • パラダイム: <名前>
  • このパラダイムを選ぶ理由: <根拠>
  • 検討して却下した代替案: <リスト>
3. レイアウトスケッチ
  • キャンバス: <サイズ>
  • パネル: <位置と内容を含むリスト>
  • 矢印と接続: <リスト>
  • 色の割り当て: <マッピング>
4. ラベリングと注釈
  • 要素名: <リスト>
  • 重要なハイライト: <リスト>
  • フォントサイズ: <目標>
  • カラーパレット: <名前>
5. ツールの提案
  • 主: <ツール>
  • 代替: <ツール>
  • 理由: <根拠>
6. 普遍ルールの監査
  • ベクター形式: <pass または fail>
  • フォントサイズ: <pass または fail>
  • 色覚多様性に安全: <pass または fail>
  • 自己完結型のキャプション: <pass または fail>
  • 誠実な軸範囲 (該当する場合): <pass または fail>
  • チャートジャンクなし: <pass または fail>
7. インテグリティゲートの結果
  • ゲート 1〜7: <pass または fail>
8. 重要度のまとめ
  • CRITICAL、 MAJOR、 MINOR
  • 最初に取るべき上位 3 つのアクション: ...

コメント