mcpField
P
paper-reviewer

paper-reviewer

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

paper-reviewer について

paper-reviewerは、査読報告と著者回答を作成する研究者向けのスキルです。報告の作成、指摘の整理、回答、草稿の評価を行い、原文の指摘と回答を一つずつ照合できる形にします。

主な機能

  1. 01report、inventory、reply、gradeの4モード
  2. 02査読コメントを実行可能な依頼に分割
  3. 03査読者の原文と順序を維持
  4. 04回答の網羅性と記載箇所を確認
  5. 05回答の明瞭さと長さを点検

活用シーン

  1. 01投稿前に想定される査読指摘を洗い出す
  2. 02査読報告を順序付きの依頼一覧にする
  3. 03各指摘に対応する回答を作成する
  4. 04回答書の漏れや冗長さを確認する

インストール

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

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

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

同梱ファイル

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

references/
comment_splitting.md
common_issues.md
reply_blocks.md
reporting_standards.md
review_checklist.md
scripts/
check_coverage.py

詳細

査読報告とそれに答える返信

2つの仕事に、1つの視点。査読報告を書くことと、それに回答することは、同じ能力を異なる側面から見たものです。質問に答えたことを証明できるのは、尋ねられた質問を再構成できる場合だけです。

始める前にモードを選んでください。

モード入力出力
report原稿査読報告、または査読者がどこを問題にするかの予測
inventory査読報告査読者自身の言葉と順序による、すべての依頼と副次的な依頼
reply査読報告と原稿依頼ごとの返信と、対応状況の監査
grade返信案忍耐のない査読者から返ってくる内容

ルール

査読報告は質問のリストです。返信は回答のリストです。査読者が自分の報告とあなたの返信書を並べてスクロールしながら確認できるよう、2つのリストを正確に対応させることが仕事です。

数を一致させる。識別子を一致させる。順序を一致させる。言葉を一致させる。重さに応じて深さを調整する。

対応関係は、要約で主張するのではなく、ページ上で確認できなければなりません。そこから3つの帰結が生まれ、このスキルのルールはすべてここから導かれます。

  1. 査読者のコメントを、返信の直前にそのまま再掲します。 言い換えたり、要約したり、削ったりしてはいけません。Nature Methodsは、査読者のコメントの言い換えを操作的な戦術として挙げており、Nature Chemistryは、著者に査読者の個々の指摘を列挙するよう求めています。
  2. 返信では査読者自身の言葉を使います。 相手が data leak と書いたなら、返信でも data leak と書きます。回答を読むために査読者が覚えなければならないような、別の用語、フレームワーク名、カテゴリ名を作ってはいけません。平易な言葉にするには、よりよい表現を考案するのではなく、相手の用語を補足します。
  3. 査読者は急いでいます。 Nature Neuroscienceはこれを keeping in mind that referees are busy と表現しています。最初の文で回答を伝えます。返信の長さは、論点を解決するための必要最小限にします。軽いコメントに過剰に回答することも、重いコメントへの回答が不十分であることと同じくらい欠点です。またNature Chemistryは、冗長なエッセイ調の文体は改訂稿を読みにくくすると、特に注意を促しています。

このスキルの対象外

  • **rebuttal-response**は何を言うかを決めます。各依頼に対する立場、証拠が裏付ける最も強い主張、否定的な結果への誠実な対応、返信書・原稿・Supplementary Informationの整合性を扱います。ここで項目を整理し、そこで草稿を作成し、忍耐のない査読者の視点で確認するために草稿をここへ戻してください。
  • **submission-audit**は、まだ査読を受けていない原稿に対して、査読者の視点から1回の不採択レビューを行います。投稿前に使用してください。このスキルは、事前に査読者の視点をシミュレーションし、実際の報告を受け取った後に対応するために使用します。
  • **stats-reporting-audit**は、統計的な内容、すなわち n の背後にある独立単位、反復、多重比較補正、図の凡例に記載する統計を扱います。依頼が統計に関する場合は、内容はそちらから、返信の形式だけはこちらから得てください。
  • **nature-portfolio-playbook**は、投稿先と論文種別の選択を扱います。このスキルでは投稿先が決まっているものとします。

モード report

各段階の基準、Nature Portfolioが実際に尋ねる査読者向け項目、報告の形式、一度に1つずつ回答できるコメントを書くためのルールについては、review_checklist.mdを読んでください。common_issues.mdには確認すべき項目がまとめられています。reporting_standards.mdでは、ガイドラインへの準拠と、ポートフォリオ全体に共通するReporting Summaryを扱っています。

モード inventory

comment_splitting.mdを読んでください。ルールを一行で言うと、次のとおりです。

査読者を納得させるために別の対応が必要になる箇所で分割します。

同じ対応で両方に答えられる場合に限り、二つの節を一つの依頼として扱います。判断基準は、この箇所だけを取り上げて、査読者が第2ラウンドで the authors did not do this と書けるかどうかです。

査読者が示した列挙項目、依頼を示す動詞、質問、欠陥を事実として述べる文、別個の対象、成果物の変更があれば、そこで分割します。小項目の前置きとなる導入文、別の言葉で言い直した依頼、依頼の根拠を示すだけの文は除きます。集合を指定した依頼は、台帳では要素ごとに一つの項目へ展開します。これにより、集合の一部だけが対応済みのまま見過ごされるのを防げます。回答書では、すべての要素に触れ、それぞれに何をしたか(変更不要だったものも含む)を説明するなら、複数の項目に対して一つの回答を共有してもかまいません。対象を一つも挙げない範囲だけの回答では、4つのパネルを修正したのか2つを修正したのか分かりません。

番号は査読者のものを使います。 番号を振り直したり、順序を変えたり、テーマ別にまとめ直したりしないでください。抜けもそのまま残します。査読者がパネル a) と c) にコメントし、b) を飛ばしていた場合、回答でも同じようにします。引用内の誤記もそのまま残します。査読者が番号を付けていない場合は、査読者の方式に見える番号を独自に付けないでください。段落の切れ目で分割し、R1-P1 のように著者が付けたことが明確なラベルを使い、それを自分たちで追加したことを一度説明してください。

結果は notes/review-ledger.md に記録します。これは作業用の資料であり、回答書には含めません。査読者が自分の指摘への回答を見つけるために表を参照する必要はなく、著者がコメントを採点した表を渡されるべきでもありません。

モード reply

reply_blocks.mdを読んでください。ブロックの形式は固定です。

[the referee's comment, verbatim, complete]

[answer sentence]

[evidence, if the band allows it]

[location]

ページ上での見え方は次のとおりです。査読者自身のラベル、査読者自身の順序、各指摘に一つずつ回答し、どの回答でも最初に結論を述べます。

## Reviewer #2

Reviewer #2 raised 5 numbered comments, 6 points under "Figures:", and 12 points under
"Minor comments:". Each is quoted below in your original order with its own reply.

### Fig. 2a
> a) y-axis legend (FoE) is missing.

Added. The y axis of Fig. 2a now reads "FoE (fraction of enriched features, higher is better)".
(Fig. 2a)

### Fig. 2c
> c) The used dataset is not mentioned in the figure legend. Is it BBBC022?

Yes, it is BBBC022. The legend now names it. (Fig. 2 legend)

### Fig. 2d
> d) Classification loss decrease makes MAP and FoE worse?

Yes, beyond epoch 40. Lower classification loss past that point reflects fitting plate-level batch
signal, which MAP and FoE penalise. (page 7; Supplementary Fig. 7b)

査読者が指摘していない二つのパネルにはブロックを作らず、その番号は空けたままにします。査読者が自分の報告書をスクロールすれば、自分の a)、c)、d) と、回答側の a)、c)、d) を照合できます。

二つの調整軸

科学的リスクに関する判断である深刻度によって、必要な作業量が決まります。回答の語数は、査読者自身の書きぶりに合わせます。

査読者の書きぶり上限
minor の見出しの下にある、または一つの修正を求める一文40語
番号付きの実質的なコメント120語
妥当性、対照、統計、または中心的な主張への異議300語

両者が食い違う場合は、必要な作業を行い、回答は短く保ちます。 一行の軽微なコメントとして寄せられた重大な問題であっても、実験をすべて行い、原稿を書き直します。修正は原稿に反映され、回答ではその箇所を示すため、回答は引き続き二文です。

平易な表現

最も重要なルールです。失敗例とその書き換えを含む14項目すべては、reply_blocks.mdにあります。

  1. 最初の文で回答し、コメントを読み返していない人が読んでも意味が通るようにします。
  2. 最初の文は25語未満とし、主節を一つにします。
  3. 最初の文では、査読者自身が使った名詞を使います。
  4. 査読者が名付けたものを別の名前で呼んではいけません。用語が曖昧でも、その語を主となる語として保ち、同じ文の中で修正を補足します。
  5. 査読者が使っていない用語には、初出時に6語以内の平易な説明を添えます。
  6. 謝意は節までとし、それだけで一文にしてはいけません。
  7. 数値にはすべて、値、単位または指標、良し悪しの方向、比較対象を含めます。
  8. 一文につき考えは一つとし、最大30語、婉曲表現は一つまでにします。また、文をまたいで前の文を指す代名詞を主語にしてはいけません。ダッシュは使いません。
  9. 伝えにくいことを先に述べ、As the referee correctly points out のような中身のない表現で書き始めてはいけません。
  10. どの回答も、場所を示すか、変更がなかったこととその理由を明示して終えます。
5つの回答

自分で使うための平易な説明であり、手紙の中でラベルとして現れることはありません。We did it は、過去形の行動とその結果です。We did a smaller version は、何を行い、何を行わなかったかを、その順で示します。It is already in the paper は、場所を先に示し、それから、それでも見つけられるようにする変更を示します。We disagree。We cannot do it は、拒否と具体的な理由を1文で示します。

うまくいかなくなるのは、意見の相違の場合です。立場ではなく事実を述べます。There is no data leak in these experiments とし、決して We respectfully disagree とはしません。前提を攻撃し、読者を攻撃してはいけません。査読者が正しいなら逆の結果になっていたはずの結果から、証拠を示し始めます。真実の割合は、それ専用の文で認めます。それでも原稿は変更します。その懸念は、それを許容する記述から生じたからです。その記述を防御的にするのではなく、正確にします(定義、より明確な設計の記述、限定された主張)。安心させる言葉と手紙の議論は、手紙の中にとどめます。

モード grade

  • 2行テスト。 査読者の要求を1行目に、あなたの最初の文をその下に置き、この2行だけを読みます。主動詞は一致しているか、それとも明示的に拒否されているか。相手が名指しした目的語は現れているか。あなたの最初の文は、改訂前からすでに真だったか。その論文を知らない読者が、2行目が1行目に答えているかどうかを言えないなら、その返答は失敗です。
  • 数のチェック。 要求は返答ブロックと同数です。すべての識別子は、順序どおりに、抜けを保って1回ずつ現れます。相手が名指ししたすべての図、パネル、表、行番号は、変更が不要なものも含めて、名前で現れます。どのブロックも、その回答全体が相互参照だけになっていてはいけません。すべてのブロックは、場所を示して終わります。
  • ハイライターチェック。 報告の各節を、それを決着させる文が見つかったら取り消し線で消します。取り消されていないものは、欠けている返答です。
  • 着地。 返答が約束する変更は、原稿の中に存在しなければなりません。手紙の中にしか存在しない返答は、再査読で最もよく見つかる失敗です。

機械的な半分については、チェッカーを実行します。逐語引用、順序、1要求につき1返答、場所、包括的な表現、冗長さです。

python3 ~/.agents/skills/paper-reviewer/scripts/check_coverage.py \
  --reviewer reviews/round1.txt --letter response/round1.md \
  [--ledger notes/review-ledger.md] [--manuscript manuscript.md] [--strict] [--json]
# Claude Code (global install): replace ~/.agents/skills with ~/.claude/skills
# Claude Code (project-local install): replace ~/.agents/skills with .claude/skills

それは、返答が要求に応えているかどうかを判断できません。クリーンな実行は、良い手紙であることを意味しません。

Nature Portfolio に関する注意

この節のすべての情報源は、review_checklist.md の末尾に記載されています。方針は変わるため、ジャーナルのページを確認してください。

  • 返答は公開されると想定してください。ただし、特定のジャーナルのページを確認し、そうでないと確認した場合を除きます。Nature は2025年6月以降、すべての新規研究投稿について査読者レポートと著者回答を公開しています。Nature Communications は2022年11月以降です。他のタイトルはさまざまで、オプトインによるものもあります。いずれにせよ、すべての査読者は、他のすべての査読者のレポートとあなたの反論を目にします。
  • 概要は、各査読者への返答の冒頭ではなく、編集者へのカバーレターに属します。 カバーレターは公開されず、査読者に見せるべきでない事柄を書く場所です。
  • 裁定するのは編集者です。 決定は投票ではありません。査読者が対立した場合は、それぞれを独自のブロックで回答し、対立を事実として一度述べ、編集者に解決させます。ある査読者を別の査読者に対して利用してはいけません。
  • 編集上の要件は、査読者のコメントではありません。 決定通知は、どの査読者も要求していない事柄を課すことがあります。それらには独自のブロックを設けます。
  • 査読者レポートの項目は、ポートフォリオ全体で異なり、レポートは記載された順序に従う必要はないため、受け取ったレポートに番号が振られていると決して想定しないでください。一部のジャーナルでは、コード評価のセクションが別に表示されるため、コードに関するコメントが主要な所見ブロックの外で届くことがあり、それでも独自の返答が必要です。

関連ファイル

ファイル開くタイミング
review_checklist.md査読報告書を作成するとき、または査読者が何を指摘するか予測するとき
comment_splitting.md受け取った報告書を項目一覧にまとめるとき、または改訂を重ねても引き継ぐとき
reply_blocks.md個々の回答を作成または評価するとき
common_issues.md方法論上または統計上の問題を指摘するとき、または受け取ったコメントを分類するとき
reporting_standards.mdガイドライン、チェックリスト、または Reporting Summary が関係する場合
scripts/check_coverage.py送信前の機械的な網羅性監査に使用

出典:査読報告書に関する部分は inno-paper-reviewer を基にしています。回答の整合性を保つレイヤーはこのリポジトリ独自のもので、査読者への回答に関する Nature Portfolio の公開ガイダンスと、透明性のある査読ファイルを要約して作成しました。

コメント