paper-reading

論文を読む

論文レポートは、長い要約ではなく、検証可能な根拠に基づく論証として扱います。論文の種類に応じて、参照資料で定義されたレポート構成を使用し、仕組み、根拠、比較、限界、または示唆を加えない文は削除します。

同梱のスクリプトやアセットを使用する前に、<skill-dir>をこのファイルが格納されているディレクトリとして解決します。

例では、PYTHON_EXEは、互換性のある有効化済みまたは分離された環境の実際のインタープリターを意味します。たとえば、python3、python、py -3、または仮想環境の実行ファイルの絶対パスです。現在のプラットフォームに合わせて解決し、このトークンをそのまま実行したり、特定のコマンド名が存在すると仮定したりしないでください。

1. 出力形式を選ぶ

明示された形式、または明らかに意図されている形式に従います。それ以外の場合は、MarkdownとHTMLのどちらを希望するかを一度だけ尋ね、その後は回答を待ちます。Markdownは軽量で編集しやすく、HTMLはデザインされた閲覧画面、1つのセクション目次、静的な数式、クリックで拡大できる図を提供すると簡潔に説明します。

「すぐに理解したい」のような手早い概要を求める依頼でも、すべてのレポートで深さは一貫させます。論証全体を読み、論拠となる技術的詳細をすべて残したうえで、簡潔に記述します。このワークフローでは再現実験を実施しません。

ゲート：formatを記録します。本当に曖昧な場合に、形式を黙って選んではいけません。

2. 出典を確認する

ローカルまたはリモートのPDF、公式の全文HTML、または貼り付けられた全文を受け付けます。PDFが利用可能な場合は、ページと図の参照位置が安定しているため、PDFを優先します。ただし、PDFを必須にはしません。

PDFの場合、出典は変更せず、新しいディレクトリに抽出します。

uv run --isolated --no-project --with pymupdf4llm==1.28.0 \
  python <skill-dir>/scripts/extract_paper.py PAPER.pdf EXTRACTED_DIR

uvが利用できない場合は、分離された標準のvenvを使用します。可能であれば、すでに利用可能な互換環境を再利用します。Condaの使用や、ベース、システム、グローバル環境へのインストールを決して要求しません。

抽出ツールは、ページ参照付きのテキスト、出典のハッシュ、変更不可のassets/raw/マニフェストを作成します。選択した図版はレポートにコピーし、「整理」のために生の抽出データを削除してはいけません。

公式HTMLまたは貼り付けられたテキストの場合は、セクション名と安定したURLをアンカーとして保持します。ページ単位のアンカーが利用できない場合は、その旨を記載します。

**ゲート：**論文全文と関連性の高い付録を読める状態にし、出典情報を内部的に記録し、採用する図版すべてを出典まで追跡できるようにします。

3. 論文を分類する

タイトル、要旨、序論、貢献の説明、セクション構成を読み、主分類を選びます。

• **実証論文：**新しい手法／モデルとベースライン実験 → empirical.mdを読みます。
• **理論論文：**定理／証明が貢献の中心 → theoretical.mdを読みます。
• **サーベイ論文：**分野全体の分類体系または統合的な分析 → survey.mdを読みます。
• **システム論文：**システム設計、実装、ベンチマーク → systems.mdを読みます。

必ずshared-sections.mdを読みます。複数の種類にまたがる論文でも主分類は1つにし、名前を指定した副分類から必要なモジュールだけを追加します。スキャフォールドには主分類を渡します。hybridは5つ目の包括的な分類ではありません。曖昧な論文を実証論文と決めつけず、まず貢献と根拠を確認します。

**ゲート：**主分類、副分類のモジュールがあればその内容、および分類の根拠を記録します。

4. 論文全体を読む

手法の適用範囲を定める論文本文と付録をすべて読み、手法の適格性、証拠、前提、否定的な結果、または限界を確認します。

以下を明らかにします。

• 課題、前提、最も近い比較対象、実現の鍵となる知見；
• 重要な役割を担うすべてのモジュール、そのインターフェース、実際の学習／推論ループ；
• 主要な方程式、記号、目的関数、データ、前処理、教師信号、アーキテクチャ、最適化、評価プロトコル；
• 主な結果、ベースライン、アブレーション、失敗事例、結果が変化する条件；
• 著者の主張、証拠が裏付ける内容、推論にとどまる内容。

実証研究やシステム研究については、モジュール単位のエンジニアリング構造を記述します。重要な役割を担うモジュールごとに、目的、正確な入力、正確な出力、アーキテクチャと主要なパラメーター、学習データと教師信号、学習方法／目的関数／最適化、推論時の役割、隣接モジュールとのインターフェース、コード上の根拠を示します。モジュールのタイトルの直下、各フィールドの上に、論文の内容に基づく横幅いっぱいの SVG を 1 つ配置し、入力 → 中核となる変換 → 出力の流れを横方向に示します。異なる入力と出力はそれぞれ独立した、重ならないノードにします。記号で表される入力と出力には、形状／範囲がわかる場合はそれも含め、静的なインライン MathML としてレンダリングされる明示的な LaTeX 表記を付けます。並列項目には、文章に列挙事項を詰め込むのではなく、箇条書きを使います。フィールドを省略せず、該当しない場合は not applicable、学習済みパラメーターを更新しない場合は frozen、情報が報告されていない場合は not reported と明記します。

ゲート： 技術的な素養のある読者が推測せずにシステム境界とデータフローを再構成でき、レポートを短くするためだけに重要なフィールドが省かれていないこと。

5. 信頼できるコードを読み取り専用で調査する

code-audit.md を読みます。公開コードの有無について、論文／プロジェクトの公式情報を確認します。信頼できるコードがある場合、ユーザーが再現を依頼していなくても、リビジョンを固定し、読み取り専用で調査して、モジュールの入力／出力、テンソルまたはデータの形状、アーキテクチャ、デフォルト値、損失、データパイプライン、学習スケジュール、推論経路を検証します。

このワークフローでは、依存関係のインストール、プロジェクトのインポート、デモの起動、モデルの重みやデータセットのダウンロード、学習／評価の実行を行わないでください。ウェブ上の確認だけでは不十分な場合、一時的な浅いクローンは許可されます。クローンは変更せず、削除するか、レポートの作業場所の外に置いてください。

実装に関する各記述には、論文に記載、コードで確認、論文／コード間の不一致、またはレポートの推論のいずれかを明記します。信頼できる実装が見つからない場合は、確認した情報源と public code not found を記載します。非公式リポジトリを、説明なしに代替として使ってはいけません。

ゲート： 各モジュールカードにコード上の根拠、またはコードなし／未報告であることの明示的な記載があり、論文とコードの不一致が見えること。

6. 主張と証拠のつながりを構築する

evidence.md を読みます。C（主張）、E（証拠）、L（限界）の座標を管理します。重要な結果や批判には、すべて根拠を示します。批判に前提、比較対象、失敗事例、または未実施のテストのいずれかが明示されていない場合、その批判は未完成です。

著者の主張、コードで確認した内容、レポートの推論、外部の一次資料が示す内容を区別します。明示的に依頼されない限り、より広範な新規性調査や先行研究調査は別のタスクとして扱います。

ゲート： 重要な記述のすべてが論文、コード、または一次資料上の正確な根拠に結び付き、推論には推論であることが明記されていること。

7. ビジュアルを選択して描画する

HTML の場合は、visuals.md と html-report.md の両方を読んでください。

モジュール構造の説明以外では、SVG の使用数に上限はありません。説明効果に応じて、文章、整列したリスト、表、オリジナルの図、HTML／CSS、SVG を使ってください。モジュール構造の説明は明確な例外です。データの流れを細部を読む前に確認できるよう、主要な各モジュールの項目より上に、控えめな横長のインターフェース SVG を1つ配置してください。細いサイドレールに押し込んだり、スペースを節約するために別々のインターフェース値を統合したりしないでください。図はシンプルかつ具体的に保ち、すべての SVG を描画して確認してください。HTML 内のすべての画像と SVG はライトボックスで開けるようにしてください。

実証論文では、論文の主要な結論を裏づける重要な結果図を、その結論の近くに配置してください。少なくとも、中心的な実証的主張を示す元のプロット、定性的なパネル、または結果の可視化を含め、HTML では data-original-result を付けてください。再作成した表、指標カード、説明用 SVG は証拠の理解に役立ててもかまいませんが、元の結果ビジュアルの代わりにはなりません。論文に結果図が実際に含まれていない場合は、結果セクションに data-original-result-unavailable="paper-has-no-result-figure" を付け、元の結果表をそのまま残してください。結果を読み取るために必要な軸、凡例、ベースライン、失敗例、限定条件を切り落とさないでください。

重要な数式は LaTeX ソースとして保持し、HTML リファレンスの指定に従って scripts/render_math.py で静的な MathML に変換してください。すべてのディスプレイ数式の直下に自然な文章を置き、その数式に含まれる文字、演算子、添字、明白でない記号をすべて定義してから、関係式全体が何を示し、なぜ重要なのかを説明してください。「直感的な説明」などの定型ラベルを文章の前に付けないでください。インライン表記は、スクロールできない1つの不可分な単位にしてください。長い因果関係はディスプレイ数式に移してください。実行可能なコード、パス、識別子にはコードスタイルを維持してください。

Markdown では、同じ内容と証拠の扱いを用い、選定した元の図を、それが裏づける主張の近くに配置してください。

**ゲート：**理解を妨げるすべての要因に最も明確な方法で対処し、すべてのビジュアルの忠実性と出典を確保してください。中心的な実証結果については、元の図がある場合、それを残してください。また、装飾目的の科学的内容を作り出さないでください。

8. 成果物を作成して検証する

ユーザーの言語を使用し、翻訳によって精度が損なわれる場合は、技術用語、数式、コマンド、識別子をそのまま保持します。

• Markdown：summary.md と、必要に応じてローカルの assets/ を作成します。
• HTML：ひな形を作成し、すべてのプレースホルダーを置き換えてから、次のように検証します。

PYTHON_EXE <skill-dir>/scripts/scaffold_report.py REPORT_DIR \
  --title "..." --title-focus "..." --authors "..." \
  --paper-type empirical --thesis "..."
PYTHON_EXE <skill-dir>/scripts/validate_report.py REPORT_DIR/summary.html

HTML の CSS と JavaScript はインラインにし、高解像度の論文アセットは相対パスを使って assets/ に保存します。

納品前に、次のことを行います。

1. ひな形のマーカーと、仕組み、根拠、比較、制約、含意を加えない文をすべて削除します。
2. ローカルリンク、座標、キャプション、数式、コードアンカー、アセットパスを確認します。表示する基本情報のセクションは、タイトル、リンク付きの著者／連絡先／研究室または研究グループ、刊行物、リンク、論文の種類、1 行の要約だけを含む簡潔な縦並びにします。ハッシュ、ページの規則、抽出ディレクトリ、アセット数は内部情報として扱います。
3. 実証研究／システムのレポートでは、重要なモジュールすべてに 9 つの解剖フィールドがそろっていること、それらの上に横幅いっぱいの入力→変換→出力 SVG が 1 つあること、個別の入力／出力ごとにノードがあること、実際の列挙には箇条書きを使っていること、記号的な入力／出力には LaTeX から生成したインライン MathML を使っていることを確認します。概要では、モジュール間の流れも説明します。
4. HTML はデスクトップと幅の狭いモバイルの両方でレンダリングし、アウトラインナビゲーションが 1 つだけであること、タイトルの階層、MathML、記号を漏れなく説明していること、インライン数式が分割されていないこと、すべてのビジュアル、ホイール／ピンチズーム、キーボードによる閉じる操作、印刷、動きを抑える設定への対応を確認します。
5. バリデーターが合格するまで実行し、ソースの範囲とコードを検査したかどうかを、確実性を誇張せずに明記します。

**完了条件：**論文の議論全体が簡潔に表現され、技術モジュールを再構成でき、根拠を追跡でき、公開コードが入手可能な場合は読み取り専用で検査され、出力がそのディレクトリからオフラインで動作し、制約が主要な主張と同じくらい容易に確認できます。