mcpField
E
explore-sota

explore-sota

github.com/vincenzoimp生産性476 回インストール14 週間前に更新
リポジトリ

explore-sota について

Explore SOTAは、サーベイ研究や対象を絞った文献拡張のために、研究最前線の論文を体系的に探すスキルです。候補キュー、引用追跡、偏りの点検を反復し、定めた停止条件まで進めます。

主な機能

  1. 01研究範囲と停止条件の設定
  2. 02学術MCPによる候補論文検索
  3. 03引用・参考文献の追跡
  4. 04候補の重複排除と出典・判定の記録
  5. 05採択論文をダイジェスト工程へ送る

活用シーン

  1. 01サーベイ用の候補論文群を構築・拡張
  2. 02既存論文から引用の手掛かりを追跡
  3. 03予算または文献の飽和を基準に探索を終了

MCP 対応

学術MCPを使って論文と引用関係を検索し、arxivとsemantic-scholar、dblp、openalexのうち少なくとも1つが応答する必要があります。機能の事前確認を通過しない場合、探索を停止します。

インストール

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

$npx skills add https://github.com/vincenzoimp/academic-research-skills --skill explore-sota

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

同梱ファイルreferences/citation-chasing.md

詳細

SOTA を探索する

SOTA 探索ループを実行します。候補論文を見つけ、sota/queue.md でトリアージし、採択した論文を要約して、宣言した停止条件を満たすまで繰り返します。長時間の自律セッションにも、小規模で対象を絞った拡張にも対応します。

最初に読むもの

  • sota/README.md — 要約のルールと形式
  • sota/queue.md — Scope ブロックと現在のフロンティア
  • references/citation-chasing.md — フロンティアの管理、エコーチェンバー防止ルール、レビュー規模

MCP の事前確認(必須ゲート)

digest-paper と同じゲートです。API キーではなく、機能に基づいて判定します。arxiv が応答し、さらに semantic-scholar、dblp、openalex のうち少なくとも 1 つが応答する必要があります。ゲートを満たしていない場合は、停止して報告します。キーがない場合は利用が制限されるだけです。アクセス可能なソースがダウンしている場合は相互検証の精度が低下しますが、停止条件にはなりません。モデルの記憶やウェブスクレイピングで代用してはいけません。

手順

  1. 範囲。 sota/queue.md の先頭にある Scope ブロックを読みます。空欄または古くなっている場合は、今すぐ記入します。研究課題、キーワード/同義語/関連用語、採択基準と除外基準、レビュー規模(quick-scan は約 8~15 件/focused-sota は約 20~40 件/full-survey は 50 件以上)、停止条件を記録します。対話セッションではユーザーに確認し、自律セッションでは README.md から導き出して検索前に記録します。
  2. シード。 多様なシードの組み合わせを作成します。ユーザーが挙げた論文、すでに要約した論文、MCP 検索で見つけた重要な先行研究、最新のフロンティア論文を含めます。単一の著者グループ、投稿先、またはサーベイ論文から始めてはいけません。
  3. 検索。 設定されているすべての学術系 MCP でキーワード検索を実行します。常時利用可能な arxiv、semantic-scholar、dblp、論文検索アグリゲーターに加え、有効な場合は openalex も対象です。短く、関連性の高いクエリを使い、有効だった用語を Scope ブロックに記録します。
  4. 追跡。 要約済みの各シードについて、references/citation-chasing.md に従い、一度に 1 ホップずつ semantic-scholar で参照先と被引用論文を取得します。
  5. 重複排除。 候補をキューに追加する前に、sota/index.md に存在せず、sota/queue.md にもまだないことを確認します(一致判定は DOI、arXiv ID、S2 ID、タイトル+筆頭著者+年の順で行います)。
  6. トリアージ。 新しい候補を出所情報(「found via」)とともに queue.md に追加し、基準に照らして accepted、rejected: <reason>、または pending と判定します。MCP で解決できない候補には unresolvable-via-mcp を付け、引用してはいけません。
  7. 要約。 accepted の候補ごとに、digest-paper スキルの手順を実行します(すべてを実行するか、何も実行しないかのいずれかです)。新たな要約から新しい引用候補が見つかったら、キューに追加します。
  8. 学習。 要約ラウンドごとに、新たに得た用語、ベンチマーク、投稿先、著者グループを範囲の用語に追加して、再検索します。
  9. 停止。 飽和を宣言する前に、references/citation-chasing.md に記載されたエコーチェンバー防止チェックを実施します。飽和した場合(1 ホップで重複または範囲外の研究が大半を占める場合)、または宣言した予算に達した場合は停止します。後者の場合、未展開のフロンティアは pending の行として記録し、決して黙って残してはいけません。
  10. セッションを終了する前に make check を実行し、トリアージされていない行が残っていない状態にします。

ルール

  • すべての候補は、要約の判断を行う前に queue.md に登録します。フロンティアを記録する場所はキューのみです。
  • 却下する場合は、必ず除外基準に結びついた理由を記載します。
  • 被引用数とグラフの中心性は論文を見つけるための手がかりであり、関連性や品質を判断する基準ではありません。
  • 論文数の予算に合わせるために候補を水増ししてはいけません。規模の目安は予算であり、目標ではありません。

完了条件

  • pending の行が残っていない、または未展開のフロンティアが明示的に記録され、ユーザーに報告されている
  • Scope ブロックに最終的な基準と飽和/予算の結果が反映されている
  • make check が成功する

コメント