academic-figure-draft-analyzer

学術論文の草稿・図表分析ツール（図表プランナー）

人が読みやすい図表戦略と、機械可読な Figure Plan v1 を作成します。固定された図表数や汎用的なパイプラインのテンプレートに合わせるのではなく、論文の主張と読者の疑問を軸に図表を計画してください。

論文が不完全な場合は、references/missing-info-policy.md を読んでください。リポジトリの引き継ぎ情報や抽出済みの参照スタイルプロファイルがある場合は、フィールド名を変更せずに引き継いでください。

2系統のプランニングワークフロー

入力に応じて、分析ツールは次のいずれかのモードで動作します。

1. 草稿から図表へのファストトラック（草稿敏捷直出）：
   • 起動条件：実験・分析結果が揃っていないメモ、アウトライン、初期草稿（Markdown、テキスト、または草稿の各セクション）が入力された場合。
   • 対象：図1：全体フレームワーク／方法の概要のみに集中します。
   • 方針：複数の図表からなるプラン（アブレーション／データの挙動）を無理に作成しないでください。実験・分析セクションの欠落について警告しないでください。
2. 投稿用の複数図表プラン（完全定稿多図规划）：
   • 起動条件：実験結果を含む完全な原稿（Markdown、LaTeX、PDF、または全文）が入力された場合。
   • 対象：主張の検証と出版上の制約を考慮し、複数の図表からなる一式を体系的に計画します。

入力仕様

• 優先する入力：原稿本文またはソース、要旨、手法、実験、投稿先・ページ制限、意味的なアーキテクチャの引き継ぎ情報、参考図。
• 対応する入力：Markdown（.md）の草稿やメモ、アウトライン、タイトルと要旨、ローカルのPDF、論文のURL／HTML、Word／LaTeX。
• URLの内容を確認した場合に限り、論文ソースとして扱ってください。すべてのURLをコードリポジトリと分類しないでください。
• 現在の環境でPDFやウェブページを読み取れない場合は、その制約を報告し、論文の構成を推測して作り上げないでください。

出力仕様

以下を含めてください。

1. 論文の概要：問い、貢献、根拠、想定する投稿先の制約。
2. 完全性に関する記述：実際に確認したセクションと資料。
3. 図ごとの推奨内容。所定のタイプを指定し、優先度は must、strong、nice のいずれかとします（草稿モードでは、主図として図1をちょうど1つ出力します）。
4. 1文で表すコミュニケーション目標：図を見た読者に何を理解してもらうか。
5. 必須のノード、エッジ、権限の境界、誤解を招く含意として避けるべきもの。
6. アスペクト比と最終的な掲載幅の目安。
7. Figure Plan v1 JSON。

所定の図表タイプ：Overall Framework、Network Architecture、Module Detail、Comparison/Ablation、Data Behavior、Concept/Motivation、Protocol/Sequence、Timeline/Lifecycle。

ワークフロー

1. 入力モードと構成を特定する

• 草稿モード（.md のメモ／アウトライン／未整理の文章／草稿）：
  • 構造化されたMarkdown：
    • 見出し（#、##）：主要な意味的コンテナ領域（例：入力コンテキスト、コアフレームワーク、最適化目標）。
    • リスト（1. 2. 3.、- ）と矢印（->）：段階的な処理、データフロー、パイプラインの手順。
    • 太字の用語（**Name**）：正式なノード／モジュールのラベル（visible_text）。
    • インラインコード（`B x C x H x W`）：テンソルの次元やデータの説明。
  • 未整理／プレーンテキストのメモ：
    • 文の主語・動詞・目的語の流れ（例：「入力XはYによってエンコードされ、損失Zによって教師あり学習される」）をたどり、エンティティ、変換、データフローを抽出します。
    • 3つの標準パネルに分類します：入力／コンテキスト -> コア手法／相互作用 -> 出力／教師信号。
  • 形式的な主張の検証は省略し、図1のナラティブなトポロジーに進みます。
• 全文モード：
  • 序論、手法、実験、分析、限界を整理します。主張されている各貢献について、出典箇所と、視覚的な表現の根拠となり得る証拠を記録します。

2. 図の役割を割り当てる

視覚表現によって理解が実質的に向上する場合に限り、図を推奨してください。

読者の疑問／目的	一般的な種類	典型的な優先度
全体を通したアイデアと権限／データの流れはどのようなものか？	全体フレームワーク	必須（ドラフトではデフォルト）
概念的な動機や問題設定は何か？	概念／動機	高または必須
内部の実行可能な構造はどのようなものか？	ネットワークアーキテクチャ	必須または高
中核となるメカニズムはどのように機能するか？	モジュール詳細	必須または高
実証的に重要な選択肢は何か？	比較／アブレーション	高
データ、時間、条件によって挙動はどのように変化するか？	データの挙動	高またはあると望ましい
コンポーネントは時間またはプロトコルに沿ってどのように連携するか？	プロトコル／シーケンス／タイムライン	高

投稿先の慣習や固定の図数を要件として扱わないでください。ドラフトのメモでは、影響度の高い図を1つだけ図1として作成してください。

3. ナラティブの構造を設計する

各図について、次を指定してください。

• communication_goal と claim_scope；
• hero_element：単に最も大きなボックスではなく、視覚的なストーリーの中心となる要素；
• 原文の根拠またはドラフトの構成に基づく required_nodes と required_connections；
• 紙面が足りない場合に省略できる secondary_context；
• forbidden_claims と forbidden_connections；
• エージェント、ツール、外部オラクルが関わる場合の authority_boundaries；
• 短いラベルを使い、詳細はキャプションに回す text_budget；
• ユーザーが参照画像を提示した場合の reference_style_profile。

全体フレームワークは、必ずしも左から右への連鎖である必要はありません。科学的なストーリーに応じて、ループ、ストーリーボード、非対称なモジュールのコラージュ、階層型の権限図、中心となるメカニズムと周辺要素、またはパイプラインを選択してください。

4. 論文掲載用の図形サイズを設定する

• 全体フレームワーク：通常、2段組の幅（183 mm）に合わせた16:9または3:2。
• ネットワークアーキテクチャ／パイプライン：トポロジーに応じて、16:9、3:2、または縦長のレイアウト。
• モジュール詳細／概念：一般的に4:3または1:1。
• 比較／アブレーション：パネルの数と読み進める順序に合わせる。
• データの挙動／タイムライン：軸と系列に応じて決める。

5. Figure Plan v1 を出力する

{
  "schema": "academic-figure/FigurePlan@1",
  "source_revision": "<paper-or-repo-revision>",
  "venue": null,
  "sources": [],
  "figures": [
    {
      "figure_id": "fig1",
      "figure_type": "Overall Framework",
      "priority": "must",
      "communication_goal": "<one sentence>",
      "claim_scope": ["<evidence-backed claim or draft objective>"],
      "hero_element": "<loop|mechanism|modular collage|pipeline|other>",
      "required_nodes": ["<component-id>"],
      "required_connections": ["<from-id> -> <to-id>: <kind>"],
      "authority_boundaries": [],
      "secondary_context": [],
      "forbidden_claims": [],
      "forbidden_connections": [],
      "aspect_ratio": "16:9",
      "final_width_mm": 183,
      "style_profile_hint": null,
      "reference_assets": [],
      "open_questions": [],
      "confidence": "high|partial|sparse",
      "review_status": "pending|confirmed|waived"
    }
  ]
}

この例はフィールドのみを定義しています。すべてのプレースホルダーを、根拠のある内容または明示的な null／空の値に置き換えてください。

入力が限られている場合とドラフトの扱い

• .md のドラフトまたはメモのみ：見出しと箇条書きからパイプラインを直接抽出し、すぐに図1を計画してください。
• タイトルと要旨のみ：上位レベルの図の役割を計画し、サブモジュールを創作しないでください。
• 実験のない手法：手法のフレームワークを計画し、作業を止めたり、根拠のないエラーを報告したりしないでください。
• リポジトリの引き継ぎのみ：システム中心の計画を作成し、ナラティブの確認が必要であることを明記してください。
• 参照画像のみ：視覚表現の文法を分析し、トポロジーを計画する前に、対象システムの内容を提示または特定するよう求めてください。

停止

戦略と Figure Plan v1 を提示したら停止してください。ユーザーが後続のワークフローを依頼していない限り、プロンプトや画像を生成しないでください。