paper-details

論文の詳細

学術論文を詳しく解説する Markdown 文書を作成するための規約です。このスキルの目的は、論文を批評することではなく、正確に説明することです。

このスキルでは、documenting-with-sources で定義されている共通の出典付きライティング規約に従います。執筆を始める前に、documenting-with-sources を読んでください。

1. 成果物の構成

1.0 出力先

解説文は、プロジェクトの reports/ ディレクトリ内に .md ファイルとして作成します。ここでいう「プロジェクト」とは、元の論文 PDF が置かれているルートディレクトリです。ディレクトリが存在しない場合は作成してください。

• パス：{project-root}/reports/{paper-filename-base}.md
• 例：PDF が /path/to/project/papers/foo.pdf にある場合、出力先は /path/to/project/reports/foo.md です。

PDF と同じディレクトリや、プロジェクトのルートディレクトリには作成しないでください。出力先をユーザーに尋ねず、上記の規則に従って機械的に決定してください。

1.1 冒頭

次の順序で記載します。

1. タイトル（# {paper title} — Detailed Explainer）
2. 書誌情報（著者、所属、掲載誌・会議、年、arXiv/DOI、URL）
3. アブストラクト全文 — writing-quotation に従い、原文をコードブロックに引用してください。原文が作業言語以外の場合は、同じブロック内に別の段落として翻訳を併記してください。

1.2 本文のセクション構成

本文のセクション構成は、論文の構成に従います。論文に Section 1 Introduction、Section 2 Method、Section 3 Results、…がある場合、解説文でも同じ順序と見出しを使用してください。

「論文の強み」「論文の限界」「出典一覧」など、解説文独自のセクションは、論文本来のセクション構成の後に追加してください。

1.3 箇条書きと文章

内容に応じて形式を選びます。

• 箇条書きは、並列する項目の列挙に適しています。変数の一覧、評価指標の定義、表の列の説明、手法間の比較点など、内容が本質的に一覧形式である場合は、文章にすると項目の区切りが曖昧になります。
• 文章は、関係性、因果関係の流れ、背景を説明するのに適しています。項目が一緒に提示される理由や、ひとつの議論をどう構成しているかを理解する必要がある場合は、文章で説明することで筋道が明確になります。

1.4 図と表：画像として抽出する

図や表を一から再作成してはいけません（手書きの HTML テーブルや、描き直した SVG 図は禁止です）。元論文から画像として抽出し、成果物（.md または HTML）に挿入してください。手作業での再作成は転記ミスを招き、太字、下線、色分けされた凡例などの元のレイアウトも失われるため、禁止されています。

このスキルに同梱されているスクリプトを使用してください。

uv run {this-skill-dir}/scripts/extract_images.py <PDF path>

• スクリプトは PDF 内の Figure N / Table N のキャプションを見つけ、各キャプションのすぐ上にある図表領域（ベクター描画、罫線、埋め込み画像のバウンディングボックス）を 300 dpi でクリップしてレンダリングします。図や表は通常、埋め込みラスター画像のないベクターとして描画されているため、これは埋め込み画像の取り出しではなく、領域のレンダリングです。
• 出力先の既定値は {project-root}/images-from-papers/ で、ファイル名は {paper-filename-base}-fig{N}.png / {paper-filename-base}-table{N}.png です。抽出リストは同じディレクトリ内の {base}-manifest.json に記録されます。
• 複数パネルのフロート（例：パネル (a)～(f) を含む 1 つの Table フロート）は、論文中のフロートと同じく、1 枚の画像として抽出されます。
• 抽出後、images-from-papers/ の画像を成果物に挿入してください。.md では、相対パスで参照します（例：![Figure N](../images-from-papers/{base}-fig{N}.png)）。html で作成した HTML 成果物では、base64 データ URI として埋め込んでもかまいません。
• 画像の下に、翻訳したキャプションを別の段落として追加してください。画像内のキャプションの文面は元の言語のままです（描き直さないため）。そのため、翻訳は画像の外に記載します。
• スクリプトが図表を取りこぼしたり、余白を取り込みすぎたりすることがまれにあります。その場合は --dpi を上げるか、出力を確認し、該当項目の pymupdf クリップ矩形を調整してください。いずれの場合も、画像抽出の方法を放棄してはいけません。

2. 引用と出典の参照

2.0 出力の中心は翻訳した引用ブロック

解説文書は、論文の本文全体をカバーする「原文の引用＋翻訳」のブロックを中心に構成してください。要約や言い換えの文章を主役にしてはいけません。文書全体を通して、読者が原文と翻訳を照合できるようにしてください。

文章（執筆者独自のテキスト）は、引用を中心とした流れを補うためのものであり、次のいずれかに該当する場合にのみ追加します。

• 引用ブロック同士のつながりが不明瞭で、セクションや段落間の関係や論理の流れを補足する必要がある場合。
• 変数の定義、前提知識、図表の読み方、用語が初めて登場した際の定義など、補足説明が読者にとって本当に役立つ場合。

どちらにも該当しない場合、原文の内容を文章で再度要約せず、引用ブロックに語らせてください。「引用で要旨を示し、文章で要約する」という分担に落ち着かないようにしてください。

論文の主張を正確に伝えるため、原文からの直接引用を含めてください。要約だけでは、読者が執筆者の解釈が正しいかどうかを判断できません。

documenting-with-sources で定義されている [label (YYYY/MM), location] の形式では、paper-details スキルにより、参照する文献に応じてラベル欄の記載方法が異なります。

対象論文への言及

対象論文に言及する場合、著者名と年は省略し、[p.X, Section Y.Z] の形式で位置だけを引用してください。解説文書全体が単一の論文を扱うため、毎回著者名を繰り返す必要はありません。

例：[p.4, Section 1]、[p.21, (15)]、[p.31, Figure 2]。

他の研究への言及

論文が引用している他の研究については、本文中で [author-short (YYYY)] を使用してください。

• 節、ページ、表、図の番号を使って、引用箇所を特定してください。
• 引用した研究の一覧を「…など」といった表現で省略しないでください。著者名と年を添えて、各研究を個別に列挙してください。解説の読者はこの一覧を頼りにしています。解説対象の論文だけを引用しても、論文が参照している研究の名前を挙げたことにはなりません。

3. 数式

3.1 構文

• 数式は LaTeX で記述します。インライン数式は $...$、ディスプレイ数式は $$...$$ で囲みます。
• 禁止事項：数式をコードブロック内に記述すること。数式をプレーンテキスト形式、擬似コード形式、または LaTeX 構文以外で記述すること。

3.2 変数の定義

数式に登場する記号は、定義されるまでは読者にとって未知のものです。数式を示す前に、そこに登場するすべての変数と記号を定義してください。スコープ内で変数が定義されていない数式を置いてはいけません。

理論や手法の形式化など、数式が多い節では、節の冒頭に変数表を置いてください。変数は役割ごとにまとめます。各項目には、次の内容を含めてください。

• 記号（LaTeX 形式）。
• 意味（1 文）。
• 直感的な理解に役立つ補足（具体例、値の範囲、特殊なケースでの挙動）。

例：

Inputs:

- $n$: number of characters in the input text. The length of the user's prompt.
- $K$: the model's context-window length in characters. Inputs longer than this cannot be passed to the model directly.

Planner outputs:

- $k^*$: branching factor at each level — how many chunks to split into. With $k^*=5$ the input is split into five chunks at each level.
- $\tau^*$: threshold below which the chunk is sent to the LLM as-is, without further splitting. With $\tau^*=26{,}000$, chunks of 26,000 characters or fewer go straight to the LLM.

数式が少ない節では、各数式の前後で変数を文章中に定義してもかまいません。ただし、未定義の記号を含む数式を置かないという原則は守ってください。

4. 数値結果

• 可能な場合、実験結果は表で示してください。
• 提案手法とベースラインを横に並べてください。
• 数値は論文に記載されているとおりに正確に転記してください。丸めたり、概算したりしてはいけません。
• 表を示す前に、箇条書きで各列と各指標を定義してください。読者が数値を見る時点で、各列の意味が明確になっている必要があります。
• 「精度」や「性能」といった一般的な語を曖昧に使ってはいけません。論文で定義されている指標名（分類精度、合格率、pass@1 など）を使用してください。
• 論文内で同じ語が異なる意味で使われている場合（たとえば、表では「最良の単一結果」を意味する手法名が、本文では「手順全体」を意味する場合）、その多義性を明示してください。

5. 実験の説明

5.1 手順を具体的に説明する

実験の節では、読者が実際に行われたことを追えるようにしてください。次の内容を省略してはいけません。

• 具体的なタスクの手順（入力が何か、各ステップで何が生成されるか、最終出力は何か）。
• データ分割の構成（探索セット／検証セット／テストセットの用途と、それぞれの分割に対応する結果）。
• 探索または最適化の手順（初期状態、反復回数、各反復で生成されるもの、最終結果を選択する基準）。

5.2 節ごとの独立性

各実験の節だけで内容が理解できるようにしてください。略語の説明がないまま「第 X 節で定義した手法」といった参照をしてはいけません。2 つの実験が同じ探索手順を共有している場合も、各節で実験固有のパラメーターを含めて、その手順を改めて説明してください。

5.3 詳細度の統一

論文に複数の実験の節がある場合、それぞれで詳細度を統一してください。ある節では探索手順を詳しく説明し、別の節では一文で済ませることは避けてください。

5.4 概念は使用前に定義する

解説で初めて登場する概念は、使用する前にすべて定義してください。論文自体が定義している概念を省略してはいけません。特に、表や数値を示す前に、その数値を読み取るのに必要な概念をすべて定義してください。

6. 出典一覧

出典一覧は解説の末尾に置き、documenting-with-sources に従って書式を整えてください。解説対象の論文に加えて、解説内で言及した他の研究もすべて含めてください。

7. セクションごとのサブエージェント監査

初稿には、1回読み直すだけでは見落としやすい誤りが含まれていることがよくあります。たとえば、数字を1桁間違えて転記している、引用番号が誤った参考文献に対応している、原文から訳文への意味がずれている、論文の引用が解説に反映されていない、といった誤りです。初稿を完成とみなす前に、サブエージェントを使ってセクションごとに監査してください。

7.1 出力先

監査結果は {cwd}/subagent-reviews/{NN-section-name}.md に書き込みます。セクションごとに1つのファイルを作成してください。ディレクトリが存在しない場合は作成します。監査結果は解説とは別の成果物です。reports/ の下には置かないでください。

7.2 セクション分け

解説を、論文のセクション構成に沿った独立した単位に分割します。

• 要約と書誌情報（1つの単位）
• 論文本文の各トップレベルセクション（序論、背景／関連研究、手法、実験、限界、結論など）
• 解説末尾の参考文献一覧

実験が複数のサブ実験や表を含む場合など、大きなセクションは、1人の監査担当者が扱うには分量が多すぎるとき、さらに分割できます。1つのファイルにつき監査担当者は1人にしてください。

7.3 監査担当者への指示

セクションごとに汎用サブエージェントを1つずつ、並列で起動します。各サブエージェントには、次の作業を指示します。

1. 論文の PDF と、対応する解説のセクションを読む。
2. 事実の正確性を確認する。主張、数式、表中の数値と本文中の数値、引用番号と参考文献の対応関係を確認する。
3. 解説が原文以外の言語で書かれている場合は、翻訳の正確性を確認する。訳抜け、原文にない含意の追加、不適切な語順、原文の慣用表現の未翻訳を確認する。
4. 書式の遵守を確認する。引用形式（対象論文には [p.X, Section Y.Z]、その他の文献には [author-short (YYYY)]）、** による太字装飾がないこと、writing-quotation の引用ルール（コードブロックでの引用、原文と訳文の対、ブロック外の独立した行に記載された出典参照）を確認する。
5. セクション内で用語が一貫していることを確認する。

各監査ファイルには、「全体評価」「指摘事項」「修正案」の3つの見出しを使います。指摘事項では、解説内の具体的な行や引用箇所を示します。翻訳に関する問題については、原文と解説での訳文の両方を引用し、統合時に並べて比較できるようにしてください。

7.4 統合と修正

すべての監査結果が返ってきたら、次の手順を実行します。

1. 各監査ファイルを最後まで読みます。
2. 指摘を適用する前に、論文そのものと照らし合わせて確認します。監査担当者が間違っている場合もあり、同じ事実について2人の監査担当者が異なる判断をする場合もあります（たとえば、2人の査読者が数値引用 [16] を異なる参考文献に対応づける場合など）。その場合は、論文の参考文献一覧を調べ、原文に基づいて矛盾を解消します。
3. 確認済みの修正を解説に反映します。
4. セクションをまたいで重複する修正（たとえば、複数箇所で繰り返される引用ラベルの変更）を適用する場合は、すべての箇所で一貫して変更します。
5. 指摘を解決したら次に進みます。「監査への回答」という別文書を書く必要はありません。監査済みの解説自体が成果物です。

7.5 用語

このスキルが作成する成果物は詳細な解説であり、レビューではありません。監査の出力はレビューです。ユーザーとの会話やタイトルでは、これらの用語を使い分けてください。解説を「レビュー」と呼んだり、監査を「詳細な解説」と呼んだりしないでください。この区別により、ワークフローの途中でユーザーから「レビューを更新して」と依頼されたときに、曖昧さが生じるのを防げます。