mcpField
R
rebuttal-response

rebuttal-response

github.com/boom5426ドキュメント637106 回インストール2 週間前に更新
リポジトリ

rebuttal-response について

査読回答の作成・改訂に向けた学術執筆ガイドです。各指摘への回答、根拠、原稿の修正箇所を対応付け、証拠に見合う主張と原稿・補足資料との整合性を重視します。

主な機能

  1. 01査読コメントを個別の要望に分解
  2. 02回答・根拠・修正箇所を対応付け
  3. 03コメントの複雑さに応じた構成
  4. 04根拠に合わせた主張の調整
  5. 05回答と原稿の整合性確認
  6. 06回答と改訂内容の最終監査

活用シーン

  1. 01複数の要望を含む査読への回答作成
  2. 02長く追いにくい回答書の再構成
  3. 03結果と修正箇所の記載確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/boom5426/nature-paper-skills --skill rebuttal-response

インストール後、Claude Code で/rebuttal-responseを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
final-audit.md
response-patterns.md
triage-and-stance.md

詳細

査読者への回答を見直す

忙しい読者が読みやすい査読者への回答を作成します。正式な回答はすべて、査読者への簡潔な謝意から始めてください。そのうえで、各回答が査読者の具体的な懸念にすぐ対応するようにします。まず実施したことと得られた結果を述べ、それが何を意味するのかを示し、原稿のどこを変更したのかを明記してください。査読者に対応関係を推測させたり、段落をまたいで探させたり、回答が明らかになった後に弁解めいた文章を読ませたりしないでください。

正式な資料を起点にする

  1. コメントに関連する最新の回答書、原稿、Supplementary Information、図、表、結果ファイルを特定します。
  2. ユーザーが示した版の優先順位を厳守します。原稿またはSIが正式な資料であるとユーザーが指定している場合、古い回答の文章や結論を再利用しないでください。
  3. 編集する前に、査読者のコメント全文と現在の回答全文を読みます。
  4. コメントを、個別に回答可能な要望に分けます。データセット、手法、比較単位、求められている解析、主張されている結果など、査読者が使った名詞や区別をそのまま保ってください。
  5. 要望ごとに1行を設けた対応表を内部で作成します。
    • 査読者の具体的な懸念または表現
    • 直接的な回答
    • 実施内容または根拠
    • 結果
    • 根拠が裏付ける結論
    • 修正箇所
    • 真に必要な場合に限り、根拠の適用範囲
  6. この対応表を受け入れ基準として使います。すべての項目が回答に明示されていなければなりません。近接する別の解析で、求められた対象への回答を代替してはいけません。
  7. 結果、統計値、実験、引用、修正箇所、プレースホルダーの値を捏造してはいけません。値が得られない場合はその旨を明記するか、不足している資料を求めてください。

文書を直接編集する作業の場合は、関連するドキュメントスキルも使用し、完成したファイルをレンダリングして見た目を確認してください。

下書きの前に分析する

ユーザーが最終文面のみを明示的に求めている場合を除き、まず簡潔な診断を行います。

  • 査読者が実際に求めていることは何ですか?
  • 懸念は方法論、根拠、解釈、提示方法、用語のいずれに関するものですか?
  • 新たな実験、既存結果の追加解析、説明の明確化、あるいは表現を限定するだけで解決しますか?
  • 得られている根拠から支持できる最も強い結論は何ですか?
  • 回答の信頼性を確保するには、原稿、SI、または回答のどの記述を変更する必要がありますか?

実験を追加すれば最善の対応になると決めつけないでください。懸念を実際に解消できる最小限の対応を優先します。ただし、表現を変更して根拠の真の不足を隠してはいけません。

コメントの原因を分類し、回答で譲歩するか、明確化するか、異議を述べるかを判断するために、triage-and-stance.md を読んでください。下書きの前にその判断を済ませます。主張の強さの調整は、選んだ立場に適用するものであり、立場を選ぶことの代わりにはなりません。

複雑さに応じて回答の構成を選ぶ

すべてのコメントに同じテンプレートを当てはめないでください。

  • 単純なコメント: 簡潔な段落ひとつに、直接的な回答または対応、必要に応じて修正した文章、修正箇所を記載します。
  • 中程度の実質的なコメント: 独立した概要をひとつ置き、その後に査読者の実際の個別質問に沿った名称のセクションを2つまたは3つ設け、最後に正確な修正箇所を記載する段落を置きます。
  • 複雑な複数項目からなる主要コメント: 独立した概要をひとつ置き、必要に応じて Specifically, we: の対応リストを続け、その項目と同じ順序で対応する根拠のセクションを設け、最後に正確な修正箇所を記載する段落を置きます。

対応リストは、案内に実質的に役立つ場合にのみ使用してください。使用する場合は、正真正銘の目次として機能させます。項目数、順序、概念、見出しは詳細セクションと一致させてください。遺伝子解析と薬剤解析の両方がひとつの実験に属する場合、実験全体の対応と、その下位レベルの結果を並列に記載しないでください。

概要は、最初の段落だけを読む査読者にも内容が伝わるものにしてください。最初の文では、査読者への感謝を簡潔に述べます。コメントに応じて、たとえば We thank the reviewer for this important comment、We appreciate the reviewer's helpful suggestion、We thank the reviewer for raising this point のように自然に表現を変えてください。回答書全体で同じ表現を機械的に繰り返したり、過度に称賛したり、受け入れていない前提に同意したり、感謝の文でコメント全体を言い換えたりしないでください。

感謝の文の直後には、懸念に対応したことを告げるだけの文ではなく、その懸念を解決する対応、結果、または直接的な回答を示してください。根拠が得られる場合は、次の順序に従ってください。

  1. 簡潔な感謝;
  2. 対応または実験;
  3. 中心となる結果;
  4. 査読者への直接的な回答;
  5. 原稿の変更。

詳細セクションには、著者側の内部的な論理区分ではなく、査読者が質問している対象を見出しとして付けてください。正確であれば、査読者が使用した専門用語をそのまま使ってください。査読者が2つの表現、データセット、ベースライン、設定、または結果について別々に質問している場合は、個別に回答してください。

回答の作成または大幅な再構成を行う際は、response-patterns.md を読んでください。

すべての段落を査読者が追いやすいものにする

  • 段落の結論または役割を最初の文で示してください。
  • 必須の感謝の後に続く最初の実質的な文で、新しい情報を伝えてください。We directly addressed the concern that... のような中身のないつなぎの書き出しや、対応や回答を伴わないコメントの言い換えは削除してください。
  • 論理的なつながりを明示してください。結果がコメントへの回答となる理由を査読者に推測させないでください。
  • 査読者が問題にしている実験単位または統計単位に合わせてください。回答で査読者と同じ言葉を使っていても、隣接する別の対象を検証しているのであれば不十分です。
  • 実験結果と、そこから導かれる解釈を区別してください。
  • 1段落につき主要な主張はひとつにしてください。
  • 直接的でなじみのある科学用語を使ってください。新たに作った名称、抽象的な表現、不要な transparent、定型的な称賛は避けてください。
  • 必ず最初の文で査読者に感謝してください。ただし、We agree that... を定型的に使わないでください。感謝することは、コメントのあらゆる前提に同意することを意味しません。
  • 原文の文体で明らかに好まれている場合を除き、em ダッシュは避けてください。
  • 書き換えの際も、関連する文献、図、表、Supplementary Note の引用を残してください。
  • 埋め込み図や表を挿入する前に、それがどの疑問に答えるのかを示す文を置いてください。

繰り返しと防御的な表現を抑える

  • 全体的な回答は概要に、対象ごとの結果は対応するセクションに、原稿の変更点は最後に記載します。同じ要点を、対応リスト、各サブセクション、独立した結論セクション、締めくくりの段落で繰り返さないでください。
  • 概要と直前の結果を言い換えているだけなら、独立した要約セクションは削除します。
  • 根拠のある結論の後に、However, this does not prove... のような定型的な留保を付け加えないでください。
  • 境界条件を含めるのは、査読者から明示的に求められている場合、記載しないと主張が不正確になる場合、または研究デザインにより過剰解釈の重大なリスクが生じる場合に限ります。
  • 必要な境界条件は、それが補足する具体的な主張のすぐ近くに置きます。防御的な締めくくりの段落にしないでください。
  • 実施していない分析について推測で述べるのではなく、根拠のある回答と具体的な修正点で締めくくります。

主張を根拠に合わせて調整する

以下の根拠の段階に従います。

  1. 直接観察: 示した、より高かった、障害が残った。
  2. 実行単位の再現性: 評価対象の実行間で再現された。
  3. 関連性: 関連していた、と整合する。
  4. 診断または介入: 整合する根拠を示す、考えられる説明を支持する。
  5. 因果の帰属: デザインによって要因が切り分けられ、妥当な代替説明が統制されている場合に限って用います。

以下の、繰り返し適用する境界ルールに従います。

  • 診断分析はメカニズムを支持する根拠となることはありますが、そのメカニズムを証明することはほとんどありません。
  • 複数のランダムシードは、学習のばらつきを特徴づけます。これらは自動的に独立した生物学的サンプルになるわけではなく、母集団レベルの推論の根拠にもなりません。
  • 意味のある優位性を検出できなかったからといって、統計的な同一性や同等性が立証されたことにはなりません。
  • 有限のハイパーパラメーター探索で特定できるのは「評価した比率のうち最も良好なもの」であり、全体的な「最適値」ではありません。
  • 最大パス深度を一定に保っても、パラメーター共有や実効容量が一定に保たれるわけではありません。
  • データセット固有の結果には、データセット名を明記します。根拠が主張する範囲を実際に網羅していない限り、「一貫して」「普遍的に」「デフォルトの選択肢」や、広範な優位性を主張する表現は避けます。
  • 平均 ± 標準偏差 は実行間のばらつきを示すものであり、信頼区間とは呼びません。
  • 実用上の効果の大きさ、確率的な安定性、統計的不確実性、データセット間の一貫性を区別します。
  • ドメインシフトの要因が交絡したままの場合、分散の完全な分解や因果的な分解ではなく、設定ごとの相関要因または妥当な説明を報告します。
  • 損失の重みが名目上同じでも、勾配への影響が同じとは限りません。
  • 撹乱テストが示すのは、その介入下での感受性または依存性です。これを自動的に、効果的な情報交換と呼ばないでください。

その区別が主張にとって重要な場合は、何を統制し、何が必然的に変化したのかを両方示します。必要な限界は明記しつつ、考え得るあらゆる代替説明を自動的に前面に出さないでください。

回答書、論文原稿、SI の整合性を保つ

実質的な主張ごとに、次の点を確認します。

  • 数値、単位、指標名、シード数、データセット、分割、比較対象、集計方法が正確である。
  • 論文原稿に、約束した修正が反映されている。
  • 回答書で詳しく説明した分析を裏付けるのに十分な方法論の詳細が SI に記載されている。
  • 図、表、注、パネルの番号が存在し、実際の内容と一致している。
  • 引用した修正後の文章が、文書の記載と一字一句一致している。
  • 用語が概要、詳細な回答、論文原稿、SI、キャプションを通じて統一されている。
  • 回答書が、修正後の論文原稿の記述を超えて一般化していない。
  • 埋め込まれた図はすべて、掲載前に本文で紹介され、意味のある参照箇所が示されている。
  • 図、表、注が参照されずに残っておらず、引用が存在しないパネルや誤ったパネルを指していない。
  • 修正箇所の記述では、それぞれの箇所で何を変更したかを明記している。たとえば、結果では知見を報告し、方法では分析を説明し、考察では解釈を見直します。
  • 概要、任意の対応リスト、セクション見出し、詳細な根拠、最後の修正内容の段落で、同じ一対一の対応関係が保たれている。
回答書に伴う論文原稿の修正

主張するのは回答書であり、論文原稿ではありません。査読者への回答に伴う論文原稿の修正には、anti-defensive-writing のルールゼロが適用されます。

  • 修正内容は、結果、厳密な定義、より明確な研究デザインの説明、または限定された主張です。安心させるための文、論文が何を主張していないかについての文、回答書の論拠を言い換えた文を追加してはいけません。
  • 限界を論文原稿に記載するのは、それが報告結果の意味を定める場合に限ります。その場合も、考察の最後の適用範囲に関する段落か、その限界が作用する方法の説明文に、肯定的な形で一度だけ記載します。
  • 査読者を納得させるための論拠は回答書に残します。「[残る要因]を切り分けることはできませんでした」のように回答書向けに調整した表現を論文原稿に貼り付けてはいけません。論文原稿では、何を一定に保ち、何を変化させたかを記載します。
  • 回答書で引用する前に、修正したすべての箇所について anti-defensive-writing の検出パスを実行します。

回答書全体または投稿準備状況のレビューには、final-audit.md を使用してください。

指定された出力形式に合わせる

コメントを分析する

判定から始めます。すでに十分な点、根拠が不足している点、変更が必要な点を示します。次に、回答の組み立て方を提案します。依頼がない限り、回答全文は作成しません。

回答を作成または修正する

まず簡潔な分析を示し、その後にそのまま使用できる文章をすべて提示します。文または段落一つだけを求められた場合は、短い分析の後にその部分だけを返します。依頼がそのまま転用できる文章の作成のみであり、その機能が利用できる場合は、ライティングブロックを使用します。

回答書を監査する

指摘事項を次のように分けます。

  1. 必須の修正: 事実誤認、根拠のない主張、矛盾、約束した修正の欠落、誤った引用やパネル、プレースホルダー、重複した文章、投稿に支障をきたすレイアウト上の問題。
  2. 強く推奨: 査読者の懸念を軽減するための、重要な明確化や適用範囲の改善。
  3. 任意: 文体上の調整のみ。

必須の修正だけを求められた場合は、カテゴリー 1 のみを報告し、該当するものがない場合はその旨を明記します。

有用な否定的結果を残す

不都合な分析を隠したり、過度に修正したりしないでください。正確に言い換えます。

  • 分析がどの不確実性または仮説を扱うのかを説明します。
  • 結果を誇張せずに報告します。
  • どの結論が弱められる、または限定されるのかを示します。
  • 残される実用上の意味を明らかにします。
  • 失敗が無関係性の証明になると主張しないでください。

目指すのは、すべてを肯定的に見せることではなく、信頼できる修正記録を作ることです。

コメント