paper-write

Paper Write：セクションごとの LaTeX 生成

各レビュアースロットの前に、選択可能なレビュアーに従ってください： 呼び出しの解決 → .aris/reviewer.json → Claude Code のデフォルト（Codex MCP） を、正規のヘルパーリゾルバー経由で reviewer_route.py を使って実行し、この スロットのティア、新規コンテキスト、ソース／画像入力、決定論的ゲートを維持します。 以下の Codex の例／固定設定は backend=codex の場合にのみ適用されます。それ以外のルートでは、 それぞれの初回呼び出し／返信の契約を使用します。ルートと実際に返された ID を保存してください。 利用できない選択肢は REVIEW_UNAVAILABLE とします。実際の ファミリー／完了状況／スコープに基づいて採否を分類します。呼び出し元のレビュアー／モデル／effort のオーバーライドを、 レビュアーを含む子処理に引き継いでください。生成ワーカーに変更はありません。

次の内容に基づいて LaTeX 論文を作成します：$ARGUMENTS

定数

• REVIEWER_MODEL = gpt-6-astra — セクションレビューに Codex MCP 経由で使用するモデルです。backend=codex の場合は、OpenAI のモデルを使用してください。
• TARGET_VENUE = ICLR — デフォルトの投稿先です。対応先：ICLR、NeurIPS、ICML、CVPR（ICCV/ECCV も対応）、ACL（EMNLP/NAACL も対応）、AAAI、ACM（ACM MM、SIGIR、KDD、CHI など）、IEEE_JOURNAL（IEEE Transactions / Letters。例：T-PAMI、JSAC、TWC、TCOM、TSP、TIP）、IEEE_CONF（IEEE の会議。例：ICC、GLOBECOM、INFOCOM、ICASSP）。スタイルファイルと書式を決定します。
• ANONYMOUS = true — true の場合、著者欄を匿名にします。カメラレディ版では false に設定してください。注：ほとんどの IEEE の投稿先では匿名投稿を採用していません。IEEE の場合は false に設定してください。
• MAX_PAGES = 9 — 本文のページ数上限です。ML 系の会議では、1 ページ目から結論セクションの末尾までを数え、参考文献と付録は含めません。**IEEE の投稿先では、参考文献もページ数上限に含まれます。**一般的な上限：IEEE ジャーナルは厳密な上限なし（ただし Transactions は通常 12～14 ページ、Letters は 4～5 ページ）、IEEE の会議は参考文献を含めて 5～8 ページです。
• DBLP_BIBTEX = true — LLM が生成したエントリではなく、DBLP/CrossRef から実際の BibTeX を取得します。引用の幻覚を排除します。インストールは不要です。従来の動作（LLM による検索と [VERIFY] マーカー）を使用する場合は false に設定してください。

入力

1. PAPER_PLAN.md — 主張と根拠のマトリクス、セクション計画、図の計画を含むアウトライン（/paper-plan で作成）
2. NARRATIVE_REPORT.md — 研究のナラティブ（内容の主要な情報源）
3. 生成済みの図 — figures/ 内の PDF/PNG ファイル（/paper-figure で作成）
4. LaTeX インクルード — figures/latex_includes.tex（/paper-figure で作成）
5. 参考文献リスト — 既存の .bib ファイル、または新規作成するファイル

PAPER_PLAN.md が存在しない場合は、まず /paper-plan を実行するか、簡単なアウトラインを提示するようユーザーに依頼してください。

Orchestra に基づく執筆オーバーレイ

既存の insleep ワークフロー、ファイル構成、デフォルト設定を維持します。以下の共有リファレンスは、執筆品質の向上に役立つ場合にのみ使用してください。

• Abstract、Introduction、Related Work の執筆前、または文章が一般論に偏っていると感じた場合は、../shared-references/writing-principles.md を読んでください。
• 最終稿の作成と投稿準備状況の確認時に、../shared-references/venue-checklists.md を読んでください。
• 組み込みの DBLP/CrossRef ワークフローでは不十分な場合にのみ、../shared-references/citation-discipline.md を読んでください。

これらのリファレンスは補助資料であり、追加のワークフロー段階ではありません。

オプション：スタイル参照（— style-ref: <source>、オプトイン）

参照論文に合わせて、構成上のスタイル（セクションの順序、定理の密度、文のリズム、図の密度、参考文献のスタイル）をユーザーが指定できます。デフォルトではオフです。ユーザーが — style-ref を渡さない場合、これまでと何も変えません。

$ARGUMENTS に — style-ref: <source> が含まれる場合に限り、執筆を始める前に、まずヘルパーを実行します。

# Resolve $STYLE_HELPER via the canonical strict-safe chain (see
# shared-references/integration-contract.md §2). Policy A — gate:
# unresolved helper means --style-ref cannot be satisfied, so abort.
cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" || exit 1
if [ -z "${ARIS_REPO:-}" ] && [ -f .aris/installed-skills.txt ]; then
    ARIS_REPO=$(awk -F'\t' '$1=="repo_root"{print $2; exit}' .aris/installed-skills.txt 2>/dev/null) || true
fi
if [ -z "${ARIS_REPO:-}" ] && [ -f "$HOME/.aris/repo" ]; then
    ARIS_REPO=$(cat "$HOME/.aris/repo" 2>/dev/null) || true
fi
STYLE_HELPER=".aris/tools/extract_paper_style.py"
[ -f "$STYLE_HELPER" ] || STYLE_HELPER="tools/extract_paper_style.py"
[ -f "$STYLE_HELPER" ] || { [ -n "${ARIS_REPO:-}" ] && STYLE_HELPER="$ARIS_REPO/tools/extract_paper_style.py"; }
[ -f "$STYLE_HELPER" ] || {
  echo "ERROR: extract_paper_style.py not resolved at .aris/tools/, tools/, \$ARIS_REPO/tools/, or via ~/.aris/repo." >&2
  echo "       Fix: rerun bash tools/install_aris.sh or smart_update.sh (refreshes ~/.aris/repo), export ARIS_REPO, or copy the helper to tools/." >&2
  echo "       --style-ref cannot be satisfied; aborting." >&2
  exit 1
}
STYLE_STATUS=0
CACHE=$(python3 "$STYLE_HELPER" --source "<source>") || STYLE_STATUS=$?
case "$STYLE_STATUS" in
  0) ;;                                       # use $CACHE/style_profile.md as structural guidance
  2) echo "warning: style-ref skipped (missing optional dep)" >&2 ;;
  3) echo "error: --style-ref source failed; aborting draft" >&2 ; exit 1 ;;
  *) echo "error: helper failed unexpectedly; aborting draft" >&2 ; exit 1 ;;
esac

指定できるソース：ローカルの TeX ディレクトリ／ファイル、ローカルの PDF、arXiv ID（2501.12345 または arxiv:2501.12345）、http(s) URL。Overleaf の URL とプロジェクト ID は受け付けません。まず /overleaf-sync setup <id> でクローンし、ローカルのクローンパスを指定してください。

厳格なルール（契約の全文は tools/extract_paper_style.py の docstring を参照）：

• style_profile.md は構成上の指針としてのみ使用します。セクション数、セクションの順序の傾向、定理環境の密度、キャプションの長さの分布、文のリズム、数式表示の比率、引用スタイルを合わせてください。
• キャッシュを通じて参照できる内容から、文章、主張、例、用語を決してコピーしないでください。プロファイルは意図的に集約されています。内容が必要な場合は、ユーザー自身のアウトラインを使用してください。
• — style-ref（またはキャッシュの内容）を査読者／監査者のサブエージェントに決して渡さないでください。モデル間レビューの独立性（../shared-references/reviewer-independence.md）を保つため、査読者が参照できるのは成果物とユーザーのプロンプトのみであり、執筆者のスタイルに関する文脈を見せてはいけません。

`` マーカー（GAP_REPORT.md がある場合）

/paper-plan が — style-ref: を指定して実行されている場合、PAPER_PLAN.md とともに GAP_REPORT.md が出力されています。このファイルには、参照論文が示唆しているものの、ユーザーに埋めるための根拠がない構成上の枠（アブレーション表、スケーリング実験、失敗事例の分析など）が記載されています。

GAP_REPORT.md があり、セクションの枠が status: missing と分類されている場合：

1. その枠を埋めるために、数値結果、図への参照、定性的な主張を捏造しないでください。

2. 欠けている内容が入る正確な位置に、HTML コメント形式のプレースホルダーを出力します。

3. スロット ID と1行の説明は、GAP_REPORT.md からそのまま取得します。スロット IDを決して創作しないでください。レポートより断定的になるよう説明を言い換えてはいけません。

4. このマーカーは HTML コメントなので、レンダリングされた PDF では表示されませんが、人によるトリアージや /experiment-bridge でのフォローアップのために、grep -r "DATA_NEEDED" sec/ で検索できます。

5. status: partial の場合、ユーザーが提供した内容を記述し、同じ段落の不足箇所に `` を出力します（セクションを分割しないでください）。

「プレースホルダー禁止」ルールの例外。 デフォルトの /paper-write の方針（「補足資料を参照」や「TBD」などのプレースホルダーを使わない）は、GAP_REPORT に記載された不足スロットを除くすべてに適用されます。根拠の不足を主張の信頼性を損なわずに明示するには、このマーカーが適切な方法です。

元のアイデア：@zhangpelf、#217。

テンプレート

学会別の設定

このスキルには templates/ に学会テンプレートが含まれています。TARGET_VENUE に基づいて選択してください。

ICLR：

\documentclass{article}
\usepackage{iclr2026_conference,times}
% \iclrfinalcopy  % Uncomment for camera-ready

NeurIPS：

\documentclass{article}
\usepackage[preprint]{neurips_2025}
% \usepackage[final]{neurips_2025}  % Camera-ready

ICML：

\documentclass[accepted]{icml2025}
% Use [accepted] for camera-ready

IEEE ジャーナル（Transactions、Letters）：

\documentclass[journal]{IEEEtran}
\usepackage{cite}  % IEEE uses \cite{}, NOT natbib
% Author block uses \author{Name~\IEEEmembership{Member,~IEEE}}

IEEE カンファレンス（ICC、GLOBECOM、INFOCOM、ICASSP など）：

\documentclass[conference]{IEEEtran}
\usepackage{cite}  % IEEE uses \cite{}, NOT natbib
% Author block uses \IEEEauthorblockN / \IEEEauthorblockA

プロジェクト構成

次のファイル構成を生成します。

paper/
├── main.tex                    # master file (includes sections)
├── iclr2026_conference.sty     # or neurips_2025.sty / icml2025.sty / IEEEtran.cls + IEEEtran.bst
├── math_commands.tex           # shared math macros
├── references.bib              # bibliography (filtered — only cited entries)
├── sections/
│   ├── 0_abstract.tex
│   ├── 1_introduction.tex
│   ├── 2_related_work.tex
│   ├── 3_method.tex            # or preliminaries, setup, etc.
│   ├── 4_experiments.tex
│   ├── 5_conclusion.tex
│   └── A_appendix.tex          # proof details, extra experiments
└── figures/                    # symlink or copy from project figures/

セクションファイルは柔軟に変更できます：論文の計画に6～8個のセクションがある場合は、それに対応するファイルを作成してください（例：4_theory.tex、5_experiments.tex、6_analysis.tex、7_conclusion.tex）。

ワークフロー

ステップ 0：バックアップとクリーンアップ

すでに paper/ が存在する場合は、上書きする前に paper-backup-{timestamp}/ にバックアップしてください。既存の作業を黙って破棄してはいけません。

重要：古いファイルを削除してください。 セクション構成を変更する場合（例：5セクションから7セクションへ）、main.tex から参照されなくなったセクションファイルを削除してください。古いファイル（例：結論が 7_conclusion.tex に移動した後も残る旧 5_conclusion.tex）は混乱を招き、容量を無駄にします。

ステップ 1：プロジェクトを初期化する

1. paper/ ディレクトリを作成します
2. templates/ から投稿先のテンプレートをコピーします — テンプレートには以下がすでに含まれています。
   • 標準パッケージ一式（amsmath、hyperref、cleveref、booktabs など）
   • \crefname{assumption} の修正を含む定理環境
   • 著者名を匿名にするブロック
3. 論文固有の表記法を含む math_commands.tex を生成します
4. PAPER_PLAN の構成に合わせてセクションファイルを作成します

著者名ブロック（匿名モード）：

\author{Anonymous Authors}

ステップ 2：math_commands.tex を生成する

論文の表記法に基づいて、共有の数式マクロを作成します。

% math_commands.tex — shared notation
\newcommand{\R}{\mathbb{R}}
\newcommand{\E}{\mathbb{E}}
\DeclareMathOperator*{\argmin}{arg\,min}
\DeclareMathOperator*{\argmax}{arg\,max}
% Add paper-specific notation here

ステップ 3：各セクションを執筆する

セクションを順番に処理します。各セクションについて、以下を行います。

1. 計画を読む — このセクションに含める主張、根拠、引用を確認します
2. NARRATIVE_REPORT.md を読む — 関連する内容、調査結果、定量的な結果を抽出します
3. 内容を下書きする — 完全な LaTeX を記述します（捏造したプレースホルダーは使用しません）。例外： GAP_REPORT.md が存在し、そのセクションに status: missing のスロットがある場合は、データを捏造する代わりに、その箇所に `` を出力します — 上記の DATA_NEEDED マーカーのサブセクションを参照してください。
4. 図表を挿入する — figures/latex_includes.tex のスニペットを使用します
5. 引用を追加する — ML カンファレンス（ICLR／NeurIPS／ICML／CVPR／ACL／AAAI）では、\citep{}／\citet{}（natbib）を使用します。IEEE の投稿先では、 \cite{}（cite パッケージによる数値スタイル）を使用します。natbib と cite のコマンドを混在させないでください。

前付けを下書きする前に、PAPER_PLAN.md に記載された一文の貢献説明を読み直してください。アブストラクトとイントロダクションでは、読者が手法の詳細に進む前に、論文の要点が明確に伝わるようにしてください。

セクションごとのガイドライン

§0 アブストラクト：

• ../shared-references/writing-principles.md にある5部構成（何をしたか、なぜ難しいか、どのように取り組んだか、根拠、最も重要な結果）を使用します
• 単独で内容が理解できるものにします（論文を読まなくても理解できること）
• 分野全体の一般的な背景ではなく、論文固有の貢献から始めます
• 具体的な定量結果を1つ含めます
• 150～250語とします（投稿先の上限を確認してください）
• 引用や未定義の略語は使用しません
• \begin{abstract} は使用しません。これは main.tex に記述されています

§1 はじめに：

• 読者を引きつける導入（問題の動機を示す1～2文）から始めます
• 課題を明確に示します（「しかし、……」）
• 読者が詳細に迷い込む前に、アプローチの概要を簡潔に説明します
• 具体的で反証可能な貢献を2～4点、番号付きリストまたは箇条書きで示します
• 最も重要な結果を実験の節まで後回しにせず、早い段階で提示します
• 最後に、論文の構成を簡潔に案内します（「本論文の残りの構成は次のとおりです……」）
• 紙幅に余裕があれば、主な結果を示す図を含めます
• 目安：1～1.5ページ
• 遅くとも2～3ページ目までに手法の説明を始めます

§2 関連研究：

• 最低でも1ページ分（内容のある段落を3～4つ）を確保します。関連研究の節が短すぎることは、査読者からよく指摘されます。
• \paragraph{Category Name.} を使い、カテゴリごとに整理します
• 手法、前提の種類、または研究上の問いに基づいて整理します。論文ごとの短い要約を並べないでください
• 各カテゴリについて、その研究の流れを要約する段落を1つ書き、この論文の位置づけを示す文を1～2文加えます
• 論文をただ列挙するのではなく、統合して比較します
• 各段落の最後に、この論文との関連性や相違点を示します

§3 手法／予備知識／設定：

• 記法を早い段階で定義します（math_commands.tex を参照）
• 形式的な記述には \begin{definition}、\begin{theorem} 環境を使用します
• 理論論文では、主要な結果の証明スケッチを本文に含め、完全な証明は付録に記載します
• 理論論文では、先行研究の境界と本論文の境界を比較する表を含めます
• 該当する場合は、アルゴリズムの擬似コードを含めます（algorithm2e または algorithmic）
• 目安：1.5～2ページ

§4 実験：

• 実験設定（データセット、ベースライン、評価指標、実装の詳細）から始めます
• 主な結果を示す表または図を最初に配置します
• その後にアブレーションと分析を示します
• はじめにで述べた主張すべてに、ここで裏付けとなる証拠を示します
• 主な実験ごとに、どの主張を裏付けるのか、読者が何に注目すべきかを明示します
• 目安：2.5～3ページ

§5 結論：

• 貢献を要約します（はじめにの文章をそのままコピーせず、言い換えてください）
• 限界（重要かつ具体的なものを2～4点。データセットの規模、計算環境、前提条件Xなど。実在する限界のみとし、数を満たすために作り上げないでください。一般的な留保事項を記載するのはこの節だけです）
• 今後の研究の方向性を具体的に1～2点示します
• 投稿先が求める場合は、倫理に関する声明と再現性に関する声明を含めます
• 目安：0.5ページ

付録：

• 証明の詳細（本文に記載した定理の完全な証明）
• 追加の実験とアブレーション
• 実装の詳細、ハイパーパラメーター表
• 追加の可視化

ステップ 3.5：理論論文の整合性チェック（理論論文のみ）

すべてのセクションのドラフトを作成した後、参考文献を作成する前にこのチェックを実行します。

トリガーのヒューリスティック： PAPER_PLAN.md で論文が理論／解析として分類されている場合、またはドラフト済みのセクションに形式的な結果環境（\begin{theorem}、\begin{lemma}、\begin{proposition}、\begin{corollary}）が5つ以上含まれている場合、その論文を理論中心として扱います。

証明ソースの検索： ワークスペースを検索し、標準的な証明の完全版を示す名前または内容（proof、appendix、full、complete、supplement、supplementary）を持つ、独立した完全な証明ソースファイルがあるか確認します。そのようなファイルがある場合は、ユーザーに正確に次のように尋ねます。

Inline full proofs from {file}? [Y/n]

デフォルトは Y です。

ユーザーが了承した場合：

• 定理／補題の記述全体と証明ブロックを、付録のソース（A_appendix.tex または計画で指定された付録ファイル）に取り込みます
• 本文の定理の記述を正式な公開版として扱います。同じチェックで本文の記述を改訂する場合を除き、付録の記述は本文と一致させます
• 「補足の証明文書を参照」や「簡潔にするため証明を省略」といったプレースホルダーを残さないでください
• 定理ラベル、数式ラベル、証明の構造を厳密に維持します
• 本文の証明スケッチは短く保ちますが、完全な証明ソースがある場合、付録を証明スケッチだけのプレースホルダーにしてはいけません

独立した完全な証明ソースがない場合：

• 実際に証明スケッチとして書かれている場合に限り、証明スケッチを使用します。プレースホルダーは使用しません
• 外部の証明文書への参照を捏造しないでください

再掲の監査：

• 付録に再掲されているすべての定理／補題／命題の記述を、本文の記述と比較します
• 証明本文の差分は確認せず、記述、仮定、場合分け、量化子、定義域、記法、変数名、定義済みの対象に関する用語のみを監査します
• stationary と terminal の違い、仮定名の変更、場合分けの欠落は、明示的に記録されていない限り不一致として扱います
• 付録で異なる表現が必要な場合は、概念名を黙って変更せず、明示的な記法の対応付けを追加します
• ステップ4の前にすべての不一致を解消します

経験に基づく動機： 実際の理論論文の作業では、付録に「補足の証明文書を参照」というプレースホルダーが生成されるのがデフォルトの動作でした。著者は、独立した証明ファイル（例：proof_full.tex）から何百行もの完全な証明を手作業で取り込む必要がありました。このチェックを行わないと、理論論文の付録がスケッチだけになり、理論分野の会議で不備と見なされる可能性があります。

ステップ 4：参考文献の作成

重要：論文内で実際に引用されている項目のみを含めてください。

1. ドラフト済みのセクションにあるすべての引用を確認します（ML 会議では \citep{}／\citet{}、IEEE の会場では \cite{}）
2. 引用キーの一覧を作成します
3. 各引用キーについて：
   • プロジェクト／ナラティブ文書内の既存の .bib ファイルを確認します
   • 見つからず、DBLP_BIBTEX = true の場合は、以下の検証済み取得手順を使用します
   • 見つからず、DBLP_BIBTEX = false の場合は、arXiv／Scholar を検索して正しい BibTeX を探します
   • BibTeX エントリを決して捏造しないでください — 不明な項目には [VERIFY] コメントを付けます
4. 引用された項目のみを含む references.bib を作成します（不要な項目を含めないでください）

検証済み BibTeX の取得（DBLP_BIBTEX = true の場合）

3 段階のフォールバックチェーンです。インストール不要、認証不要で、すべて実際の BibTeX を取得できます。

ステップ A：DBLP（最も高品質 — 会議名、ページ、編集者をすべて含む）

# 1. Search by title + first author
curl -s "https://dblp.org/search/publ/api?q=TITLE+AUTHOR&format=json&h=3"
# 2. Extract DBLP key from result (e.g., conf/nips/VaswaniSPUJGKP17)
# 3. Fetch real BibTeX
curl -s "https://dblp.org/rec/{key}.bib"

ステップ B：CrossRef DOI（フォールバック — arXiv のプレプリントにも対応）

# If paper has a DOI or arXiv ID (arXiv DOI = 10.48550/arXiv.{id})
curl -sLH "Accept: application/x-bibtex" "https://doi.org/{doi}"

ステップ C：[VERIFY] を付ける（最終手段） DBLP と CrossRef の両方から何も返されない場合は、エントリに % [VERIFY] コメントを付けます。捏造してはいけません。

重要な理由： LLM が生成した BibTeX では、会議名、ページ番号、さらには共著者まで頻繁に幻覚されます。DBLP と CrossRef は、出版社によって検証されたメタデータを返します。上流のスキル（/research-lit、/novelty-check）は、LLM の記憶に基づいて論文に言及することがあります。この取得チェーンは、幻覚された引用が最終的な .bib に入り込むのを防ぐゲートです。

DBLP/CrossRef のフローでは不十分な場合、プレースホルダーを追加する前に ../shared-references/citation-discipline.md を読み込み、より厳格なフォールバックルールを確認してください。

Bib の自動クリーニング — 引用されたエントリだけを抽出するには、次の Python パターンを使用します。

import re
# 1. Grep all \citep{...}, \citet{...}, and \cite{...} from all .tex files
# 2. Extract unique keys (handle multi-cite like \citep{a,b,c} or \cite{a,b,c})
# 3. Parse the full .bib file, keep only entries whose key is in the cited set
# 4. Write the filtered bib

これにより、Bib の肥大化を防げます（テストでは 948 行から 215 行に削減）。

Bib の衛生状態を強制検証 — フィルタリング済みの references.bib を書き込んだ直後に実行します。

python3 - <<'PY'
import io, json, re, sys, urllib.parse, urllib.request
from pathlib import Path

try:
    import bibtexparser
except ImportError:
    sys.exit("Missing dependency: pip install bibtexparser")

ROOT = Path("paper")
tex_paths = [ROOT / "main.tex", *sorted((ROOT / "sections").glob("*.tex"))]
tex = "\n".join(p.read_text(errors="ignore") for p in tex_paths if p.exists())

cited = set()
for m in re.finditer(r'\\cite[a-zA-Z]*\{([^}]*)\}', tex):
    cited.update(k.strip() for k in m.group(1).split(',') if k.strip())

with (ROOT / "references.bib").open() as fh:
    bib = bibtexparser.load(fh)

entries = {e["ID"]: e for e in bib.entries}
dead = sorted(set(entries) - cited)
if dead:
    print("DEAD ENTRIES:")
    for key in dead:
        print("  ", key)

def norm(s):
    return re.sub(r'[^a-z0-9]+', ' ', (s or '').lower()).strip()

def dblp_hits(title):
    q = urllib.parse.quote(title)
    url = f"https://dblp.org/search/publ/api?q={q}&format=json&h=3"
    with urllib.request.urlopen(url, timeout=20) as r:
        data = json.load(r)
    return [h.get("info", {}) for h in data.get("result", {}).get("hits", {}).get("hit", [])]

def crossref_entry(doi):
    req = urllib.request.Request(f"https://doi.org/{doi}", headers={"Accept": "application/x-bibtex"})
    with urllib.request.urlopen(req, timeout=20) as r:
        parsed = bibtexparser.loads(r.read().decode("utf-8", "ignore"))
    return parsed.entries[0] if parsed.entries else {}

for key in sorted(cited & set(entries)):
    e = entries[key]
    title = e.get("title", "").strip("{}")
    hits = dblp_hits(title) if title else []
    hit = hits[0] if hits else None
    source = "DBLP"
    if hit is None and e.get("doi"):
        try:
            hit = crossref_entry(e["doi"])
            source = "CrossRef"
        except Exception:
            hit = None
    if hit is None:
        print(f"VERIFY {key}: no DBLP/CrossRef hit")
        continue

    issues = []
    year_a = str(e.get("year", "")).strip()
    year_b = str(hit.get("year", "")).strip()
    if year_a and year_b and year_a != year_b:
        issues.append(f"year {year_a} != {year_b}")

    venue_a = e.get("journal") or e.get("booktitle") or ""
    venue_b = hit.get("journal") or hit.get("booktitle") or hit.get("venue") or ""
    if norm(venue_a) and norm(venue_b) and norm(venue_a) != norm(venue_b):
        issues.append(f"venue {venue_a} != {venue_b}")

    authors_a = [norm(a) for a in re.split(r'\s+and\s+', e.get("author", "")) if a.strip()]
    authors_b = [norm(a) for a in re.split(r'\s+and\s+', hit.get("author", "")) if a.strip()]
    if authors_a and authors_b and authors_a[:2] != authors_b[:2]:
        issues.append("author list differs")

    if issues:
        print(f"MISMATCH {key} ({source}): " + "; ".join(issues))
PY

DEAD ENTRIES が出力された場合は、続行する前に該当するキーを references.bib から削除してください。 VERIFY または MISMATCH が出力された場合は、メタデータを捏造してはいけません。

• DBLP で明確な一致が見つかった場合は、DBLP を優先します。
• DBLP で見つからず、DOI が利用できる場合は、CrossRef にフォールバックします。
• 両者の情報が一致しない場合、または引き続き検証できない場合は、% [VERIFY] マーカーを付けた状態でのみエントリを残します。
• 引用されていないエントリは削除してください。未使用の書誌情報として残して肥大化させてはいけません。

引用の到達可能性ルール： キーが paper/main.tex または paper/sections/*.tex のいずれかにある \cite...{} コマンドに出現しない場合、そのエントリは未使用です。

実証的な背景： 実際の投稿作業では、複数回の改善を経ても未使用の Bib エントリがいくつか references.bib に残っており、少なくとも 1 件でキーと年が一致していませんでした。既存の自動クリーニングでは、どちらも検出されませんでした。

引用検証ルール（claude-scholar + Imbad0202 より）：

1. すべての BibTeX エントリに、author、title、year、venue/journal が含まれている必要があります。
2. 出版済みの場合は、arXiv のプレプリントより出版版を優先します。
3. 一貫したキー形式を使用します：{firstauthor}{year}{keyword}（例：ho2020denoising）
4. すべてのエントリについて、年と会議名を再確認します。
5. 重複したエントリ（キーが異なる同一論文）は削除します。

Step 5: 科学的な文章の品質チェック（5回の監査パス）

すべてのセクションをドラフトした後、5回の監査パスを順番に実施します。Sainani の「Writing in the Sciences」の手法に基づき、すべての単語に存在する理由が必要です。

パス 1：冗長表現の除去 — 文を整理し、最もすっきりした要素だけにします。

冗長な表現	置き換え
Due to the fact that	Because
In order to	To
A number of	Several
It is worth noting that	（削除 — 要点をそのまま述べる）
It is important to note that	（削除）
At the present time	Now
On the basis of	Based on
In light of the fact that	Because
Have an effect on	Affect
Give rise to	Cause

冗長な表現も削除します。「completely eliminate」→「eliminate」、「future plans」→「plans」、「unexpected surprise」→「surprise」。

AI らしい表現も削除します：delve、pivotal、landscape、tapestry、underscore、noteworthy、intriguingly。

パス 2：能動態と動詞の活力 — 誰が何をしたのかを明確にします。

• 受動態を見つけます：「to-be」動詞＋過去分詞（「was observed」「were analyzed」）
• 能動態に変換します：動作主を見つけ、主語－動詞－目的語の構文に組み直します
• 名詞化された弱い動詞を、生き生きとした動詞に戻します：
  • 「We made an investigation」→「We investigated」
  • 「Failure of the system occurs」→「The system fails」
  • 「Provides a description of」→「Describes」

受動態が許容されるのは、確立された事実、動作主が重要でない手法の説明、または投稿先のスタイルで求められる場合です。

パス 3：文の構成 — 構造と流れを整えます。段落の形に変化をつけます。 すべての段落が「問題 → 方法 → 利点 → 要約」の順に展開すると、型にはまり、 読者を飽きさせます。その型を崩しましょう。

• 40 語を超える文に印を付け、分割します
• 主語と動詞が近くにあることを確認します（その間に長い挿入句を置かない）
• 既知の文脈を先に置き、新しい情報を後に置きます
• 文の中で最も重要な点を終わり近くに置きます
• 各段落の役割を一つに絞ります
• 連続する文を「This」や「We」で始めないようにします
• 段落間のつながりを確認します。各段落の最初の文は、前の段落につながる必要があります

パス 4：キーワードの一貫性 — バナナルール。

「バナナ」を繰り返しを避けるために「細長い黄色の果物」と呼んではいけません。 Methods で「肥満群」と呼んだ場合、Results で「体重の重い群」に切り替えてはいけません。専門用語の同義語を使うと、新しいカテゴリが導入されたのかどうか、読者に考えさせることになります。

• Method セクションからすべての重要な用語（群名、変数名、手法名、略語）を抽出します
• Results、Discussion、表、図のキャプションに、まったく同じ用語が使われているか確認します
• 定義済みの用語を別の同義語に置き換えている箇所すべてに印を付けます
• 略語は必要最小限にします。便宜のためだけに作られた非標準的な略語に印を付け、すべての略語が初出時に定義されていることを確認します

パス 5：数値と引用の整合性

• Abstract のサンプルサイズ（N）は Table 1 と一致していますか？
• Results の割合は、表の生データと一致していますか？
• 有効数字は一貫しており、適切ですか？
• Figure の図示内容は Table の値と一致していますか？
• 二次資料（レビュー、教科書）経由でのみ引用されている統計に印を付け、一次資料の確認を推奨します

Step 6: REVIEWER_MODEL による相互レビュー

完全なドラフトを GPT-6-Astra xhigh に送信します。

最初にこのレビュアー枠を解決してください。以下は backend=codex の例です。

mcp__codex__codex:
  model: gpt-6-astra
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    Review this [VENUE] paper draft (main body, excluding appendix).

    Judge claim calibration in BOTH directions. Recommend narrowing only when the
    current scope or modality exceeds the evidence; do not ask for extra hedges
    around a supported result. Flag stacked hedges, self-defence ("we do not
    claim"), instruction confessions ("we do not address X"), and generic caveats
    outside Limitations as writing defects to remove. Tone fixes must never alter
    facts, negation, modality, scope, comparison direction, or numbers.

    Focus on:
    1. Does each claim from the intro have supporting evidence?
    2. Is the writing clear, concise, and free of AI-isms?
    3. Any logical gaps or unclear explanations?
    4. Does it fit within [MAX_PAGES] pages (to end of Conclusion)?
    5. Is related work sufficiently comprehensive (≥1 page)?
    6. For theory papers: are proof sketches adequate?
    7. Are figures/tables clearly described and properly referenced?
    8. Would a skim reader understand the contribution from the title, abstract, introduction, and Figure 1?

    For each issue, specify: severity (CRITICAL/MAJOR/MINOR), location, and fix.

    [paste full draft text]

CRITICAL と MAJOR の修正を適用します。MINOR の問題はユーザー向けに記録します。

Step 7: リバースアウトラインテスト（Research-Paper-Writing-Skills より）

すべてのセクションをドラフトした後：

1. トピックセンテンスを抽出する — 各段落の最初の文を抜き出します
2. 順番に読む — それだけで一貫した話の流れになっている必要があります
3. 主張の網羅性を確認する — Claims-Evidence Matrix のすべての主張が含まれている必要があります
4. エビデンスとの対応を確認する — すべての実験／図が、明示された主張を裏付けている必要があります
5. 不足を修正する — トピックセンテンスがストーリーを前に進めていない場合は、段落を書き直します

ステップ 8：最終チェック

完了とする前に、次の項目を確認してください。

• すべての \ref{} と \label{} が一致している（未定義の参照がない）
• すべての引用コマンド（ML カンファレンスでは \citep{}／\citet{}、IEEE では \cite{}）に対応する BibTeX エントリがある
• 匿名モードで著者情報が記載されていない
• 図表の番号が正しい
• ページ数が MAX_PAGES 以内である（本文の開始から Conclusion の末尾まで）
• テキストに TODO／FIXME／XXX マーカーが残っていない
• 未確認の [VERIFY] マーカーが残っていない
• Abstract が自己完結している（論文を読まなくても理解できる）
• タイトルが具体的で、内容がよくわかる（一般的すぎない）
• Related work が全 1 ページ以上ある
• references.bib に引用されたエントリのみが含まれている（不要な項目がない）
• 古いセクションファイルがない — sections/ 内のすべての .tex が main.tex から \input されている
• セクションファイルが main.tex と一致している — ファイル番号と \input のパスに矛盾がない
• 会議固有の必須セクション／チェックリストを満たしている（必要に応じて ../shared-references/venue-checklists.md を確認）
• 流し読みする読者が、タイトル、Abstract、Introduction、Figure 1／キャプションから主要な主張を把握できる

主なルール

=== 確信を持った文章、限界には誠実に（主張を決して誇張しない）===

1. 各主張を証拠が実際に示す範囲と確度に合わせ、その範囲に合わせた主張を直接述べます。必要な前提、不確実性、適用範囲は主張の一部です。ヘッジを重ねたり、先回りして弁解したりする必要はありません。
2. 現在の主張が裏付けられていない場合は、証拠で裏付けられる範囲に狭めるか、削除します。適用範囲、確度、比較、集約の問題を修正せず、響きの柔らかい類義語に置き換えてはいけません。
3. 一般的な注意書きや、より広範な境界に関する議論は、1つの「限界」セクションにまとめます。それ以外の箇所では、「さらなる研究が必要である」「一般化できない可能性がある」「慎重に解釈すべきである」といった一般的な免責表現を削除します。主張を成り立たせる適用範囲、前提、統計上の但し書きは、その主張に付けたままにします。
4. 重要で具体的な限界を2～4つ示します（データセットの規模、計算環境、前提Xなど）。実在するものに限ります。数を満たすために捏造せず、一般的な謝罪をせず、同じ限界を論文内で繰り返しません。
5. 執筆上の指示は原稿の内容ではありません。「Xに言及しない」とは、Xを省くという意味であり、「Xは扱わない／主張しない／論じない」と書くことではありません。執筆指示、求められた削除、査読者からのフィードバック、改訂履歴を、原稿の文章に決して持ち込んではいけません。
6. 自己弁護（「私たちは主張していない」「私たちの目標は単に～である」）は、論文が実際に示すことを、証拠に即して肯定的に述べる表現に置き換えます。弁解的な文に実質的な境界条件が含まれる場合は、その境界条件を主張または「限界」に残します。真偽を左右する内容は削除しません。
7. 文体だけを整える編集によって、事実、否定、確度、適用範囲、前提、比較の方向、集約、数値、数式、引用を変えてはいけません。実際に過大な主張がある場合は、引き続き範囲を狭めます。裏付けのある主張に冗長な注意書きが付いている場合は、それを取り除き、直接述べます。
8. 因果関係の軸は1本にします。ギャップ -> 問い -> 着想 -> 帰結 -> 証拠 -> 含意の順に展開します。すべてのセクションがこの流れを進めるようにします。手法が必然的に導かれる構成にします。ギャップから具体的な問いが生まれ、核となる着想がその問いに答え、その着想から手法が導かれ、主要な実験がそれぞれの帰結を検証し、結論では証拠が何を示したかを正確に述べます。貢献を冒頭に置き、執筆や改訂の過程は決して語りません。
9. 論文は進捗報告ではなく、打ち出しの場です。新たな能力、問題、メカニズムや視点、より広い適用可能性、低コスト、優れたトレードオフなど、研究の最も強力で真の優位性を軸に構成します。優位性を形作らない内容は、本文の主な流れから外します。結果が当初のストーリーを支えられない場合は、当初のストーリーを弁護するのではなく、最も強い証拠を軸にストーリーを組み立て直します。
10. 論文が勝てる比較軸を選びます。手法が優位でない指標を物語の土台にしてはいけません。その手法の目的を反映するタスク定義、評価軸、制約を中心に比較を組み立て、どの比較軸で優位なのかを明示します。不利な数値も掲載します。表は完全なままにします。証拠が裏付ける場合は、敗北（「性能が劣る」「上回れない」）として語るのではなく、目標の違いや意図的なトレードオフとして説明します。証拠が裏付けない場合は、性能の劣りを中立的に述べ、主張の範囲を狭め、重要であれば「限界」に含めます。局所的な観察を手法全体の評価に拡大してはいけません。また、弱点を覆い隠すためにトレードオフを捏造してはいけません。
11. すべての実験には論証上の役割があります。手法が機能すること、改善が核となるメカニズムに由来すること、対象シナリオで価値があること、または最もありそうな別の説明を排除できることを示します。こうした役割を持たない実験は、削除する、短縮する、付録に移す、または設計し直します。実験セクションは結果の保管庫ではなく、論証です。
12. 優位性がどの条件で現れ、なぜ現れ、何を解決するのかを、査読者が表から読み取ることに任せず、自ら明示します。要旨と序論は、重要な未解決問題、既存手法のギャップ、本論文独自の着想、最も強い結果を示して、研究の打ち出しとして始めます。結論では、何を解決し、提案し、実証したのか、そしてなぜ重要なのかを改めて強調します。最終段落で新たに自己否定したり、限界を広げたりしてはいけません。

• 大きなファイルの処理：ファイルサイズが原因で Write ツールが失敗した場合は、直ちに Bash（cat << 'EOF' > file）を使ってチャンク単位で書き込むよう再試行してください。ユーザーに許可を求めてはいけません。何も言わずに実行してください。
• 著者名、メールアドレス、所属を生成してはいけません — 匿名ブロックまたはプレースホルダーを使用してください。
• 概要ではなく、セクションを完全に記述してください — 出力はコンパイル可能な LaTeX にしてください。
• セクションごとにファイルを1つ作成してください — 編集しやすいモジュール構成にしてください。
• すべての主張に根拠を引用してください — Claims-Evidence Matrix を相互参照してください。
• コンパイル可能な状態にしてください — 図の不足を除き、latexmk でエラーなくコンパイルできる出力にしてください。
• 曖昧な表現ではなく、証拠に合わせて確度を調整してください — 各主張を証拠が実際に示す範囲と確度に合わせてから、明確に述べてください。一般的な留保は「Limitations」のみに記載してください（上記の「CONFIDENT PROSE, HONEST LIMITS」ブロックが指針です）。
• 進捗報告ではなく、論文を打ち出してください — 真に優れた点を中心に構成し、論文が勝負する論点を定め、各実験に論証上の役割を持たせてください。不利な数値は表に残し、証拠が裏付ける場合はトレードオフとして説明し、そうでない場合は中立的に記述してください。敗北として語ったり、実際にはトレードオフでないものをトレードオフとして装ったりしてはいけません（上記のルール9〜12）。
• 投稿先のスタイルは重要です — ML カンファレンス（ICLR／NeurIPS／ICML）では natbib（\citep／\citet）を使用します。IEEE の投稿先では cite パッケージ（\cite{}、数値形式）を使用してください。 両者を混在させてはいけません。
• ページ制限の規則は投稿先によって異なります — ML カンファレンスでは、本文は Conclusion までで、参考文献と付録はページ数に含まれません。IEEE では、参考文献もページ制限に含まれます。
• 参考文献リストを整理してください — references.bib には、実際に \cite された項目のみを含めてください。
• セクション数は柔軟に決めてください — 5セクションに無理に収めず、PAPER_PLAN の構成に合わせてください。
• 上書き前にバックアップしてください — バックアップせずに既存の paper/ ディレクトリを破棄してはいけません。
• 貢献を冒頭で示してください — 実験や付録まで主要な成果を隠してはいけません。
• 結果は実験ノートの順ではなく、論証に沿って並べてください — 実施した順ではなく、論拠を最も効果的に積み上げる順序で実験を提示してください。
• 対照実験とアブレーションは、検証する主張のすぐ近くに配置してください — 読者が論点を忘れた頃に、離れた小節へまとめてはいけません。

執筆品質の参考資料

• ../shared-references/writing-principles.md — ストーリーの構成、概要・序論のパターン、文単位の明瞭さ、査読者が読む順序
• ../shared-references/venue-checklists.md — 完了と判断する前に確認すべき ICLR／NeurIPS／ICML／IEEE の投稿要件
• ../shared-references/citation-discipline.md — 引用が曖昧な場合に適用する、より厳格な基準

上記のメインワークフローにあるリバースアウトラインのテストと誇張を抑えるための推敲を引き続き行ってください。共有資料は、新たなフェーズを加えることなく品質を高めるためのものです。

謝辞

執筆方法は Research-Paper-Writing-Skills（CCF 受賞の方法論）を参考にしています。引用の検証には claude-scholar と Imbad0202/academic-research-skills を利用しています。このハイブリッドパックの執筆ガイダンスのオーバーレイは、Orchestra Research の論文執筆資料を参考にしています。