mcpField
L
litreview

litreview

github.com/alirezarezvani生産性28.9k418 回インストール2 日前に更新
リポジトリ

litreview について

Litreviewは、なじみのない学術分野を調べる研究者向けに、文献検索を始めるための案内資料を作成します。PubMedとOpenAlexで検索し、利用可能な場合はConsensus MCPも追加できます。

主な機能

  1. 01PubMedとOpenAlexで論文を検索
  2. 02任意でConsensus MCPを利用
  3. 03研究課題に応じた分析フレームワーク選択
  4. 04検索・重複排除・引用数の追跡
  5. 05構造化された文献案内の作成

活用シーン

  1. 01未知の分野に入る際のテーマ整理
  2. 02臨床課題のPICO検索の構成
  3. 03技術研究の手法・評価・限界の比較
  4. 04複数回の検索における引用と結果の追跡

MCP 対応

Consensus MCPは任意の検索経路として、利用可能な場合に無料検索を補完し、結果を統合・重複排除します。標準の検索にはMCPは不要です。

インストール

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

$npx skills add https://github.com/alirezarezvani/claude-skills --skill litreview

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

同梱ファイル

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

references/
docx_8_sections.md
framework_selection.md
search_budget_allocation.md
scripts/
citation_tracker.py
cross_search_aggregator.py
framework_recommender.py
free_search.py

詳細

Litreview — 学術文献の方向づけ

移植性: 外部への HTTPS 通信が可能な環境であれば、どこでも動作します。デフォルトの検索経路は無料のキー不要 API(PubMed E-utilities と OpenAlex。アカウント、キー、MCP は不要)です。Consensus MCP は任意の拡張経路で、このセッションで接続されている場合にのみ使用します。ドキュメント生成には docx パッケージを含む Node.js が必要であり、CLI では bash_tool も必要です。Claude Code CLI でネイティブに動作し、Code Execution を使えば Claude.ai でも動作します。

出発点となる資料を作成します。完成した文献レビューではなく、なじみのない分野に足を踏み入れる研究者が、自信を持って読み始め、検索を始めるために必要な情報をすべてまとめた方向づけのドキュメントです。その分野に詳しい親切な同僚が、コーヒーを飲みながら教えてくれるような内容を考えてください。

検索経路

経路使用する場面方法
無料経路(デフォルト)いつでも利用可能。キー、プラン、MCP は不要scripts/free_search.py または直接 HTTPS(以下の URL テンプレート)で PubMed E-utilities と OpenAlex を利用
Consensus 経路(任意の拡張)このセッションで Consensus MCP ツールが利用できる場合に限る合成された回答カードを得るため、無料経路に加えて Consensus クエリを実行

経路の確認(実行時に一度だけ確認。すべてのプラン判定に代わるものです): このセッションで Consensus MCP ツールが利用できない場合は、無料経路を使用してください。プラン判定を試みないでください。マーケティング文面を解析したり、Consensus のプランについてユーザーに尋ねたりしないでください。Consensus が利用できる場合は、追加で検索を実行し、結果を統合してください(DOI/タイトルで重複を除去します)。

無料経路の URL テンプレート(正確な形式)

PubMed E-utilities(キー不要。利用上の配慮として、リクエストは毎秒 3 件以下にしてください):

  1. 検索 → PMID:https://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi?db=pubmed&term=<urlencoded-query>&retmode=json&retmax=20&sort=relevance — esearchresult.idlist(PMID)と esearchresult.count を読み取ります。
  2. PMID → メタデータ:https://eutils.ncbi.nlm.nih.gov/entrez/eutils/esummary.fcgi?db=pubmed&id=<pmid1,pmid2,...>&retmode=json — result[<pmid>] ごとに、title、authors[].name、pubdate、fulljournalname、articleids[](idtype: "doi" の項目)を読み取ります。
  3. 発表年代による絞り込み:直近の文献には &datetype=pdat&mindate=2021&maxdate=3000、歴史的な文献には &maxdate=2015 を追加します。
  4. 論文 URL:https://pubmed.ncbi.nlm.nih.gov/<PMID>/。

OpenAlex(キー不要。丁寧な利用者向けプールを使うには &mailto=<email> を追加します。応答が速く、信頼性も高まります):

  1. 検索:https://api.openalex.org/works?search=<urlencoded-query>&per-page=20&mailto=<email> — results[] ごとに、display_name(タイトル)、publication_year、cited_by_count、doi、id(OpenAlex の URL)、authorships[].author.display_name、primary_location.source.display_name(掲載先)を読み取ります。
  2. 発表年代による絞り込み:&filter=from_publication_date:2021-01-01 または &filter=to_publication_date:2015-12-31。
  3. レビュー論文:&filter=type:review。

OpenAlex の cited_by_count は、検索横断のインテリジェンス層における引用数の情報源です(PubMed esummary は引用数を返しません)。

エージェントの完全性ルール(Research-Pack 規約)

research-pack 規約を継承しています。PR #657 のスキル間一貫性監査に基づき、文言をそのまま固定しています。

  • 出典の規律。 THIS セッションの検索(free lane および/または Consensus)で取得した論文のみを引用します。学習済み知識には [Not from search — model knowledge] のラベルを付け、引用数から除外します。検索結果が少ない場合は明示し、黙って補完することはありません。
  • 件数の規律。 次の 3 つの数を記録します。実行した検索数/受け取った固有の論文数(DOI/タイトルで重複を除外)/引用した論文数。引用する論文にはすべて、このセッションで取得可能な URL(PubMed、DOI、OpenAlex、または Consensus)が必要です。件数を決定論的に集計するには scripts/citation_tracker.py を使用します。
  • レート制限のマナー。 PubMed E-utilities:API キーなしの場合、毎秒 3 リクエスト以下。OpenAlex:mailto を利用したポライトプール。Consensus(接続されている場合):毎秒 1 クエリ、逐次実行必須。既定の規律:すべてのレーンで逐次実行、毎秒 1 クエリ。
  • 再試行ポリシー。 失敗した場合 → 3 秒待機 → 1 回だけ再試行 → 記録。3 回連続で失敗したら停止し、ユーザーに通知して、収集済みの内容を共有します。
  • レーンの確認。 セッション開始時に一度だけ、Consensus MCP ツールが利用可能かどうかを確認します。ティアの検出は一切行いません。

逐次実行の根拠と予算上限については、references/search_budget_allocation.md を参照してください。

エラー処理

失敗動作
いずれかのレーンでレート制限/HTTP エラー3 秒待機し、1 回だけ再試行して結果を記録
検索結果が 0 件「専門的な用語であるか、実際に研究の空白がある」と明記します。黙って補完することはありません
ネットワークが利用できない(free lane が終了コード 2 で終了)停止してユーザーに通知します — free lane にはアウトバウンド HTTPS が必要です。検出やアップグレードで解決できる問題ではありません
3 回連続で失敗検索を停止し、ユーザーに通知して、収集済みの内容を共有し、今後の進め方を尋ねます
サブ領域の検索結果が少ない(論文 5 件未満)監査で指摘し、Google Scholar/Scopus での手動補足を提案します
ユーザーがサブ領域の調整を希望表を更新し、検索前に再確認します
DOCX の検証に失敗XML を展開して修正し、再パッケージします

フェーズ 0:グリル形式のインテーク(回答を求める質問 3 つ、1 つずつ)

各質問には、質問する理由を明記します。停止条件:フェーズ 1 に進む前に最大 3 つまで質問します。

Q1(根幹)— 研究課題の具体性

研究課題を 1~2 文で述べてください。具体的であるほどよいです。「医学における AI」より、「臨床推論課題において、LLM は医師と比べてどのような性能を示すか」のほうが適切です。曖昧な質問からは、曖昧なレビューしか生まれません。

質問する理由: 予備調査では、正確な用語が重要になります。曖昧な質問では予備調査の結果が乏しくなり、役立つフレームワークの分類につながりません。

曖昧な回答は受け付けません。 ユーザーの質問が広すぎる場合は、例を示して 1 回だけ再質問します。それでも曖昧な場合は、「詳細なレビューではなく、広い範囲の概観」であることを明記して提供します。

Q2(Q1 に依存)— フレームワークのヒント

フレームワークを選ぶか、「おまかせ」と答えてください:

  1. PICO(Population/Intervention/Comparison/Outcome — 臨床的な質問で最も一般的)
  2. SPIDER(Sample/Phenomenon/Design/Evaluation/Research-type — 社会科学/質的研究向け)
  3. 分解(問題/解決策/評価/限界 — テクノロジーに重点を置く場合)
  4. ハイブリッド(複数のフレームワークから使う要素を選択)
  5. おまかせ — Q1 を分析して提案

質問する理由: PICO は臨床的な質問の約 70% で既定のフレームワークですが、質的研究やテクノロジー評価には適合しにくい場合があります。事前に選択しておくことで、予備調査で不適切なフレームワークが提案されるのを防げます。

既定の選択肢(「おまかせ」)を提示して、必ず選んでもらいます。このスキルは予備調査の後、自身のフレームワークの推奨案を示すため、ユーザーは変更できます。ヒューリスティックには scripts/framework_recommender.py を使用します。

PICO/SPIDER/分解の基準については、references/framework_selection.md を参照してください。

Q3(Q1 に依存)— 仮の深さ

仮の深さ — いずれかを選んでください。最終確認はフレームワークの内訳を確認した後に行います:

  1. クイックスキャン(5 件の検索)
  2. 標準レビュー(10 件の検索)
  3. 詳細調査(20 件の検索)

質問する理由: この質問は 2 回行います。最初は調査検索の重点を調整するために今、もう一度はフレームワークの内訳を確認した後に最終確認するためです。仮の回答によって、最初に取り上げるサブエリアが変わります。最終回答によって、検索予算の配分が決まります。

選択を必須とします。ユーザーがフレームワークの内訳を確認した後、Phase 2 後のチェックポイントで再度質問します。

停止条件: Phase 1 の前に行う質問は最大 3 件です。Phase 2 後のチェックポイントは、それ自体がユーザーに選択を求める場面です(フレームワーク表+サブエリアの調整+深さの再確認)。

Phase 1:初期調査

テーマ、用語、方法論上の違いを把握するために、広範な調査検索を 1 件実行します。

  • レーンの確認を実行します(Consensus が利用可能かどうか)。その後:
    • 無料レーン:python scripts/free_search.py --query "<broad version of Q1>" --source both --max 20(または前述の esearch/works URL テンプレート)
    • Consensus が利用可能な場合は、追加で広範な Consensus 検索を 1 件実行し、統合します
  • クエリ:Q1 の広範な表現(用語のバリエーションも可。最初の検索は広く網羅します)
  • 記録:citation_tracker.py --action record_search --session NAME --query "..."
  • 取得件数を記録:citation_tracker.py --action record_papers_received --session NAME --count N

チェックポイントに向けて以下をまとめます:

  • 明らかになったテーマ
  • 用語のバリエーション(例:「LLM」、「large language model」、「GPT-style model」)
  • 方法論上の違い(臨床試験、ベンチマーク評価、ケーススタディなど)
  • 網羅性のギャップ(調査結果に含まれていない副次的な質問)

Phase 2:フレームワークの選択+サブエリアの作成

フレームワークを選択します(Q2 に基づくか、調査結果に応じて変更します):

  • PICO — 臨床に関する質問の大半(デフォルトで約 70%)
  • SPIDER — 社会的・定性的なテーマ
  • Decomposition — 技術に焦点を当てるテーマ(問題/解決策/評価/制限事項)
  • Hybrid — フレームワーク間の対応関係を明示

フレームワークの各要素に対応するサブエリアの質問を 4~5 件作成します。それぞれを Phase 3 の対象を絞った検索に使用します。

チェックポイント(ユーザーに選択を求める場面)

Phase 2 の後に処理を一時停止し、以下を提示します:

3~4 文の調査概要
  • 明らかになったテーマ
  • 用語の全体像
  • エビデンスの状況
フレームワークの内訳表
フレームワークの要素このトピックとの対応調査するサブエリアの提案
(要素 1)...サブエリア 1
(要素 2)...サブエリア 2
(要素 3)...サブエリア 3
(要素 4)...サブエリア 4
横断的なテーマ...サブエリア 5
深さの再確認(選択を必須とします)

実務上の制約として、使用中の検索レーン(無料/無料+Consensus)と、クエリごと・ソースごとの結果が約 20 件までであることを提示します。

  • クイックスキャン(検索 5 件 × 結果約 20 件=ソースごとに最大約 100 件の論文)
  • 標準レビュー(検索 10 件 × 約 20 件=ソースごとに約 200 件の論文)
  • 詳細調査(検索 20 件 × 約 20 件=ソースごとに約 400 件の論文)
サブエリアの選択肢
  • 「問題ありません — このサブエリアで進めてください」
  • 「調整:[X]に関するサブエリアを追加」
  • 「調整:[Y]を削除し、[Z]に置き換える」
  • 「別のフレームワークでやり直す」
質問する理由(根拠)

フレームワークやサブエリアの設定を誤ると、検索予算が無駄になります。これは方針を修正できる最後のコストが低いタイミングです。

Phase 3 を始める前に、ユーザーの回答を待ってください。 ユーザーが明示的に選択するまで、Phase 3 の開始を拒否します。

Phase 3:対象を絞った検索

検索は逐次実行します(1 クエリ/秒)。各深さの区分に応じた予算を使用します。すべての検索は無料レーン(free_search.py または URL テンプレート)で実行します。Consensus が利用可能な場合は、追加で同じクエリを使って Consensus でも検索し、統合します。詳細な基準については、references/search_budget_allocation.md を参照してください。

クイックスキャン(検索 5 件)
  • サブエリアごとに 1 件、計 5 件のサブエリア検索
  • 時代による制限のある検索とレビューに特化した検索は省略
標準レビュー(10件の検索)
  • 5件のサブエリア検索
  • 2件のレビュー論文検索(上位2つのサブエリア):「"systematic review [topic]"」/「"meta-analysis [topic]"」(OpenAlex:&filter=type:reviewを追加)
  • 2件の時代別検索(最重要のサブエリア):過去(PubMed &maxdate=2015/OpenAlex to_publication_date:2015-12-31)+最近(PubMed &mindate=2021/OpenAlex from_publication_date:2021-01-01)
  • 1件のフォローアップ検索:最も引用数の多い論文のキータームを使い、その出版年より後の日付を指定
詳細調査(20件の検索)
  • 5件のサブエリア検索
  • 5件のレビュー論文検索(サブエリアごとに1件)
  • 4件の時代別検索(上位2つのサブエリアについて、過去+最近をそれぞれ検索)
  • 引用数上位3論文のフォローアップ検索を3件
  • 新たな研究動向を調べるための予備検索を3件(追跡すべき意外な発見)

全体を通して、レート制限は1秒あたり1リクエストです。順番に実行してください。次の呼び出しの前にレスポンスを確認してください。各検索をcitation_tracker.pyで記録してください。

検索横断インテリジェンス

すべての検索結果を対象に、3種類のトラッカーを使います。フェーズ3の完了後にscripts/cross_search_aggregator.py --session NAMEを実行してください。

  1. 繰り返しヒットした論文 — 3件以上のサブエリア検索で同じ論文が見つかった場合、基礎的な重要文献である可能性が高いです
  2. 繰り返し登場する著者 — 複数の検索で同じ著者が見つかった場合、有力な研究グループです。頻度上位3〜5名が重要です
  3. 年間被引用数の目安 — 2023年の被引用数150件の論文は、2008年の被引用数150件の論文より大幅に重要です。基礎的な研究の特定には、OpenAlexのcited_by_countを使ってください。

これらの情報をDOCXの「まず読む文献」+「主要研究グループ」+「参考文献」セクションに反映します。

フェーズ4:DOCX研究ガイド

Node.jsとdocxライブラリを使って生成します。全8セクションです(詳しい仕様はreferences/docx_8_sections.mdを参照してください)。

  1. トピックの概要 — 要点を絞った段落を1つ(4〜6文)
  2. まず読む文献 — 優先読書順 — 論文を5〜7本、順番に掲載:最良の最新レビュー → 基礎的な研究 → 最前線の研究2〜3本 → ギャップ/論争。それぞれに、ハイパーリンク付きタイトル+著者/出版年+貢献を述べる1文+「注目点」を述べる1文を記載します
  3. 研究分野の変遷 — 年代順の解説(1〜2段落)+タイムライン表(5〜8件の節目:年/節目/重要性)+用語の変遷に関する注記
  4. サブエリア別ガイド(各サブエリアにつき、次の4項目)
    • 4a. 研究で明らかになっていること(インライン引用を含む2〜3文の統合的な要約)
    • 4b. 主要論文(引用数、出版年、重要性を述べる1文を添えた、ハイパーリンク付き論文3〜5本)
    • 4c. 主要な検索語(キーワード、同義語、MeSH、歴史的な用語を6〜10件)
    • 4d. ブール検索文字列(そのまま貼り付けて使える文字列を2〜3件)
  5. 主要研究グループ — 所属機関、対象とするサブエリア、代表論文へのリンクを添えて、著者/グループを上位3〜5件掲載(検索横断アグリゲーターの情報を使用)
  6. 未解決の疑問とギャップ — 方法論/対象集団・文脈/概念・理論の3カテゴリ。それぞれのギャップについて、なぜ重要かを説明します
  7. 参考文献 — 第一著者の姓のアルファベット順。各項目にクリック可能なリンクを付けます:PubMed URLまたはDOI(無料レーン)/「Consensusで表示」(Consensusから取得)。すべてのインライン引用を参考文献項目と対応させてください
  8. 監査ログ — 検索の概要表(番号、クエリ、フィルター、返された論文数、ステータス)、件数ブロック、使用した検索レーン(無料/無料+Consensus)を含むカバレッジ注記
DOCXの技術要件

docxライブラリの重要なパターンを記載してください。

  • ページ:US Letter、余白1インチ
  • リスト:LevelFormat.BULLET(Unicodeの箇条書き記号は使用しない)
  • ハイパーリンク:style: "Hyperlink"を指定したExternalHyperlinkを使い、URL全体を記載する(省略しない)
  • 表:幅の二重指定(columnWidths+セルのwidth)、ShadingType.CLEAR
  • 保存後の検証手順(zip整合性チェック:python3 -c "import zipfile,sys; zipfile.ZipFile(sys.argv[1]).testzip()" output.docx — 出力なしなら破損なし。その後、必須セクションが含まれていることを確認してください)

セットアップのパターンとベストプラクティスについては、docxスキルを参照してください。

出力

research_guide_<topic-slug>_<YYYY-MM-DD>.docx

加えて:

  • チャットの要約ブロック:「保存先:。監査:検索N件 × ユニークな論文M本/引用済みK本。検索レーン:<free | free+Consensus>。」
  • ユーザーから要求があった場合は、監査ログをインラインで表示します

ツール

スクリプト役割
scripts/free_search.py無料でキー不要の検索レーン — PubMed E-utilities と OpenAlex を標準ライブラリの urllib 経由で利用します(--query、`--source pubmed
scripts/citation_tracker.py~/.litreview_sessions/<session>.json に保存する JSON ベースの 3 件数監査
scripts/framework_recommender.py研究課題に基づく PICO/SPIDER/分解法のヒューリスティックな提案
scripts/cross_search_aggregator.pyフェーズ 3 後に、複数回ヒットした論文、頻出著者、年間被引用数を基に順位付けします

参考資料

避けるべきアンチパターン

  • 検索呼び出しを並列化する(どのレーンでも)
  • 対話形式のチェックポイントを省略する(ユーザーの確認なしにすべての検索を実行する)
  • 情報量の少ない検索結果を、学習済み知識で水増しする
  • 正当な理由なく、デフォルトで PICO 以外のフレームワークを選択する
  • このセッションでの検索結果に含まれていない論文を、チャットで引用する
  • Consensus のプラン階層を検出しようとする(削除済み — 実行時に確認するのは「このセッションで Consensus MCP ツールを利用できるか」だけです)
  • Consensus を必須として扱う(任意の拡張機能であり、無料レーンがデフォルトです)
  • 標準/詳細な検索予算で、対象年代を絞った検索を省略する
  • 複数検索のインテリジェンス(複数回ヒットした論文、頻出著者)を省略する
  • ハイパーリンク内のソース URL を途中で切り詰める

バージョン: 1.1.0 ソース仕様: megaprompts/09-litreview-megaprompt.md(メンテナー向けのローカル草案仕様 — gitignore 対象のため、公開リポジトリには含まれていません) ビルドパターン: パス B(直接変換)。pulse の姉妹プロジェクト(research-pack 形式)。v1.1.0:キー不要の無料 API(PubMed + OpenAlex)がデフォルトの検索レーンになり、Consensus は任意の拡張機能に変更され、2026-06 の newgen 監査と ClawHub ルール #3(有料サービスへの依存禁止)に従い、プラン階層の検出は削除されました。

コメント