rebuttal-strategist

反論戦略

実際の査読者フィードバックを、戦略的な反論計画、実験計画、論文改訂計画、回答草案にまとめます。このスキルは査読結果が届いた後に使用します。投稿前の模擬査読ではありません。

次の用途に使用します。

• OpenReview の査読結果の抽出とスレッド分析
• 査読者の意図と判断状況の分析
• 実際のコメントに基づく課題ボードの作成
• 反論期間中に追加する実験、分析、証明、説明の検討
• 著者回答の項目別草案の作成
• 議論中に投稿する簡潔な追加回答の準備
• 回答で約束した論文改訂の追跡
• 次回に向けた反論の記憶の保存

このスキルは、次のスキルと組み合わせて使用してください。

• 実際の査読結果、課題ボード、反論用の実験、または約束した改訂をセッションをまたいで保持する必要がある場合は、research-project-memory
• 投稿前の模擬査読、または回答草案のストレステストには、paper-reviewer-simulator
• 反論計画で新たな実験が必要な場合は、run-experiment
• 受け入れられた査読者の批判に応じて論文の構成変更や文章の明確化が必要な場合は、conference-writing-adapter
• 査読で引用の問題が指摘された場合は、citation-audit と citation-coverage-audit
• 採択後に、約束した改訂、最終的な主張と証拠の整合性、匿名性の解除、公開への引き継ぎを確認するには、camera-ready-finalizer

スキルのディレクトリ構成

<installed-skill-dir>/
├── SKILL.md
└── references/
    ├── decision-strategy.md
    ├── experiment-response-planning.md
    ├── issue-board.md
    ├── memory-model.md
    ├── openreview-protocol.md
    ├── rebuttal-writing-style.md
    ├── report-template.md
    └── review-intent-analysis.md

段階的な読み込み

• 常に references/review-intent-analysis.md、references/issue-board.md、references/rebuttal-writing-style.md を読みます。
• ユーザーが OpenReview の URL、フォーラム ID、査読スレッドを提示した場合、または査読情報の取得を依頼した場合は、references/openreview-protocol.md を読みます。
• スコア、確信度、査読者の立場、または AC／メタ査読の動向が重要な場合は、references/decision-strategy.md を読みます。
• 査読で実験、ベースライン、アブレーション、証明、分析、または詳細が求められた場合は、references/experiment-response-planning.md を読みます。
• プロジェクトの反論状況を保存または再利用する場合は、references/memory-model.md を読みます。
• 十分な規模の計画や保存レポートには、references/report-template.md を使用します。
• 回答に影響する場合は、会議の公式情報源を確認し、最新の会場の反論規則、回答の長さ、締切、匿名性に関する制約、議論の方針を確認します。

基本原則

• 反論は単に礼儀正しく応じるものではなく、戦略的に行います。目標は、判断に至る道筋を変えることです。
• 対象読者は査読者とエリアチェアです。AC が採択への道筋を見いだせる回答を書きます。
• 説得可能な査読者と影響の大きい誤解を優先します。動かない不採択判断に予算の大半を費やしてはいけません。ただし、その異議がメタ査読を大きく左右する場合は除きます。
• 科学的に実際に問題がある点と、説明上の誤解を切り分けます。
• 証拠を先に示します。各回答では、結果、表、図、定理、付録の詳細、新しい実験、または具体的な改訂案を根拠として示します。
• 妥当な批判は明確に認めます。防御的な口調は信頼を損ないます。
• 著者が実行できない実験、改訂、コード、分析を約束してはいけません。
• 反論中も匿名性と会場の方針を守ります。

ステップ 1 - 反論の状況を定義する

次の項目を特定します。

• 会場、年、トラック
• 回答の締切と、回答の長さまたは形式の制限
• 議論が査読ごと、統一形式、またはその両方のどれで行われるか
• 追加コメントが許可されているか
• 現在のスコア、確信度、メタ査読または AC のコメント
• 論文のソースファイルと付録
• 査読情報のソース：OpenReview の URL、エクスポートした JSON、コピーした査読テキスト、PDF、またはユーザーが書き起こしたスクリーンショット
• モード：
  • plan：戦略、課題ボード、実験計画
  • draft：反論文の作成
  • followup：議論中に寄せられた新たな査読者の質問への回答
  • post-mortem：最終判断後の記憶の更新

課題ボードがまだない場合は、回答草案の作成に入る前に、既定で plan を使用します。

ステップ 2 - レビューと論文の根拠資料を収集する

以下を読み込むか、取得します。

• すべてのレビュー
• スコアと確信度
• 査読者からの質問
• 長所と短所
• 公式コメントとフォローアップスレッド
• メタレビューまたはACコメント
• 論文の概要、序論、手法、実験、付録、図、表、関連研究
• 査読者の懸念に答えられる可能性のある実験ログやメモ

OpenReviewを使用する場合は、references/openreview-protocol.mdに従います。取得がブロックされている場合やログインが必要な場合は、エクスポートしたレビュー本文または貼り付けたコメントをユーザーに依頼します。

ステップ 3 - レビューを個別の論点に分解する

各レビューを個別の論点に分解します。

各論点には、以下を含めます。

• 査読者ID
• 該当箇所に関する具体的な懸念
• カテゴリ：新規性、正確性、理論、実験、ベースライン、アブレーション、関連研究、明瞭さ、再現性、倫理、限界、書式、質問、称賛
• 深刻度
• 査読者の指摘が事実として正しいか
• 既存の根拠で回答できるか
• 対応方針

レビューの長い段落をひとまとめにして回答しないでください。1つの段落に複数の独立した論点が含まれる場合があります。

ステップ 4 - 査読者の意図と判定状況を推測する

references/review-intent-analysis.mdとreferences/decision-strategy.mdを読みます。

査読者ごとに、以下を推測します。

• 立場：強く支持、採択の可能性が高い、説得の余地があるボーダーライン、懐疑的だが対応可能、却下の可能性が高い、方針を変えない却下派
• 中核となるアイデアを評価しているか
• 要求された修正は小規模、中規模、または致命的か
• 明確化を求めているか、却下の根拠を組み立てているか
• どの根拠があれば納得するか

次に、論文全体の判定の見通しを推測します。

• 現在の判定状況
• 主な採択への道筋
• 主な却下への道筋
• 採否を左右する査読者または論点
• ACが重視しそうな点

ステップ 5 - 論点ボードを作成する

references/issue-board.mdを読みます。

論点を以下のように優先順位付けします。

• must-win：うまく回答できれば採否を左右する可能性がある
• must-answer：査読者からの直接の質問、または重大な懸念
• quick-win：簡単な明確化で大きな効果が得られる
• experiment-needed：新たな実験、分析、または証明が必要
• paper-revision：約束する本文の修正で対応できる
• do-not-overinvest：影響が小さい、または方針を変えない反論

論点ボードに基づいて、回答に割く分量を決めます。

ステップ 6 - 実験と根拠を計画する

references/experiment-response-planning.mdを読みます。

根拠が必要な各論点について、以下を行います。

• 信頼性のある最小限の実験、アブレーション、証明の概要、分析、または表を定義する
• 締め切りまでの実現可能性を見積もる
• 必要なデータ、コード、計算資源、指標、担当者を特定する
• 成功、一部成功、失敗の場合の回答文を定義する
• 回答文、付録、今後の改訂のどれに含めるか決める

広く新しい結果を探すよりも、査読者の異議に直接答える、的を絞った実験を優先します。

ステップ 7 - 対応方針を選ぶ

各論点について、以下から対応方針を1つ選びます。

• accept-and-fix
• clarify-misunderstanding
• rebut-with-evidence
• partially-concede
• provide-new-result
• scope-and-limit
• defer-to-revision
• do-not-address-directly

表現の指針として、references/rebuttal-writing-style.mdを読みます。

ステップ 8 - 反論文を作成する

指定された形式で作成します。

• 査読者ごとの回答
• 統合回答
• OpenReviewの著者コメント（短文）
• フォローアップへの返信
• 必要に応じてカメラレディ版の回答要約

標準的な構成：

1. 感謝と論文の主張を1文で述べる
2. 採否を左右する懸念にまず回答する
3. 複数の査読者に共通する懸念をまとめる
4. 新たな結果と具体的な根拠を示す
5. 予定している論文の修正内容を明記する
6. 残りの査読者固有の質問に回答する

簡潔で、防御的でない表現を使います。形式上必要な場合を除き、査読者一人ひとりに個別に謝辞を述べて分量を費やさないでください。

ステップ 9 - 草稿のストレステスト

最終版にする前に、次の点を確認します。

• 草稿は、最も強い却下理由に答えていますか？
• AC が採択できる道筋を示していますか？
• 約束した改訂は実現可能ですか？
• 新しい結果は十分な詳細とともに述べられていますか？
• 査読者の誤解を、対立的な印象を与えずに正していますか？
• 妥当な批判は認めていますか？
• 繰り返し指摘されている問題をまとめていますか？
• 投稿先の分量制限と匿名性の要件を守っていますか？

草稿に問題がある場合は、一度修正し、残るリスクを報告します。

ステップ 10 - メモリーを更新する

references/memory-model.md を読みます。

査読内容を解析した場合、または戦略を作成した場合は、プロジェクト内のメモリーを次の場所に更新します。

.agent/rebuttal-strategy/

以下を記録します。

• 元の査読内容と解析した課題
• 査読者の意図マップ
• 実験計画
• 回答案
• 約束した論文の改訂
• 追加の議論の状況
• 判明している場合は最終決定

プロジェクトで research-project-memory を使用している場合は、次も更新します。

• memory/risk-board.md：実際の査読者リスクと課題の深刻度を記録します。査読文には確実性 observed を、意図には inferred を使用します。
• memory/action-board.md：反論のための実験、回答の草稿作成タスク、約束した改訂、反論後のフォローアップを記録します。
• memory/evidence-board.md：反論のために新たに行った実験、証明の概略、分析、表を記録します。
• memory/claim-board.md：査読者が異議を唱えた、弱めた、明確化した、または支持した主張を記録します。
• rebuttal/.agent/rebuttal-status.md：課題ボード、査読者の意図マップ、回答計画、約束した改訂、議論の状況を記録します。

論文やコードに変更が加わるまでは、約束した改訂を完了済みとして記録しないでください。約束とアクションを関連付けてください。

出力モード

戦略プラン

# Rebuttal Strategy
## Situation Summary
## Reviewer Intent Map
## Decision Path
## Issue Board
## Experiment / Evidence Plan
## Response Posture
## Draft Outline
## Follow-up Strategy

回答案

# Rebuttal Draft
## Response Strategy Notes
## Draft
## Claims Requiring Verification
## Promised Paper Revisions
## Remaining Risks

追加の返信

# Follow-Up Reply
## New Reviewer Comment
## Intent Assessment
## Recommended Reply
## Risk If Ignored

最終確認

最終版にする前に、次の点を確認します。

• 実際の査読内容と推測した意図が区別されています。
• 利用可能なすべてのスコアと確信度が記録されています。
• 決定的な査読者または課題が特定されています。
• 必ず解決すべき各課題に、根拠または明確な代替策があります。
• 回答文は投稿先の制限とポリシーに従っています。
• 実現不可能な約束をしていません。
• 実験計画に実現可能な期限が設定されています。
• 論文の改訂に関する約束が追跡されています。
• ユーザーがプロジェクトリポジトリで作業している場合、メモリーの更新が書き込まれています。