rebuttal

ワークフロー 4：反論

次の内容について、根拠に基づき、投稿先の規定に準拠した反論を準備し、維持します：$ARGUMENTS

対象範囲

このスキルは、次の用途に最適化されています：

• テキストのみの反論（文字数・語数の厳しい制限がある場合。例：ICML の単一文書形式）
• 査読者ごとのスレッド返信（査読者ごとに個別に表示される場合。例：OpenReview 形式）
• 共通の懸念と査読者固有の懸念がある複数の査読者
• 初回の反論後の追加ラウンド
• 捏造なし、過度な約束なし、すべての論点を網羅した安全な草案作成

このスキルは、次のことは行いません：

• 新しい実験を自動で実行する
• 新しい定理の主張を自動で生成する
• 改訂版 PDF を編集またはアップロードする
• OpenReview / CMT / HotCRP に投稿する

ユーザーが新しい結果、導出、または承認済みの確約をすでに持っている場合、このスキルはそれらをユーザー確認済みの証拠として取り入れられます。

ライフサイクルにおける位置付け

Workflow 1:   idea-discovery
Workflow 1.5: experiment-bridge
Workflow 2:   auto-review-loop (pre-submission)
Workflow 3:   paper-writing
Workflow 4:   rebuttal (post-submission external reviews)

定数

• VENUE = ICML — デフォルトの投稿先です。必要に応じて上書きしてください。
• RESPONSE_MODE = TEXT_ONLY — v1 のデフォルトです。
• REVIEWER_MODEL = gpt-6-astra — Codex バックエンドのデフォルトモデルです。内部のストレステストに使用します。手動バックエンドでは、ユーザーが選択したモデルを使用します。使用できるのは、異なるファミリー（OpenAI、Anthropic、Google、DeepSeek、Moonshot/Kimi、Qwen）の、認識済みモデルに限られます。
• REVIEWER_BACKEND = codex — デフォルトは Codex MCP（xhigh）です。Oracle MCP を使う場合は — reviewer: oracle-pro、Manual Review MCP を使う場合は — reviewer: manual で上書きします。Manual Review MCP を利用できない場合は、停止してインストールコマンドを表示してください。Codex にフォールバックしないでください。shared-references/reviewer-routing.md を参照してください。
• MAX_INTERNAL_DRAFT_ROUNDS = 2 — 草案 → リント → 改訂。
• VENUE_MODE = single_document — 著者共通の返信を 1 つ作成する場合は single_document、査読者ごとに個別のスレッドが表示される場合は per_reviewer_thread を指定します。不明な場合は、草案作成前に投稿先／インターフェースを確認してください。Phase 4/7 の出力形式に影響します。
• STRESS_TEST_ROUNDS_BASE = 1 — 返信全体に対して、外部査読者による批評を 1 ラウンド実施します。reviewer_priority: pivotal の返信には、査読者から新たな実質的問題が返されなくなるまで、重点的なラウンドを追加します。上限は 5 ラウンドです。
• MAX_FOLLOWUP_ROUNDS = 3 — 査読者ごとのスレッドにつき最大 3 ラウンドです。
• AUTO_EXPERIMENT = false — true の場合、戦略計画で査読者の懸念に対処するため新しい実証的証拠が必要と特定されたとき、補足実験を実行するために /experiment-bridge を自動で呼び出します。false（デフォルト）の場合は一時停止し、証拠の不足をユーザーに提示して手動での対応を求めます。
• QUICK_MODE = false — true の場合は Phase 0〜3 のみ実行します（査読コメントの解析、懸念事項の細分化、戦略の策定）。ISSUE_BOARD.md と STRATEGY_PLAN.md を出力して停止します。草案作成とストレステストは行いません。査読者が求めていることをすばやく把握し、対応を決める際に便利です。
• REBUTTAL_DIR = rebuttal/
• RENDER_HTML = true — true（デフォルト）の場合、Phase 6 / Phase 8 で最終化した後、rebuttal/REBUTTAL_DRAFT_rich.md（査読者向けの詳細な草案）を自動で HTML にレンダリングします。Codex による完全なレビューゲートを使用します（投稿前の最終成果物であり、査読者向けの内容のため、レンダリングの忠実性が重要です）。プレーンテキストの PASTE_READY.txt はレンダリングされません。設計上、文字数をカウントするプレーンテキストです。スキップするには false に設定するか、— render html: false を渡してください。

上書きの例：/rebuttal "paper/" — venue: NeurIPS, character limit: 5000

レビュアーの呼び出し規約

ストレステストのためにレビュアーを呼び出す際は、REVIEWER_BACKEND に応じて分岐します。

REVIEWER_BACKEND = codex の場合： 新しいレビュースレッドには mcp__codex__codex を使用します。 追加のレビューラウンドには mcp__codex__codex-reply を使用します（threadId を再利用します）。

REVIEWER_BACKEND = manual の場合： 新しいレビュースレッドには、次の内容で mcp__manual_review__review を使用します。 prompt: [Codex に送信するものとまったく同じプロンプト] config: {"model_reasoning_effort": "xhigh", "executor_model": "", "require_reviewer_model": true} 返された threadId を保存します。 追加のレビューラウンドには、次の内容で mcp__manual_review__review_reply を使用します。 threadId: [保存した manual-review の threadId] prompt: [追加レビューのプロンプト] config: {"model_reasoning_effort": "xhigh", "executor_model": "", "require_reviewer_model": true}

プロンプトの忠実性：manual のプロンプトは、Codex が受け取るものとまったく同じテキストでなければなりません。 レビューの追跡は、どちらのバックエンドにも同様に適用されます。

必須入力

1. 論文のソース — PDF、LaTeX ディレクトリ、または概要
2. 元のレビュー — レビュアー ID を含む、貼り付けたテキスト、Markdown、または PDF
3. 投稿先の規則 — 投稿先の名称、文字数／単語数の上限、テキストのみか改訂版 PDF を認めるか、出力形式（全レビュー共通の回答か、レビュアーごとの個別スレッドか）
4. 現在の段階 — 初回の反論回答または追加ラウンド

投稿先の規則、上限、または出力形式が不明な場合は、作成を中断して確認してください。

安全モデル

3 つの必須ゲートがあります。いずれかに不合格の場合は、最終版を作成してはいけません。

1. 出典ゲート — すべての事実に関する記述は、paper、review、user_confirmed_result、user_confirmed_derivation、または future_work のいずれかに対応していなければなりません。出典がない場合はブロックされます。
2. コミットメントゲート — すべての約束は、already_done、approved_for_rebuttal、または future_work_only のいずれかに対応していなければなりません。承認されていない場合はブロックされます。
3. 網羅性ゲート — すべてのレビュアーの懸念は、answered、deferred_intentionally、または needs_user_input のいずれかに分類されていなければなりません。論点を未対応のまま残してはいけません。

ワークフロー

フェーズ 0：再開または初期化

1. rebuttal/REBUTTAL_STATE.md が存在する場合 → 記録されたフェーズから再開します
2. それ以外の場合 → rebuttal/ を作成し、すべての出力ドキュメントを初期化します
3. 論文、レビュー、投稿先の規則、ユーザーが確認済みの根拠を読み込みます

フェーズ 1：入力の検証とレビューの正規化

1. 投稿先の規則が明確であることを検証します
2. すべてのレビュアーのテキストを rebuttal/REVIEWS_RAW.md に原文のまま正規化します
3. メタデータを rebuttal/REBUTTAL_STATE.md に記録します
4. 曖昧な点がある場合は、一時停止して確認します

フェーズ 2：レビュアーの懸念事項の分割と分類

rebuttal/ISSUE_BOARD.md を作成します。

個々の懸念事項ごとに、次の項目を記録します。

• issue_id（例：R1-C2）
• reviewer、round、raw_anchor（短い引用）
• issue_type：assumptions / theorem_rigor / novelty / empirical_support / baseline_comparison / complexity / practical_significance / clarity / reproducibility / other
• severity：critical / major / minor
• reviewer_stance：positive / swing / negative / unknown
• reviewer_priority：standard / pivotal
  • pivotal — 適切に対処すれば判定に影響する可能性が高いレビュアーです。評価が低い、またはボーダーラインであること、対処可能な懸念があること、そして影響を及ぼすのに十分な確信度／影響力があることが条件です。フェーズ 3 では、このレビュアーに追加のドラフト作成とストレステストの予算を割り当てます。
• response_mode：direct_clarification / grounded_evidence / nearest_work_delta / assumption_hierarchy / narrow_concession / future_work_boundary / structural_distinction
  • structural_distinction — 「あなたの手法は X に帰着する」「単なる汎用的な Y だ」「Z に包含される」といった批判に使用します。局所的な簡約には同意したうえで、パラメーター化が維持する構造上の特徴のうち、X／Y／Z では捉えられないものを、具体的なメカニズム（定理の依存関係、導出の段階、または実証的な帰結）で裏付けて示します。裏付けとなるメカニズムなしに、修辞的に使用してはいけません。
• status：open / answered / deferred / needs_user_input

フェーズ 3：戦略計画の作成

rebuttal/STRATEGY_PLAN.md を作成します。

1. 共通の懸念を解消する 全体テーマ を 2～4 個特定します
2. 各問題について 回答モード を選択します
3. 文字数配分 を設定します（冒頭 10～15％、査読者ごとの回答 75～80％、締めくくり 5～10％）。これは single_document モードに適用されます。per_reviewer_thread モードでは、スレッドごとの単語数／文字数の目標を設定してください
4. 重要な査読者（その投票または確信度の変化が判断に最も大きな影響を与える査読者。特に、懸念が思想的なものではなく、対処可能な場合）を特定します。ISSUE_BOARD.md で reviewer_priority: pivotal と指定してください。該当する査読者は複数の場合があります。これらの査読者に対し、ドラフト作成とストレステストの予算を優先的に配分します。
5. 根拠のない主張（裏付けがない、または未承認の主張）を特定します
6. ブロッカーが未解決の場合 → 一時停止してユーザーに提示します 判定に関わる手動回答は、必ず次の行で始めてください。 Reviewer-Model: <exact-model-id> — executor_model には、このセッションで実際に実行されているモデルを指定してください。モデルが欠落している、不明である、または同じファミリーのモデルである場合、判定の根拠として認められません。推測せずに REVIEW_UNAVAILABLE を出力してください。実行モデルを特定できない場合、手動レビューにおける異なるモデルファミリーであるという主張は立証できません。その旨をレポートに記載し、主張しないでください。

QUICK_MODE の終了条件：QUICK_MODE = true の場合、ここで停止します。ISSUE_BOARD.md と STRATEGY_PLAN.md をユーザーに提示し、査読者ごとの問題数、共通の懸念と固有の懸念、推奨する優先事項、根拠の不足を要約します。その後、ユーザーは完全な反論作成（/rebuttal — quick mode: false）に進むか、自分で執筆するかを選択できます。

フェーズ 3.5：根拠のための実験（AUTO_EXPERIMENT = true の場合）

AUTO_EXPERIMENT が false の場合は完全にスキップし、代わりに一時停止して根拠の不足をユーザーに提示します。

戦略計画で新たな実証的根拠が必要な問題が特定された場合（response_mode: grounded_evidence と evidence_source: needs_experiment のタグが付いているもの）：

1. 査読者の懸念に基づいて、小規模な実験計画を作成します。

   • 実施内容（アブレーション、ベースライン比較、スケールアップ、条件確認）
   • 成功基準（どのような結果であれば査読者を納得させられるか）
   • 推定 GPU 時間

2. 小規模な実験計画を使用して /experiment-bridge を呼び出します。

   /experiment-bridge "rebuttal/REBUTTAL_EXPERIMENT_PLAN.md"
   

3. 結果を待ってから、ISSUE_BOARD.md を更新します。

   • 完了した実験に user_confirmed_result のタグを付けます
   • 関連する問題カードの根拠ソースを更新します

4. 実験に失敗した場合、または結果が不確定な場合：

   • 回答モードを narrow_concession または future_work_boundary に切り替えます
   • 肯定的な結果を捏造してはなりません

5. 実験結果を rebuttal/REBUTTAL_EXPERIMENTS.md に保存し、来歴を追跡します。

時間制限：推定 GPU 時間が反論の締め切りを超える場合はスキップし、手動対応が必要であることを記録します。

フェーズ 4：反論の初稿を作成

VENUE_MODE に応じて、ドラフトの成果物を作成します。

• single_document モード → rebuttal/REBUTTAL_DRAFT_v1.md を 1 つ作成
• per_reviewer_thread モード → 査読者ごとに rebuttal/Reviewer_<ID>_response.md を 1 つ作成（トップレベルの REBUTTAL_DRAFT_v1.md は作成しません）

構成は VENUE_MODE によって異なります。

• single_document — REBUTTAL_DRAFT_v1.md を 1 つ作成：

  1. 短い冒頭 — 査読者への謝意と、2～4 個の全体的な解決策
  2. 査読者ごとの番号付き回答 — 回答 → 根拠 → 含意
  3. 短い締めくくり — 解決済みの事項／未解決の事項／採択に値する理由

• per_reviewer_thread — 査読者ごとに、単独で完結する Reviewer_<ID>_response.md を 1 つ作成：

  1. その査読者の主な論点への簡潔な謝意
  2. 番号付きの W#/Q# 回答（回答 → 根拠 → 含意）
  3. 実験設定に関する共通段落（任意。「再利用可能な設定ブロック」を参照）
  • 各ファイルは単独で読める必要があります。「査読者 X への回答を参照」といった参照は含めません。全体向けの冒頭も含めません。

問題ごとのデフォルトの回答パターン：

• 第 1 文：直接回答
• 第 2～4 文：根拠に基づく説明
• 最終文：論文への含意 再利用可能なセットアップブロック（per_reviewer_thread モード）。 複数のレビュアースレッドへの回答で同じ実験セットアップや指標の定義が必要な場合は、標準となる SETUP_METRICS_BLOCK.md を作成してください。必要な各レビュアーファイルで一貫して再利用します。目標は 150 語以下です。本当にレビュアー固有の追加事項がある場合に限り、インラインで拡張してください。一度変更すればすべてに反映されるため、スレッド間の不整合を防げます。

効果的な反論で得られたヒューリスティック（内容）：

• 主張より証拠
• 全体の論旨を先に、レビュアーごとの詳細を後に（single_document モードのみ）
• 直感に反する点には具体的な数値を示す
• 新規性に異議がある場合は、最も近い先行研究と正確な差分を明示する
• レビュアーが正しい場合は、限定的に認める
• 理論については、中心的な仮定と技術的な仮定を分ける
• 好意的なレビュアーにも回答する

レビュアーへの対応策：

• 懸念ごとに必要十分な証拠を示す。 通常は数値を一つ提示します。つまり、そのレビュアーの具体的な質問に直接対応する指標です。他のレビュアーが重視する指標は省きます。内容が膨らむと回答が薄まります。
• 事前登録済みの較正表現。 しきい値やホールドアウトを生成サンプルの確認前に固定していた場合は、「生成サンプルを一つも確認する前にホールドアウトで設定した」のような表現で明示してください。ほとんど語数を増やさずに、チェリーピッキングとの批判をかわすことができます。実際にそのとおりの場合に限り使用してください。
• 一見わかりにくい設計上の選択を先に示す。 実験セットアップに一見わかりにくい注意点（計算量を一致させてもエポック数は一致しない、標準的でないシードの手順、パラメーター部分集合の制限など）がある場合は、設計上の選択が明確になる具体的な数値とともに示してください。敵対的なリバースエンジニアリングを未然に防げます。
• 否定ではなく、構造上の違いを示す。 レビュアーが、あなたの研究は一般的なフレームワークに還元される、またはその枠組みに包含されると主張している場合、その還元を否定しないでください。あなたのパラメーター化が保持し、一般的なフレームワークが保持しない構造的な特徴を明らかにしてください。response_mode: structural_distinction を参照してください。
• 主張を譲らずに譲歩する。 レビュアーの指摘に一理ある場合は、局所的な点を明確に認めたうえで、何が依然として正しく、それがなぜ論文の貢献を支えるのかを述べてください。譲歩と併せて、維持される定理、メカニズム、実証結果、または適用範囲の条件を示します。

厳守事項：

• 実験、数値、導出、引用、リンクを決して捏造しない
• ユーザーが承認していないことを決して約束しない
• 強い証拠がない場合は、言いすぎず、控えめに述べる

single_document モードのみ：さらに、rebuttal/PASTE_READY.txt（プレーンテキスト。OpenReview/CMT の貼り付け欄に合わせた正確な文字数）を生成してください。per_reviewer_thread モードではこの成果物を作成せず、各 Reviewer_<ID>_response.md をそれぞれのスレッドへの貼り付け対象とします。

さらに、rebuttal/REVISION_PLAN.md（全体的な改訂チェックリスト）を生成してください。

この文書は、反論の草案で明示または暗示的に約束した、論文のすべての改訂について唯一の信頼できる情報源となります。反論提出後に著者が進捗を追跡し、Phase 5 のコミットメントゲートが照合できる具体的な成果物を用意するためのものです。

構成：

1. ヘッダー

   • 論文タイトル、投稿先、文字数制限、反論ラウンド
   • ISSUE_BOARD.md、STRATEGY_PLAN.md、REBUTTAL_DRAFT_v1.md へのリンク

2. 全体チェックリスト — 採択後の最終版／改訂 PDF に各項目が反映されたことを著者が確認できるよう、すべての改訂項目を網羅した、GitHub スタイルのフラットなチェックリストを一つ作成します。

   ## Overall Checklist
   
   - [ ] (R1-C2) Add assumption hierarchy table to Section 3.1 — commitment: `approved_for_rebuttal` — owner: author — status: pending
   - [ ] (R2-C1) Clarify novelty delta vs. Smith'24 in Section 2 related work — commitment: `already_done` — status: verify wording
   - [ ] (R3-C4) Add runtime breakdown figure to Appendix B — commitment: `future_work_only` — status: deferred, note in camera-ready
   - ...
   

   チェックリストの各項目は独立した項目（1 行につき論文の編集 1 件）とし、それぞれに issue_id を記載して ISSUE_BOARD.md と対応付けてください。

3. グループ別ビュー — 同じ項目を、（a）論文のセクション／位置別、（b）重要度別に再グループ化し、著者が改訂作業を効率的に計画できるようにします。

4. コミットメントの概要 — already_done／approved_for_rebuttal／future_work_only の件数と、作業の妨げとなっている needs_user_input 項目があればその一覧。

5. スコープ外ログ — 論文の改訂を引き起こさない査読者の懸念（例: deferred_intentionally、編集を伴わない narrow_concession）を、それぞれ一行の理由とともに記載します。これによりチェックリストの誠実さが保たれます。何も黙って消えてしまうことはありません。

REVISION_PLAN.md のルール:

• すべてのチェックリスト項目は、ISSUE_BOARD.md の少なくとも 1 つの issue_id に対応していなければなりません。
• REBUTTAL_DRAFT_v1.md 内の、論文の編集を意味するすべての約束は、チェックリスト項目として現れなければなりません。それが計画に含まれていない場合、コミットメントゲート違反です。
• ドラフトまたはユーザーが確認した証拠に裏付けられていない項目は決して追加しないでください。
• 再実行 / フォローアップのラウンドでは、ゼロから再生成するのではなく、チェックボックスの状態をその場で更新してください。

フェーズ 5: 安全性の検証

すべてのリントを実行します:

1. カバレッジ — すべての issue がドラフトのアンカーに対応している
2. 来歴 — すべての事実文に出典がある
3. コミットメント — 約束が承認されており、かつドラフト内のすべての論文編集の約束が REVISION_PLAN.md のチェックリスト項目として現れている（およびその逆 — 計画内に孤立した項目がない）
4. トーン — 攻撃的 / 従属的 / 回避的な表現にフラグを立てる
5. 一貫性 — 査読者への返信間に矛盾がない
6. 制限 — 正確な文字数をカウントし、超過している場合は圧縮する（冗長性 → 友好的な表現 → 冒頭 → 文言の順で、重要な回答は決して削除しない）
7. スレッドローカルなコンテキスト（per_reviewer_thread モードのみ） — 各査読者ファイルは、他のどの査読者ファイルを読まなくても理解できなければなりません。「査読者 X を参照」といった参照や、スレッド間のコンテキストに依存する未定義の用語にフラグを立ててください。
8. 敵対的な設計選択スキャン — 各実験的主張について尋ねます: 「敵対的な査読者が、私が開示していない非自明な設計選択（計算量の一致、凍結されたサブセット、サンプリングプロトコル）を見つけることはできるか?」もしできるなら、Setup 段落に一行の注意書きを追加してください。来歴よりも狭い範囲で、事実の出典ではなく設計選択に焦点を当てます。

フェーズ 6: 外部査読者ストレステスト

選択したバックエンドを使用します。codex の場合:

mcp__codex__codex:
  model: gpt-6-astra
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    Stress-test this rebuttal draft:
    [raw reviews + issue board + draft + venue rules]

    1. Unanswered or weakly answered concerns?
    2. Unsupported factual statements?
    3. Risky or unapproved promises?
    4. Tone problems?
    5. Paragraph most likely to backfire with meta-reviewer?
    6. Minimal grounded fixes only. Do NOT invent evidence.

    Verdict: safe to submit / needs revision

手動の場合: 同じプロンプトと、上記の査読者呼び出し規約の identity-bearing config（executor_model + require_reviewer_model: true）を指定して mcp__manual_review__review を使用します。

イテレーション。 完全なドラフトに対してベースラウンドを実行します。次に、各 reviewer_priority: pivotal の回答に対してフォーカスしたフォローアップラウンドを実行し、査読者が新しい実質的な問題を返さなくなった時点で終了します。合計 5 ラウンドをハードキャップとします。各ラウンドを rebuttal/MCP_STRESS_TEST_round<N>.md に保存します。最も大きいラウンド番号が最終状態を表します。ハードな安全性ブロッカーが残っている場合 → 最終化の前に改訂してください。

フェーズ 7：最終化

出力は VENUE_MODE によって異なります：

single_document モード — 2 つのバージョンを作成します：

1. rebuttal/PASTE_READY.txt — 厳密版

   • プレーンテキストで、文字数が正確に数えられており、会場の上限に収まる
   • 会場のインターフェースにそのまま貼り付けられる状態
   • Markdown 形式や余分な内容は含めない

2. rebuttal/REBUTTAL_DRAFT_rich.md — 拡張版

   • 同じ構成で、詳細を追加：より詳しい説明、追加の根拠、任意の段落
   • 厳密版の上限を超えるセクションには [OPTIONAL — cut if over limit] と記載
   • 著者が内容を読んで論旨全体を把握したうえで、何を残すか、削るか、書き直すかを手動で判断できる
   • 追加の内容があらかじめ作成されているため、後続ラウンドでも役立つ

per_reviewer_thread モード — 査読者ごとに 1 つのファイルを作成します：

1. rebuttal/Reviewer_<ID>_response.md — 査読者ごとに 1 つの自己完結したファイル。対応する査読者スレッドにそのまま貼り付けられる状態
2. rebuttal/SETUP_METRICS_BLOCK.md — 査読者ごとのファイルで再利用する場合の、任意の標準的なセットアップ／メトリクスの文章
3. rebuttal/SUPPLEMENTARY_FIG_PDF/（任意）— 会場が PDF の改訂を認めない一方で、匿名の図へのリンクを認める場合に、会場の規定に準拠した補足 PDF を生成します。匿名ホスティングサービスや組版スタイルをハードコードせず、対象の会場で認められているものを選んでください。

両方のモード：

4. rebuttal/REBUTTAL_STATE.md を更新します
5. rebuttal/REVISION_PLAN.md を更新し、全体のチェックリストを最終稿に合わせます（項目を追加し、already_done をチェック済みにし、pending の項目は引き継ぎます）
6. ユーザーに以下を提示します：
   • single_document の場合：PASTE_READY.txt の文字数と会場の上限、確認用の REBUTTAL_DRAFT_rich.md
   • per_reviewer_thread の場合：査読者ごとのファイル一覧と各ファイルの単語数、使用した場合は SETUP_METRICS_BLOCK.md、生成した場合は補足 PDF
   • REVISION_PLAN.md のチェックリスト — 保留／承認済み／延期の件数
   • 残っているリスクと手動承認が必要な行

フェーズ 8：フォローアップラウンド

新たな査読者コメントが届いた場合：

1. rebuttal/FOLLOWUP_LOG.md に原文のまま追記します
2. 既存の課題にリンクするか、新しい課題を作成します
3. 差分の返信のみを作成します（全面的な書き直しはしません）
4. rebuttal/REVISION_PLAN.md をそのまま更新します — フォローアップで追加された新しいチェック項目を加え、著者がすでに完了した項目にチェックを付け、既存項目のステータスを最新の状態に保ちます
5. 安全性の静的チェックを再実行します
6. 継続性のために、必要に応じて適切な返信ツールを使用します（Reviewer Calling Convention に従います）
7. ルール：論調ではなく技術面でエスカレーションすること、査読者が正しければ認めること、新たな根拠がなく査読者の考えを変えられない場合は議論をやめること

フェーズ 9：HTML ビューのレンダリング（RENDER_HTML = true の場合に自動実行。デフォルト）

フェーズ 6（初回の反論）またはフェーズ 8（フォローアップラウンド）の後、rebuttal/REBUTTAL_DRAFT_rich.md を最終化し、詳細な草稿に対して /render-html を実行します：

/render-html "rebuttal/REBUTTAL_DRAFT_rich.md"

Codex の完全なレビュープロセスを使用します（査読者に提示する投稿前の成果物であり、レンダリングの忠実度が重要です。リッチ草稿には著者が制御する書式が含まれており、査読者には意図したとおりに正確に表示する必要があります）。出力：埋め込みのソース SHA256 と .review.json サイドカーファイルを含む rebuttal/REBUTTAL_DRAFT_rich.html。

rebuttal/PASTE_READY.txt はレンダリングしないでください — これは意図的に文字数を正確に合わせたプレーンテキストであり、構造化された成果物ではありません。

ブロッキングなし：/render-html が失敗した場合（ヘルパーが見つからない、Codex MCP を利用できない、ファイルの書き込みエラーなど）は、失敗を記録し、反論フェーズは完了したものとして扱います — 正式な出力は PASTE_READY.txt と REBUTTAL_DRAFT_rich.md です。

RENDER_HTML = false の場合はスキップします。

重要なルール

• 大きなファイルの処理：Write が失敗した場合は、Bash のヒアドキュメントで黙って再試行します。
• 捏造しないこと。 根拠、数値、導出、引用、リンクを作り上げてはいけません。
• 過剰な約束をしないこと。 ユーザーが明示的に承認した内容だけを約束します。
• すべてを網羅すること。 査読者からの懸念はすべて記録し、対応します。
• 生の記録を保持すること。 査読や MCP の出力は一字一句そのまま保存します。
• 構成は VENUE_MODE に従います。 single_document → 共通の懸念をまとめた全体の導入部と、査読者ごとの番号付き詳細。per_reviewer_thread → 全体の導入部は設けず、各査読者のファイルをそれぞれ単独で読める形式にします。
• 好意的な査読者にも回答すること。 支持的な論調をさらに強めます。
• メタ査読者向けの締めくくり。 解決済みの点、未解決の点、採択すべき理由をまとめます。
• 修辞より根拠を重視すること。 文章での説明より、導出と数値を優先します。
• 譲歩は慎重に行うこと。 広範な否定より、範囲を絞った誠実な譲歩を優先します。
• 勝ち目のない議論に時間をかけないこと。 一度だけ回答し、次に進みます。
• 制限を守ること。 文字数の上限は厳守します。
• 適切に再開すること。 再実行時は REBUTTAL_STATE.md から続けます。
• 幻覚を防ぐための引用ルール。 追加する参考文献はすべて、DBLP → CrossRef → [VERIFY] の手順を経る必要があります。

査読の追跡

各査読者呼び出し（mcp__codex__codex、mcp__codex__codex-reply、mcp__manual_review__review、または mcp__manual_review__review_reply）の後、shared-references/review-tracing.md（Policy C — forensic）に従って追跡記録を保存します（黙って省略してはいけません）。shared-references/integration-contract.md §2 に記載された手順に従って解決した save_trace.sh を使うか、.aris/traces/<skill>/<date>_run<NN>/ にファイルを直接書き込みます。--- trace: パラメーターに従います（既定値：full）。