paper-evidence-board

論文エビデンスボード

研究プロジェクトの論文向けビューを管理します。論文でどのような主張をしているか、その主張をどのエビデンスが裏付けているか、主張がどこに記載されているか、査読者がどこを問題視する可能性があるか、投稿前にどのような対応が必要かを把握します。

次のような場合に、このスキルを使用してください。

• 論文の執筆中に、主張を裏付けるエビデンスが不足していると判明した
• 新しい実験結果に合わせて、論文の説明、図、節の更新が必要になった
• 査読シミュレーションにより、実験や執筆に関する対応事項が生じた
• 投稿前に、論文草稿の主張とエビデンスを整合させる必要がある
• 図や表を論文の主張に対応付ける必要がある
• 図表のスタイルを、配色、マーカー、記号、タイポグラフィ、投稿先の慣例などを含む執筆上の決定事項として管理する必要がある
• 論文の進捗を継続的に把握できるエビデンスボードが必要である
• 不足部分に対して、追加実験、書き換え、主張の範囲縮小、または資料の削除のどれが必要かを決める必要がある

このスキルは research-project-memory よりも対象を絞っています。プロジェクト全体の事実を横断的に把握する情報源としてプロジェクトメモリを使用しつつ、執筆と査読の判断に向けた論文用ボードを作成します。

次のスキルと組み合わせてください。

• プロジェクト全体の主張／エビデンス／来歴／リスク／対応事項／引き継ぎの ID と書き戻しには research-project-memory
• 主張やエビデンスの変更に応じて論文内の該当箇所を古い状態としてマークしたり、依存関係を更新したり、執筆スレッドを作成したりする場合は paper-writing-memory-manager
• 主張を裏付けるエビデンスが不足しており、新たな計算を計画する前に既存の結果 CSV を調べる場合は paper-evidence-gap-miner
• CSV の結果を論文用の表、図、来歴記録に変換する場合は paper-result-asset-builder
• ボードで構成や段落レベルの変更が必要と判明した場合は conference-writing-adapter
• 新たな実験が必要なエビデンス不足がボードで明らかになった場合は experiment-design-planner
• 新しいエビデンスによって主張が弱まったり、複雑になったりした場合は result-diagnosis
• 査読者の視点からボードを厳しく検証する場合は paper-reviewer-simulator
• 図表について、主張の裏付け、キャプション、統計、または視覚スタイルをレビューする場合は figure-results-review
• 新規性や関連研究の不足が見つかった場合は citation-coverage-audit

スキルディレクトリの構成

<installed-skill-dir>/
├── SKILL.md
└── references/
    ├── board-schema.md
    ├── evidence-gap-triage.md
    ├── paper-section-map.md
    ├── report-template.md
    ├── reviewer-risk-integration.md
    └── update-protocol.md

段階的な読み込み

• 必ず references/board-schema.md、references/evidence-gap-triage.md、references/update-protocol.md を読みます。
• 草稿から節ごとのボードを作成する場合は、references/paper-section-map.md を読みます。
• 査読シミュレーション、実際の査読結果、または投稿先固有のリスクを扱う場合は、references/reviewer-risk-integration.md を読みます。
• 実質的な内容を含むボードレポートには、references/report-template.md を使用します。
• 投稿先固有のエビデンス要件が重要な場合は、現在の投稿規定や査読フォームを確認します。

基本原則

• 論文の主要な主張には、それぞれ論文内の箇所、エビデンスの状態、査読上のリスクを設定します。
• エビデンスは、文章による記憶だけでなく、元となる成果物を参照する必要があります。
• 図表には役割を持たせます。主張の裏付け、査読者の疑問への回答、または対象範囲の明確化に使用します。
• 論文向けの図表は、正しい数値を示すだけでなく、論文の視覚的なスタイル方針にも従う必要があります。
• エビデンス不足は、必ずしも執筆上の問題とは限りません。実験設計、結果の診断、主張の範囲縮小、または引用文献の調査が必要な場合もあります。
• 否定的な結果や弱い結果を隠してはいけません。主張がどのように変わるかを記録します。
• ボードを実行可能な状態に保ちます。未解決の不足事項はそれぞれ、次に使用するスキルまたは対応事項につなげます。

ステップ 1 - 論文とプロジェクトメモリの場所を特定する

次を探します。

• 論文のルート：paper/、現在のディレクトリ、またはユーザーが指定したパス
• プロジェクトルート（論文ルートと異なる場合）
• memory/claim-board.md
• memory/evidence-board.md
• memory/provenance-board.md
• memory/risk-board.md
• memory/action-board.md
• memory/handoff-board.md
• memory/phase-dashboard.md
• paper/.agent/paper-status.md
• main.tex、paper.tex、sections/*.tex、図、表、付録などの論文ソース

プロジェクトメモリがない場合も、草稿から論文ボードを作成します。そのうえで、research-project-memory の初期化を推奨します。

Step 2 - 論文の主張を抽出する

草稿または提供されたメモを読み、以下を抽出します。

• タイトルと要旨の主張
• 序論の貢献に関する箇条書き
• 手法に関する主張
• 理論に関する主張
• 実験に関する主張
• 関連研究における新規性の境界
• 限界と適用範囲に関する主張

CLM-### ID を割り当てるか、既存のものを再利用します。各主張について、以下を記録します。

• 論文内の正確な位置
• 主張の種類
• 強さ
• 現在の表現におけるリスク
• 期待されるエビデンス
• 入手可能なエビデンス

貢献を目指す表現を、実証済みのエビデンスとして扱わないでください。

Step 3 - エビデンスを主張に対応付ける

references/board-schema.md を読みます。

すべてのエビデンス項目について、以下を行います。

• ソースのパス、実行 ID、表、図、定理、引用、またはレビュー文を特定する
• 主張 ID にリンクする
• ステータスを付ける：planned、running、observed、reported、stale、contradicted、または cut
• 確実性を付ける：observed、user-stated、inferred、stale、または needs-verification
• 限界を記載する

エビデンスが日次ログまたはチャットメモにしかない場合は、その旨を記し、ソースの成果物を検証するアクションを作成します。エビデンスが CSV の結果ファイルに存在する可能性があるものの、論文に掲載できる表や図がない場合は、新たな計算が必要なギャップとする前に、paper-evidence-gap-miner と paper-result-asset-builder に回します。エビデンスの変更が既存の論文テキストに影響する場合は、paper-writing-memory-manager に回し、依存するタイトル、要旨、セクション、キャプション、限界、または結論を古いものとしてマークします。

Step 4 - セクションと図・表のマップを作成する

references/paper-section-map.md を読みます。

以下を作成します。

• セクションマップ：セクション -> 主張 -> エビデンス -> リスク -> アクション
• 図・表マップ：図・表 -> エビデンス -> 主張 -> 必要なキャプションメッセージ -> 古さのステータス
• ビジュアルスタイルマップ：配色、手法とマーカーの対応、タイポグラフィ、記号、図のサイズ、表の慣例
• 必要に応じて付録マップ

以下を特定します。

• 複数箇所で繰り返され、強さに一貫性がない主張
• 対応する主張がない図
• 期待される図・表・証明・引用がない主張
• 新しい結果の後も更新されていない図
• 論文内のビジュアル間で一貫性のない色、記号、手法名、フォントサイズ、図のサイズ
• 本文で議論されていない結果表

Step 5 - エビデンスのギャップをトリアージする

references/evidence-gap-triage.md を読みます。

各ギャップについて、以下を判断します。

• mine-existing-results：新たな計算の前に、既存の CSV、ログ、レポート、成果物を検索するため、paper-evidence-gap-miner が必要
• build-result-asset：再利用可能な CSV エビデンスを論文用の表または図にするため、paper-result-asset-builder が必要
• new-experiment：既存の結果では不十分なため、experiment-design-planner が必要
• result-diagnosis：既存の結果が曖昧または矛盾している
• rewrite：エビデンスはあるが、本文が過大な主張をしている、またはエビデンスを見えにくくしている
• narrow-claim：エビデンスが裏付けるのは、より限定的な主張である
• citation-work：主張に不足している関連研究または出典の明示が必要
• cut：裏付ける価値のない主張である
• accept-risk：修正する代わりに、限界として明記できる

リスクの高いギャップはすべて、アクションを作成する必要があります。

Step 6 - 査読者リスクを統合する

references/reviewer-risk-integration.md を読みます。

以下を使用します。

• paper-reviewer-simulator による模擬査読者リスク
• citation-coverage-audit による引用リスク
• rebuttal-strategist による実際の査読リスク
• 判明している場合は、投稿先に固有の期待事項

各リスクを以下に対応付けます。

• 主張
• 論文内の位置
• エビデンスのギャップ
• 修正の種類：実験、分析、証明、引用、書き換え、図・表、限界、または反論
• 優先度

Step 7 - ボードとアクションを作成する

出力全体については references/report-template.md を使用します。

プロジェクトに保存する場合、パスが指定されていなければ、以下を使用します。

paper/.agent/paper-evidence-board.md

以下を出力します。

• 論文のスナップショット
• 主張とエビデンスのマトリックス
• セクションマップ
• 図・表マップ
• ビジュアルスタイルマップ
• エビデンスのギャップ
• 査読者リスクマップ
• アクションプラン
• プロジェクトメモリへの書き戻し

ステップ 8 - プロジェクトメモリへの書き戻し

プロジェクトで research-project-memory を使用している場合は、以下を更新します。

• memory/claim-board.md：主張の状態、表現、論文内の位置、弱めた主張や削除した主張
• memory/evidence-board.md：エビデンスのソースパス、図表の対応関係、古さの状態、制約
• memory/provenance-board.md：実行結果、CSV、レポート、引用、図、表、キャプション、結果の記述から EVD-### および CLM-### への追跡可能性
• memory/risk-board.md：エビデンスの不足、執筆、新規性、ベースライン、査読者に関するリスク
• memory/action-board.md：実験、診断、書き直し、引用、図表、レビューに関するアクション
• memory/handoff-board.md：別のスキルで対応する必要があるエビデンスの不足、アセットの作成ニーズ、レビューでの修正、執筆上の依存関係
• memory/phase-dashboard.md：主張を裏付ける状況が変化し、プロジェクトのフェーズを進める、または後退させる場合は、現在の論文／エビデンスのゲート
• paper/.agent/paper-status.md：論文の各セクションの現在の状態
• paper/.agent/visual-style.md：視覚的な慣例が重要な場合の、論文用の図表スタイル方針
• paper/.agent/paper-evidence-board.md：論文用のボード

長い実験レポートを重複させないでください。レポートへのリンクを記載してください。

最終確認

最終版を作成する前に、以下を確認してください。

• 主要な主張すべてに、位置とエビデンスの状態が示されている
• 裏付けのない主張には、計画中、範囲縮小、または削除のいずれかが明記されている
• すべての主要な図表に、主張に関連する役割がある
• 論文用の図表で、色、マーカー、記号、タイポグラフィ、サイズ、表記が一貫している
• 古くなったエビデンスが明記されている
• 査読者に関するリスクがアクションにリンクされている
• 次のアクションが適切なスキルに割り当てられている
• プロジェクトメモリが存在する場合は更新されている