simulate-reviewers

レビュアーをシミュレーションする

投稿前に、論文を会場の特性に合わせて調整した模擬レビュー委員会にかけます。NeurIPS のメイントラックのレビュアーと SIGSPATIAL のデモトラックの審査員は、異なるしきい値で異なる理由から不採択にします。このスキルは、その違いを再現します。ペルソナに基づく弱点の洗い出し、会場独自の尺度による評価基準の採点、そして、まだ修正が間に合ううちに著者に修正点を伝える、決定論的な採否リスクの判定を行います。

使用するタイミング

• 「この論文についてレビュアーは何と言うでしょうか？」／「レビューをシミュレーションして」
• 「厳しい NeurIPS のレビュアーとしてレビューして」／「Reviewer 2 は何を嫌がるでしょうか？」
• 「KDD に出すには十分でしょうか、それともショートトラックを目指すべきでしょうか？」
• 「レビュアーに指摘される前に弱点を見つけて」／「投稿原稿をレッドチームで検証して」
• preflight-check に合格した後（フォーマットに問題がない状態）から投稿前まで — このスキルは内容を評価し、preflight は要件への準拠を評価します。

入力

1. 論文：.tex のソースツリー、PDF、または読み取り可能な形式の草稿。 一時的に処理し、論文の文章をリポジトリにコピーしないでください。
2. 会場プロファイル：venues/conferences/<venue>-<year>.yml（スキーマは venues/schema.yml）。プロファイルがない場合は、まず parse-cfp で作成するか、 最も近い分野のデフォルト設定で実行し、その旨を伝えてください。
3. 対象トラック（ページ数の上限とレビュアーの期待事項は異なるため、確認してください）。

手順

1. 調整済みのレビューパケットを作成します。 次を実行します。

   python3 scripts/review_form.py venues/conferences/<venue>-<year>.yml \
       --track "<track>"
   

   これは決定論的に動作し、オフラインで実行できます。分野プロファイルを統合し、 審査委員会（ペルソナと厳しさ）、会場の採点尺度と境界しきい値、評価基準、 レビュアー別のフォームのひな形、scores.json のテンプレートを出力します。 機械可読な出力には --json を追加してください。終了コード：0 は成功、 2 はプロファイルがない、解析できない、または不明なトラックです。

2. 公開中の CFP と必ず再照合します。 プロファイルやスクリプト内の尺度の基準点は 過去の慣例であり、正解とは限りません。プロファイルの cfp_url（およびリンク先に レビュアー向けガイドラインのページがあればそのページ）を取得し、レビューの尺度と フォーム、匿名性のレベル、反論の形式、トラックごとの期待事項を確認してください。 相違があればプロファイル YAML を更新し、レポートに相違点を記載して、公開中の 情報を優先してください。記載する会場情報にはすべて、信頼度タグとクリック可能な 出典を付けてください：verified-live／corroborated／inferred-from-family／ needs-verification。出典なしでユーザーに尺度の数値を伝えるのは、利便性ではなく バグです。

3. 論文全体を読み、主張の一覧を作成します。 新規性に関する主張（「初の」、 「最先端の」、「上回る」）、すべての実証的な主張、およびそれぞれの根拠が記載 されている箇所を列挙してください。この一覧をペルソナが検証します。手順は references/weakness-hunting.md を参照してください。

4. 各レビューは、ペルソナに従って独立して執筆します。 パケットに記載された順に、各レビュアーにつき1回ずつ、執筆中は他のレビューを参照せずに書きます（実際のレビューは独立しており、それぞれが独立に見つけた一致する懸念こそ、最も強いシグナルです）。ペルソナの振る舞い、厳しさの調整、トラックごとの修正内容は、references/reviewer-personas.mdで指定されています。 根拠の提示に関するルール — 必ず守ってください：

   • 各レビューは、本物の「強み」から始め、その後に「弱み」を記載します。 実際の査読フォームのようにしてください。具体的な強みを2〜4個挙げます（論文の優れた点：新規性、優れた実験、明瞭さ、有用な成果物など）。弱みと同様に、それぞれをセクションや図に基づいて示してください。欠点ばかりのレビューは本物のレビューではなく、修正する際に何を維持すべきかについて著者を誤解させます。水増しするために強みをでっち上げてはいけません — 論文に弱点があるならそう述べつつ、真に優れている点を見つけてください。
   • すべての弱みについて、セクション、図、行を引用するか、1文以下を引用してください。
   • 先行研究をでっち上げてはいけません。ペルソナが関連研究の不足を疑う場合は、find-papersで実在する候補を探し、verify-citationsで検証してください — あるいは、架空の引用を使わずに「Xに関する先行研究が存在するなら、R4が見つけるでしょう」のように条件付きで懸念を述べてください。
   • 誤読が許されるのは、流し読みをするペルソナに限られ、実際の本文の記述から生じうる誤読でなければなりません。

5. ルーブリックで採点し、その後、投稿先の評価尺度に当てはめます。 各レビュアーについて、4つの主要な評価項目（新規性、妥当性、再現性、明瞭さ）を、references/rubrics.mdの基準に従って1〜5で採点し、その後、パケットに記載された投稿先の総合評価尺度と確信度に対応づけます。 厳しさの調整：厳しさが5の場合、未解決の妥当性に関する弱点があれば、総合評価は少なくともボーダーライン・リジェクトとなります。厳しさが2の場合（デモトラック）、評価の上限とはせず、質問として扱います。

6. 決定論的に集計します。 手順1の scores.jsonテンプレートを埋めて、次を実行します。

   python3 scripts/aggregate_scores.py scores.json
   

   信頼度加重平均、評価の不一致・支持者・反対者のフラグ、評価を引き下げる評価項目、決定リスクの区分（採択見込み低／ボーダーライン・リジェクト／ボーダーライン・アクセプト／採択見込み高）を算出します — 「支持者がいないボーダーラインは下方に判定する」というルールも含まれます。--exampleは有効な入力を出力し、--jsonは機械処理用の出力を指定します。入力が無効な場合は終了コード2で終了します。

7. メタレビューと修正リストを作成します。 AC／1AC／AEのペルソナとして、レビューを総合し、最も大きな共通の懸念を挙げ、支持者がいるかどうかを述べます。その後、すべての弱みを優先順位付きの修正リストに変換し、各項目に次のタグを付けます。

   • fix-now — 投稿前に対応可能（アブレーションの追加、主張の緩和、再現性に関する説明の追加）。
   • rebuttal-defensible — この投稿先の反論形式で対応可能（プロファイルのreview.rebuttal_format／制限を確認）。
   • structural — 今回のサイクルでは修正できません。別の投稿先／トラックを検討してください（select-venueに引き継ぎます）。 ボーダーライン・リジェクトを予測する要因として明示的に確認すべき項目は、references/weakness-hunting.mdに記載されています。

出力

チャットに提示する、シミュレーションによる査読パケット（ユーザーからの依頼があった場合に限り、ファイルに書き出します）。

• 独立したレビューN件。投稿先の形式に従い、それぞれ「強み」のセクションから始め、「弱み」、質問、下位評価の順に記載します。
• メタレビュー。維持すべき最大の強みと、修正すべき最大の共通リスクを挙げ、支持者がいるかどうかを述べます。
• スコア表と、aggregate_scores.pyによる決定リスクの読み取り結果。
• 優先順位付きの修正リスト。各項目にfix-now／rebuttal-defensible／structuralのいずれかのタグを付けます。

すべての出力に、免責事項として次の内容を含めてください。このシミュレーションは論文の改善を目的とするものであり、実際の結果を予測するものではありません。

実例

NeurIPS メイントラックへの 9 ページの投稿です。python3 scripts/review_form.py venues/conferences/neurips-2026.yml --track Main を実行し、 CFP をライブで確認した後（スケールと反論形式を確認し、verified-live とタグ付け）、 4 人のペルソナが個別に記述されます。収束が見られます。経験的な懐疑論者の R2 と 隣接分野の専門家 R4 は、互いの評価を見ずに、同じギャップにたどり着いています。

R2、弱点。 「表 2 では単一の実行結果しか報告されていません（§5.1）。5 個の シードにわたる ±std を用いた場合、ベースラインとの差 +1.3％は維持されますか？ ベースラインのチューニング予算が同等かどうかも記載されていません。」— 妥当性 2、 確信度 5。

R4、弱点。 「§1 の『X と Y を初めて組み合わせた』という主張には、X-under-Y に 関する 2023 年の研究が考慮されていません。その研究が存在するなら、新規性の主張は エンジニアリング上の差分に限定されます。」（条件付き — find-papers に回付。 架空の引用は提示しません。）— 新規性 2、確信度 4。

scores.json（R1 5/4、R2 4/5、R3 6/2、R4 5/4）に記入して集計すると、次の結果になります。

conf-weighted mean: 4.8   delta vs threshold: -0.133 (normalized)
DECISION RISK:      BORDERLINE-REJECT
drag dimensions:    soundness 2.5, reproducibility 2.75
flags:              strong detractor present (R2) — objection must be rebuttal-proof

修正リストでは、複数の評価で一致した所見が最初に挙げられます。fix-now — 表 2 に 5 個のシードの ±std とチューニング予算の同等性を追加します（妥当性の最低点を 脱するための最も手軽な方法です）。fix-now — X-under-Y に関する先行研究を確認し、 それに応じて「初めて」という主張を弱めます。メタレビューでは、閾値を超えた唯一の スコアが、確信度の低い流し読みをした評価者によるものである（実質的な支持者はいない） と指摘しています。そのため、妥当性に関する異議が投稿前に解消されない限り、ボーダー ラインの評価は下方に傾きます。

専門分野に合わせて調整する

パネルとスケールは、投稿先の family: フィールドに基づいて選択されます。ほかの分野で 使用する場合は、scripts/review_form.py と会場 YAML に、そのコミュニティ向けの調整項目 （ペルソナとスケール）を追加してください。たとえば、アクションエディター 1 人と 査読者 2 人で構成し、採択／軽微な修正／大幅な修正／不採択を判定する APA ジャーナルの パネルなどです。

ガードレール

• シミュレーションを予測として提示してはいけません（「あなたの論文は NeurIPS で 5 を 取ります」など）。「シミュレーション上のパネルは X と評価しました。実際のパネルの 評価には大きなばらつきがあります」と伝えてください。
• 引用、査読者の身元、発言を捏造してはいけません。ペルソナは典型的な査読者像であり、 実在する研究者の名前を付けてはいけません。関連研究の不足に関する指摘は find-papers と verify-citations に通すか、条件付きのままにしてください。
• 査読プロセスに関する事実は、ライブの cfp_url で再確認してください（ステップ 2 は 必須です）。プロフィールの古さが判明した場合は、レポートに明記してください。
• 論文は一時的に処理し、所見ごとに引用する文は最大 1 文にしてください。このリポジトリに 論文の本文を保存してはいけません。
• ユーザーに代わって、いかなる査読システムにも投稿したり、投稿内容を公開したりしては いけません。
• 作業中に見つかった形式やコンプライアンスの問題は対象外です。preflight-check に 回してください。

メモリー

このスキルは、ユーザーの論文ディレクトリにある共有 .paper-memory/ 規約を使用します。 詳細は paper-memory-convention.md を参照してください。

• 開始時： .paper-memory/profile.yml（専門分野、リスク許容度、投稿先のランク）を 読み、パネルと、ペルソナが新規性の主張をどの程度厳しく評価するかを調整してください。 また、lessons.md を読み、これまでに指摘された弱点や、著者が繰り返す recurring な 弱点（例：「アブレーションが不十分」「貢献を過大に主張している」）を確認し、メタレビューで それらを先に取り上げられるようにしてください。
• 終了時： 共有形式 - [YYYY-MM-DD] (simulate-reviewers | <scope>) weakness -> recommendation で、長期的に役立つ弱点を追記して ください（重複を除去して日付を付ける reflect-and-improve の reflect_log.py append を 使用します）。複数の草稿に共通して見られる構造的な傾向は recurring、草稿固有の ギャップは this-paper とします。査読者ごとのスコアのばらつきは記録しないでください。
• .paper-memory/ がない場合は必要に応じて作成し、プロジェクトの .gitignore に追加する ことを提案してください。これはローカル専用です。アップロードしたり、このリポジトリに コピーしたりしてはいけません。