paper-navigator

Paper Navigator

学術論文を検索して読みます。意図に基づいて分岐し、関連性で判断します。

        User
         │
         ▼
   ┌── Router ──┐
   │            │
   ▼            ▼
 POINT      LIST/ITERATIVE
(1 paper)   (Probe + up to 3 paper rounds:
             R2 breadth / R3 deepen / R4 close)

関連性の判断はエージェントが行います。LLM-as-judge は呼び出さず、数値スコアも付けません。評価基準を作成し、各論文を選別して、関連性の高い順に並べます。

セットアップ

このドキュメント内のスクリプトパスは、このスキルのディレクトリからの相対パスです。python scripts/<name>.py で実行します。

依存関係：pip install deepxiv-sdk httpx（スキルのルートにある requirements.txt にも記載されています）。ユーザーが作業している環境にインストールしてください。

arXiv へのアクセス（arxiv_monitor、scholar_search のフォールバック）には DeepXiv SDK を使用します。pip install deepxiv-sdk を実行し、続いて deepxiv token を一度実行して無料の API トークンを取得します（~/.env に保存されます）。このスキルは、環境変数の DEEPXIV_API_TOKEN／DEEPXIV_TOKEN、または ./.env／~/.env からトークンを読み取ります。

環境変数	使用元	備考
S2_API_KEY	すべての S2 スクリプト	設定されていない場合：scholar_search は arXiv（DeepXiv 経由）にフォールバックします。citation_traverse／recommend／snippet_search は無効になります
DEEPXIV_API_TOKEN	arxiv_monitor、scholar_search のフォールバック	無料トークンの取得方法：deepxiv token（~/.env に書き込みます）。DEEPXIV_TOKEN および ./.env／~/.env からも読み取ります。1 日あたり約 10,000 件のリクエスト
JINA_API_KEY	fetch_paper	キーなしでも無料枠を利用できます
GITHUB_TOKEN	github_search、find_code	レート制限が緩和されます
PAPER_NAV_PAPERS_DIR	fetch_paper の全文	デフォルト値なし。設定するか、--metadata-only を渡してください

環境変数の全一覧：references/env-vars.md。

---

5 つの厳守事項（常に適用）

1. 検索履歴を記録する。 すでに実行したクエリを再実行しないでください。結果が空なら、類義語ではなく検索の切り口を変えてください。
2. 漠然とした印象ではなく、情報の不足を検索する。 各クエリは、欠けている情報の一項目に対応させます。キーワードを寄せ集めたクエリは使いません。
3. 1 つのクエリには 1 つの概念を指定する。 比較（A vs B）、複数の性質に関する質問、複数年にまたがる範囲は、それぞれ別の呼び出しに分割します。
4. 決して捏造しない。 事実（タイトル、著者、年、引用数、内容）はすべてツールの結果に基づくものとします。
5. 引用がなければ、該当なし。 論文が基準を満たすと主張する場合は、論文のアブストラクト／tldr／スニペットから 80 文字以内の引用を示してください。引用がなければ、その論文が基準を満たすと主張してはいけません。（これは捏造を防ぐためのルールであり、数値スコアには影響しません。）

---

ルーター

分岐	ユーザーのシグナル	実行頻度	出力
POINT	引用符付きのタイトル、URL、arXiv／DOI／PMID／S2 ID、「この論文を読んで」	1 回の呼び出し	論文カード
LIST（デフォルト）	「X に関する論文を探して」、「…という論文はありますか？」、「A と B の両方を満たす論文」	事前調査 + 最大 3 ラウンド（R2/R3/R4）	基準ごとの根拠を添えた候補リスト
ITERATIVE	「X の調査」、「Y に関する論文 30 本以上」、research-survey／research-ideation からの呼び出し	事前調査 + 最大 3 ラウンド（R2/R3/R4）	順位付きの表（レポート作成は research-survey に引き継ぎます）

判断に迷う場合は LIST をデフォルトにします。LIST のクエリには survey／review を追加しないでください。追加すると、ユーザーが求めている主要な研究論文の順位が下がります。

出力形式は呼び出し元に従います： 上記の「出力」列は、スキルの呼び出し元向けの構造化形式です。ユーザーから直接呼び出された場合は、デフォルトでナラティブ形式になります。ステップ 6「出力モード」を参照してください。

曖昧なクエリ（プロジェクトの愛称、コードネーム、検索結果がゼロ件の大文字始まりの単語 1 つ）の場合は、識別子を特定するため、まず scholar_search の完全一致検索とウェブ／GitHub 検索を実行してから、適切な分岐を選びます。

---

POINT 分岐（論文が特定されている場合）

入力	コマンド	出力
URL	python scripts/fetch_paper.py --url <URL>	論文カード + 読解メモ（L1/L2/L3 については references/reading-strategy.md を参照）
引用符付きのタイトル	python scripts/match_paper_by_title.py --title "<title>"（誤字がある場合は --fallback-search を追加）	論文カード
ID のみ（arXiv／DOI／S2／CorpusId）	python scripts/fetch_paper.py --paper-id <ID> --metadata-only	論文カード

論文カード：

📄 **<Title>**
Authors: <First Author> et al. | Year: <Y> | Venue: <V>
Citations: <N> | ID: <ArXiv:xxxx.xxxxx> | DOI: <...>
TLDR: <one sentence>

ここで終了します。依頼されていない限り、引用情報を使った検索の拡張には進まないでください。

---

LIST／ITERATIVE 分岐 — 6 ステップ

ステップ 1：意図を解析する

1 文で、調査対象（具体的な手法／概念）と制約（分野、タスク、時期、除外事項）を明示します。ルーターの分岐を確認します。ユーザーが方向性を示さず、単独の名詞（概念／モデル／アルゴリズム／ベンチマーク名）だけを提示した場合は、デフォルトの意図を「系譜をたどる」――基礎、発展、現状――とし、応用や一般的な survey にはしません。

ステップ 2：RUBRIC を作成する（think_tool 経由）

検索を始める前に、構造化ブロックを出力します。このブロックは複数のラウンドにわたって保持され、以降のすべてのステップで参照されます。

RUBRIC for "<user query verbatim>"
Branch: LIST | ITERATIVE
Criteria (2–4, atomic; mark each [core] or [secondary]):
  C1 [core]     <what the paper MUST do/be — one sentence>
  C2 [core]     <...>
  C3 [secondary] <...>
Named entities to preserve verbatim: [<ent1>, <ent2>, ...]
Angle tags (3–5 sub-topic axes): [<tag1>, <tag2>, <tag3>]
Recency signal: [none | recency cue — defined in Step 3]
Disqualifiers: [<auto-reject if abstract shows this>]

ルール：

• 評価基準は、重複のない、個別の条件（1 条件につき 1 項目）にします。それぞれに [core]（必須）または [secondary]（あると望ましい）の印を付けます。これは関連性の順位付けに使い、重み付けや計算は行いません。
• 固有名詞は、ユーザーのクエリに含まれる固有名詞／専門用語の基準語です。各語を Probe と R2 のいずれかのクエリに、少なくとも 1 回そのまま含めます。
• アングルタグは、サブトピックの軸（method、task、dataset、evaluation、domain など）です。同じラウンド内で、同一のタグを複数のクエリに使ってはいけません。
• 新しさのシグナルは、ユーザーのクエリに新しさを求める手がかりが含まれているかどうかです（ステップ 3 の新しさトリガーを参照）。これは --year-min とステップ 6 の新しさによるタイブレークに使います。
• 除外条件は、「具体的には X で、Y は対象外」という条件です。除外条件に抵触した場合は、関連性なしとします。

ITERATIVE の場合、評価基準は簡略化できます（例：covers topic + is canonical）。除外条件は空でもかまいません。

ステップ3: 検索 — プローブしてからマルチラウンド（広範 → 深化 → クローズ）

まずプローブしてユーザーのニーズを包括的に把握し、その後最大3つの論文ラウンド（R2 広範 / R3 深化 / R4 クローズ）を実行します。ラウンドごとに追加のラウンドが必要かどうかを判断します（ステップ5のゲート）— ラウンド数を固定してはいけません。R5は存在せず、上限は3つの論文ラウンドです。

プローブ（前提条件 — 3つのラウンドにはカウントされません、2つの並列クエリ）: ニーズの包括的な理解を確立し、固有表現／観点のギャップを引き上げます。

• Q-broad — トピックの標準的な言い回し（観点: general）
• Q-narrow — 特定のメカニズム／サブ質問／手法（観点: タグ付け）

python scripts/scholar_search.py --query "<Q-broad>"  --limit 15 --sort-by relevance --output /tmp/pool.jsonl --append
python scripts/scholar_search.py --query "<Q-narrow>" --limit 15 --sort-by relevance --output /tmp/pool.jsonl --append

--output --append はラウンド間で paperId によって自動重複排除されます（スクリプトに組み込み済み）。そのため、2つのクエリで見つかった論文は1回だけ書き込まれます。/tmp/pool.jsonl を読んで検査します（ステップ4のトリアージ）。プローブのタイトルとtldrから、以下を引き上げます:

• 繰り返し現れる固有表現（アルゴリズム／ベンチマーク／データセット／モデル名）、
• 観点のギャップ（ステップ2のタグで見られなかったもの）、
• 隣接コミュニティの語彙。

R2 — 広範（デフォルト — ステップ5の早期終了によってのみスキップされます。2〜3の並列クエリ）。 コア対象に関する広範な学術クエリ + プローブから引き上げた標準的な用語。主軸はユーザーのコア対象 + 標準的なマッピングです。プローブは高信頼度の補足のみを提供します。

R3 — 的を絞った深化（オプション、ステップ5のゲートがCONTINUEと言う場合、2〜3の並列クエリ）。 以下のギャップ→戦略マップによって駆動されます — ステップ4のトリアージが明らかにした特定のギャップを埋めます。

R4 — クローズ（オプション、2〜3の並列クエリ）。 R3の後に残る重要なギャップを埋めます: 欠けている代表的な研究、強力なベースライン、反例、またはカバーされていないサブ方向。

ギャップ→戦略マップ（R3/R4はステップ4のトリアージギャップによって駆動され、雰囲気ではありません）:

ステップ4のトリアージで表面化したギャップ	R3/R4の戦略
基礎的な研究が最近の論文に埋もれている	--year-max、元のメカニズム／初期の用語を検索
ユーザーがSOTA／フロンティアを求めている、またはR2が古いに偏っている	--year-min 直近2年
単一ソースの証拠が薄い	マルチソースの裏付けのために用語／チーム／ベンチマークを入れ替える
不完全なA対Bの比較	A、B、および上位トピックのクエリを別々に埋める（survey/reviewの用語なし）
矛盾する知見	検証クエリ、権威ある会議／高被引用／直接実験を優先

クエリごとのルール:

• 3〜6語が望ましい（英語の学術用語）; 3未満は過剰再現、6超はランキングを希釈します。
• 学術用語を使用する（mechanism、benchmark）; how it works という言い回しは避ける。
• survey / review / tutorial の用語を追加しないでください — これらは結果をレビュー論文に偏らせ、ユーザーが求める研究論文を押しのけます。ユーザーが明示的にサーベイ／レビューを求めた場合にのみ使用してください。
• 裸のエンティティ名; paper / pdf / arxiv / original は不可。
• 比較／複数プロパティは分割する; 2〜3のクエリに足りない場合は、上位トピックまたは代表的な手法で埋める。
• 時間の意図は --year-min/max パラメータに入れ、クエリに年を示す語を決して入れない。
• 禁止: "…"、(..)、OR、AND、|、site:、filetype:。
• 1つのラウンド内の2つのクエリは、コンテンツトークンの60%超を共有してはいけません（ストップワードを除く）。

最新性トリガー（クエリ層）。 ユーザークエリに最新性のシグナル（最新 / 近年 / 近期 / 近两年 / 前沿 / SOTA / latest / recent / state-of-the-art）が含まれる場合、R2以降で --year-min を直近2年に設定します — 現在のシステム年の前年の1月1日（例: システム日付2026-08 → --year-min 2025）。3〜4年に拡張しないでください。

S2_API_KEY がない場合: scholar_search を arxiv_monitor --keywords "<variant>" --match-mode flexible --days 3650 に置き換えます。

引用の拡張（反復的、または3つ以上のAll-core/Partialシードの後にLIST）:

python scripts/citation_traverse.py --paper-id <SEED> --direction co-citation --limit 15 --output /tmp/pool.jsonl --append
python scripts/citation_traverse.py --paper-id <SEED> --direction forward --limit 20 --min-citations 20 --year-min 2022 --output /tmp/pool.jsonl --append
python scripts/recommend.py --positive <SEED1>,<SEED2> --limit 15 --output /tmp/pool.jsonl --append

Step 4: トリアージ — All-core / Partial / Irrelevant

各ラウンドの後、新しい論文をそれぞれ分類し、RUBRIC に基準ごとのマスク（✓ / ~ / ✗）を付けます。数値スコアは付けません。このマスクによって、「A と B を満たす論文」のような連言クエリを正しく処理できます。すべての [core] 基準で ✓ の論文のみが All-core です。think_tool ブロックを出力します。

TRIAGE round=<n>  query="<q>"
  All-core   (k): <paperId> "<title-≤60>" Y=<year> · [C1✓ C2✓ (C3~)]   every [core] ✓
                 C1: "<≤80-char quote>"
                 C2: "<≤80-char quote>"
  Partial    (k): <paperId> "<title>" Y=<year> · [C1✓ C2✗]              some [core] ✓
                 C1: "<≤80-char quote>"
  Irrelevant (k): <paperId> "<title>"                                   no [core] ✓, or trips disqualifier — drop

Tier	Mask	Quotes
All-core	すべての [core] 基準が ✓（いずれの [core] 基準にも ✗ がない）	[core] 基準ごとに80文字以内の引用を1つ
Partial	[core] 基準のうち少なくとも1つが ✓ だが、一部が ✗ / ~。または [secondary] 基準のみを支持	✓ の [core] 基準ごとに引用を1つ
Irrelevant	[core] 基準に ✓ がない、または失格条件に該当	なし — 以降のラウンドから除外

✓ = 要旨／tldr が明確に支持。~ = 部分的／推論可能。✗ = 支持がない、または矛盾している。[secondary] 基準は Tier を決めませんが、マスク記号は付けます。

ルール：

1. ラウンド間で重複を除去します。まず paperId、次に正規化したタイトルで照合します。より強いマスクを残します。
2. 失格条件の確認は他のすべての一致より優先されます → Irrelevant。
3. 不足を再診断します。All-core と Partial 全体で ✓ が0件の [core] 基準、および All-core / Partial が0件のアングルタグを記録します。これらが次の絞り込み対象となり、Step 3 の不足→戦略マップに反映されます。
4. 捏造禁止： 要旨がない場合は ~ を付け、学習データから推測しません。

ここで収集した基準ごとの引用は、Step 6 の Rank-1 バーと構造化された LIST テンプレートがそのまま引用します。省略しないでください。

スニペットのアップグレード：境界線上の論文について、要旨に [core] 基準の記述がない場合は、実際の本文をまとめて取得します。

python scripts/snippet_search.py --query "<criterion phrase>" \
  --paper-ids "CorpusId:1,CorpusId:2,..." --limit 50

Step 5: 飽和ゲート

Probe と各ラウンドの後に、論文数ではなく、重要な不足が残っているかどうかに基づいて CONTINUE か STOP かを判断します。

Probe 後の早期終了（単一推薦／連言クエリのみ、K=1–2）：「……を満たす論文はありますか？」「論文を1つ推薦してください」「X の定番は何ですか？」といったクエリ、または「A and B を満たす論文」のような連言クエリでは、All-core の論文がすでにすべての [core] 基準を満たしている場合、追加ラウンドを実行せず STOP します。これにより、1件の Probe 結果で POINT 型のクエリを解決できる高速パス（約2クエリ）を維持します。これは、キーなしの S2 レート制限下で重要です。より広範な質問形式（「……に関する論文を探してください」K=3–5、または30件以上の論文を対象とする ITERATIVE）では、この早期終了を適用せず、以下の完全な STOP 条件を適用します。

次のすべてを満たしたら STOP：

• All-core の論文が1件以上ある — すべての [core] 基準が ✓ の論文が1件あること。これは、「A and B を満たす論文」のような連言クエリが、片方だけを満たす別々の論文2件を根拠に通過しないために必要です。AND
• すべてのアングルタグに All-core / Partial の論文が1件以上ある。AND
• 重要な主張が単一の情報源に依存していない。OR
• 以降のラウンドで新しい結果が出なくなる（検索結果なし／すべて重複）。

それ以外の場合は次のラウンド（R3 / R4）に CONTINUE し、不足→戦略マップに基づいて進めます。

• All-core の論文が0件 → まだ ✗ の [core] 基準を補います。
• アングルタグの All-core / Partial が0件 → そのアングルを掘り下げます。
• 重要な主張が単一の情報源に依存している → 複数の情報源で裏付けを取ります。

再分解（ルーブリックが誤っている場合）：R2 全体で All-core が0件、かつ Partial が0件の場合、最有力の Partial 候補を報告し、基準の緩和をユーザーに依頼します。

ラウンド上限： LIST と ITERATIVE は最大3ラウンド（R2/R3/R4）です。POINT は1回の取得のみ（複数ラウンドなし）です。上限に達しても飽和していない場合は、Step 6 に進み、網羅できなかった基準／アングルタグを報告します。

このゲートでは不足を機械的に判定します。「結果が良さそうだから」という理由でラウンドを省略しないでください。STOP 条件を満たした後に追加ラウンドを実行しないでください。単一の All-core で十分とするショートカットは、上記の K=1–2 の早期終了にのみ適用され、より広範なクエリには適用されません。

Step 6: ランク付けと出力

収集： すべてのラウンドから All-core と Partial の論文をすべて集めます（paperId で重複を除去）。Irrelevant は除外します。 関連度順にランキング — 数値スコアではなく、モデルが判断します。 収集した論文を、ユーザーの質問にどれだけ直接答えているかに基づいて並べます。All-core を Partial より上位にし、すべての [core] 基準を満たす論文は、一部の基準のみを満たす論文より上位にします。これは判断であり、数式ではありません — weighted_total を計算してはいけません。

新しさを考慮した同点時の判定。 RUBRIC が新しさのシグナルを示した場合（手順 3 で定義された手がかり）、同点または僅差の判定では、より新しい論文（year DESC）を優先します。これは関連度の判定後に適用します。新しさは関連度に次ぐものであり、関連度より優先されることはありません。

K（ソフト上限 — 候補の大量投入を防止）：

質問の形式	K
「ちょうど N 本の論文」	N
「…という論文はありますか？」／「論文を推薦してください」	1–2（トップ 1 を太字にする）
「…についての論文を探してください」	3–5
「…のサーベイ」／ITERATIVE	≤ 10（ソフト上限）+ ユーザーが明示的に求めている場合はサーベイ 1–2 本

K はソフトな目安であり、数式ではありません。幅広い「分野をサーベイ／分類してください」という質問で最も起こりやすい失敗は、蓄積された候補全体（多くの場合 30–50 本で、その大半は基準を満たしません）を出力に並べ、基準を満たす少数の論文を埋もれさせてしまうことです。関連度順に並べて上位 K 件に絞り、残りは**「参考になる論文（順位付けなし）」**のリストに移してください。件数を満たすために、関連性の低い論文でランキングを水増ししてはいけません。

1 位の品質基準。 1 本だけ推薦する質問（「…という論文はありますか？」「論文を推薦してください」「X の代表的な論文は何ですか」）では、太字のトップ 1 は、引用を根拠にすべての [core] 基準を明確に満たす All-core 論文でなければなりません。1 位はユーザーの印象を大きく左右するため、Partial 論文をトップ 1 にすると、自信満々に誤答しているように見えます。基準を満たす論文がない場合は、「完全に一致する論文は見つかりませんでした」と述べ、最も有力な候補を、満たしていない基準とともに正直に示してください。

ラウンド上限を迎えた後に All-core 論文が残らなかった場合は、「完全に一致する論文は見つかりませんでした」と報告し、最も有力な Partial 候補とそれぞれの不足点を列挙して終了してください。

出力形式（呼び出し元から推定）。 明示的なフラグではなく、リクエストが求める内容に応じて形式を選んでください。

• 構造化形式（以下の形式）— ランキングリスト／表、基準ごとの根拠、または後続スキルへの引き渡しなど、機械処理可能な出力が求められる場合に使用します。スキルからの呼び出し（research-survey、research-ideation、paper-writing、experiment-pipeline）では、これをデフォルトとします。
• ナラティブ形式（以下の「ナラティブ出力」を参照）— 直接ユーザーからの呼び出しでは、これをデフォルトとします。これは、構造化出力が求められていない自然言語の質問を指します。

構造化出力形式（スキルからの呼び出し）：

LIST（根拠付きの候補リスト）：

**Top matches:**
- **<paperId>** "<Title>" — <Authors> et al., <Year>, <Venue>, cited by <N>. <URL>
  - C1 [core]: "<quote>"
  - C2 [core]: "<quote>"
  - C3 [secondary]: "<quote>"

**May also be relevant:**
- <paperId> "<Title>" — <Authors> et al., <Year>, cited by <N>. <URL> (Partial: only C3)

ITERATIVE（ランキング表）：

| # | Title | Authors | Year | Venue | Cited by | Link |
|---|-------|---------|------|-------|----------|------|
| 1 | …    | … et al. | 2024 | NeurIPS | 1234 | <URL> |

POINT：Paper Card（上記）。

ナラティブ出力（直接ユーザーからの呼び出し）。

検索の経過ではなく、構造化された知見を提示してください。出力前に、プロセスに関する用語（Probe、R2/R3/R4、All-core/Partial、「ラウンド完了」）を取り除いてください。ただし、ユーザーが経過の説明を明示的に求めている場合は除きます。

• 情報優先であり、リスト優先ではない。 ユーザーが論文リストだけを求めている場合を除き、回答を「タイトル + 一行の貢献」に圧縮しないでください。ユーザーが必要とする認知構造（タイムライン / トピックのグループ化 / 比較 / メカニズムの分解 / 証拠の検証 / 読書パス）を構築し、その中に論文を証拠ノードとして配置します。
• 主たる形式を 1 つ + 補助的な形式を 2〜3 個。 主たる形式が回答の論理を担います（タイムライン、トピックのグループ化、比較、メカニズムの分解、証拠の等級付け、読書パス、ミニサーベイ）。補助的な形式を 2〜3 個（論文カード、表、証拠の等級付け、注釈付き文献目録、読者の利得）用いて可読性を高めます。すべての形式を積み重ねないでください。
• 意図 → 形式（簡略版）: 最新/SOTA → 状況判断 + 表。起源/基盤 → タイムライン + 原論文の分析。A 対 B → 結論 + 次元ごとの比較。メカニズム → メカニズムの分解 + 証拠の交互配置。ベンチマーク/データ → 検証 + 証拠表。全体像 → トピックのグループ化 + 読書パス。
• 引用ルール: 中核論文は初出時に Title (Venue Year) を示します（Zhang et al. のような著者名のみは不可）。引用するすべての論文には、返された [N] を付けます。表に [N] マーカーを含めてもかまいません。 回答の末尾で、引用したすべての論文を番号順に IEEE スタイルで列挙します（被引用数を付記）: [N] A. Author et al., "Title," Venue, Year, cited by N. [Online]. Available: URL。IEEE のルール: 著者名は Initial. Surname の形式（例: A. Vaswani）。複数の著者はカンマと and で結合。著者が 3 名以上 → A. Firstauthor et al.。タイトルは二重引用符で囲む。続いて Venue, Year。cited by N（ツールの citationCount）を付記。リンクのために [Online]. Available: URL で終える。ツールが本当に返さなかったフィールドのみ省略します（決して捏造しない）。著者と被引用数は、返された場合は必ず記載します。
• 長さ: 単一点で 600〜1200 語。比較/検索で 1200〜2500。全体像/タイムラインで 2000〜3500。簡潔さのために証拠構造を犠牲にしないでください。
• 引用必須またはゼロは依然として適用されます — 論文が主張を支えるために用いられる場合、その主張は依然として 80 文字以内の引用によって裏付けられます（レッドライン 5、ハルシネーション防止）。ナラティブでは、生の引用を示す代わりに [N] として描画するだけです。

出力前チェックリスト（必須）。 回答を出力する前に、各項目を確認してください。

• プールを収集し、各ラウンドのトリアージから、paperId で重複排除し、無関係なものを除外した。
• 関連性で順位付け（数値スコアではなく判断）— All-core を Partial より前に。
• 再新性のタイブレークを適用（再新性シグナルが存在する場合、関連性の後に year の降順）。
• 単一推薦クエリで Rank-1 が基準を満たす（引用を伴ってすべての [core] 基準を明確に満たす）— または「完全に一致する論文は見つかりませんでした」と報告した。
• 引用するすべての論文が、その用途の主張に対する ≥1 の裏付け引用を持つ（引用必須またはゼロ、レッドライン 5 — ハルシネーション防止）。
• 出力 ≤ K（ソフトキャップ）。余剰の関連論文は順位付きリストではなく「関連あり（順位外）」に置く。
• ナラティブモードのみ — 引用するすべての論文が、回答末尾の番号付き参考文献リストに IEEE スタイルで著者 + 被引用数付き（[N] A. Author et al., "Title," Venue, Year, cited by N. [Online]. Available: URL）で現れ、本文からはプロセス用語（Probe / R2 / All-core/Partial）を取り除く。

いずれかの項目が未チェックの場合、ステップ 6 に戻ってください — 出力しないでください。

---

ツール早見表

必要な内容	スクリプト	備考
キーワード検索	scholar_search.py	キーがない場合、または 429 の場合は S2 から arXiv にフォールバックします
タイトル → レコード	match_paper_by_title.py	S2 で完全一致検索します。誤字がある場合は --fallback-search を指定します
引用グラフ	citation_traverse.py	--direction forward/backward/co-citation；--min-citations；--year-min/max；--smart-sort；--enrich
類似論文	recommend.py	シードベースです。多様なシードには --per-seed を指定します
著者の論文	author_search.py	--sort-by year/citations
新着 arXiv 論文	arxiv_monitor.py	--categories cs.CL または --keywords "x,y" --match-mode flexible
トレンド	trending.py	引用速度
本文の抜粋	snippet_search.py	--paper-ids c1,c2,c3 --limit 50（N 回ではなく 1 回の呼び出し）
全文を取得	fetch_paper.py	$PAPER_NAV_PAPERS_DIR/<id>.md に保存します。標準出力は 2000 文字に切り詰められます
コードリポジトリ（既知の論文）	find_code.py --arxiv-id <ID>	公式リポジトリを検索します
コードリポジトリ（未発表）	github_search.py	arXiv ID がない場合に使用します
HF リーダーボード / SOTA	sota.py	ダウンロード数順
HF データセット	dataset_search.py	タスクの説明ではなく、短いクエリ名（imdb、sst2）を指定します
飽和判定ゲート（任意）	saturation.py	各ラウンドの取得数を記録する JSONL ログです。estimate は STOP/CONTINUE を返します

すべての検索スクリプト：--limit N、--json、--output FILE、--append を指定できます。S2 / arXiv / DOI / CorpusId の各 ID を受け付けます。--output --append はラウンド間で paperId による重複を自動的に除去するため（バッチ内およびファイル間）、候補プールを整理された状態に保てます。

---

レート制限

API	キーなし	キーあり
Semantic Scholar	約 3 秒あたり 1 リクエスト、並列処理不可	1 分あたり 100 リクエスト、並列処理可
arXiv	3 秒あたり 1 リクエスト（配慮による制限）	該当なし
GitHub	1 分あたり 10 リクエスト	1 時間あたり 5,000 リクエスト
HuggingFace	300 秒あたり 500 リクエスト	HF_TOKEN があれば上限が引き上げられます

グローバル S2 ペーサーとサーキットブレーカー（5 回失敗すると 60 秒間クールダウン）。再試行間隔：3 秒 / 6 秒 / 12 秒 / 24 秒 / 48 秒。

S2_API_KEY がない場合：scholar_search（arXiv フォールバックあり）と arxiv_monitor を使用します。citation_traverse / recommend / snippet_search は S2 専用のためスキップし、再試行しないでください。

---

参考資料

ファイル	読むタイミング
references/env-vars.md	環境変数を設定するとき
references/search-principles.md	クエリごとのルール、ギャップの診断、レート制限からの復旧
references/iterative-collection.md	反復的なコーパス収集（論文 30 件以上）：フェーズのマッピング、引用の拡張、代替手段
references/disambiguation.md	クエリがプロジェクトの通称 / コードネームの場合
references/reading-strategy.md	L1 / L2 / L3 の読解フレームワーク
references/api-reference.md	S2 / arXiv / Jina / HF / GitHub のエンドポイント詳細
references/arxiv-categories.md	arXiv のカテゴリコード
references/output-formats.md	Baseline / Disambiguation / Reading-Notes / Citation-Graph のテンプレート

参考資料はそれぞれ単独で完結しています。資料間をたどらず、ここに戻って次の案内を確認してください。

---

次の引き継ぎ先

目的	スキル
サーベイレポート	research-survey
アイデア生成	research-ideation
関連研究のセクション	paper-writing
ベースライン + 実験	experiment-pipeline