godfetch

godfetch

統合された外部リサーチ — 1つのスキルから、ライブラリのドキュメントを調べ、任意の Git リポジトリ内のソースコードを検索し、パッケージのバージョンを確認できます。

ルーティング

意図	主なツール	フォールバック
ライブラリのドキュメント、API リファレンス	llms-probe → WebFetch llms.txt	llms.txt が公開されていない場合は context7
変更履歴、破壊的変更	llms-probe → WebFetch llms.txt	CHANGELOG.md の場合は gh api contents
リポジトリ横断のコード検索（正確な識別子）	Sourcegraph MCP keyword_search	gh search code、続いて追加調査に git-clone
GitHub ホストの依存関係に関する意味・概念検索（「ライブラリ Y で X はどう動作しますか」）	mcp__plugin_ora_morph__github_codebase_search	質問が複数ファイルにまたがって分岐し続ける場合は git-clone
複数ホスト、または GitLab／Bitbucket のリポジトリを横断する概念検索	抽出した 2～5 個のキーワードを使った Sourcegraph MCP nls_search	リテラルな用語を選んでから keyword_search
既知のリポジトリを詳しく調査（3 ファイル以上）	git-clone + シェルツール	単発の読み取りには Sourcegraph read_file
GitHub のイシュー	gh issue view <N>	イシューの検索には gh search issues
GitHub の PR	gh pr view <N>	PR の検索には gh search prs
GitHub のリリース（バージョン、日付、リリースノート）	gh release view <tag> --repo owner/repo	一覧表示には gh release list --repo owner/repo
単一ファイル（既知のリポジトリとパス）	Sourcegraph MCP read_file	gh api repos/.../contents/<path>（GitHub のみ）
シンボルのナビゲーション（定義、参照）	Sourcegraph go_to_definition / find_references	git-clone + ast-grep
リポジトリ横断の Git 履歴／差分検索	Sourcegraph commit_search / diff_search / compare_revisions	gh api /repos/.../commits
パッケージのバージョン、非推奨情報	deps-dev	npm のメタデータのみの場合は npm view
npm パッケージ情報（バージョン以外）	npm view <pkg> (Bash)	コミュニティの評判には WebSearch
一般的な Web 検索	WebSearch → WebFetch	—
比較／意思決定	ライブラリごとに llms-probe + WebSearch	追加の抜粋には context7

複数の内容を含むリクエストでは、関連するツールをすべて並行して実行します。プローブとクローンは I/O 待ちが発生するため、バックグラウンドで開始し、待ち時間を抑えるために WebFetch／context7／WebSearch を同時に実行してください。

GitHub アクセスルール

github.com または raw.githubusercontent.com の URL には WebFetch を使わず、適切なツールを使ってください。

GitHub のコンテンツ	使用するもの	使用しないもの
ソースコード（調査）	git-clone + シェルツール	gh api contents でファイルを閲覧する
ソースファイル（パスが既知の場合）	gh api repos/.../contents/<path>	WebFetch raw.githubusercontent.com
Issue	gh issue view <N> --repo owner/repo	WebFetch github.com/.../issues/N
プルリクエスト	gh pr view <N> --repo owner/repo	WebFetch github.com/.../pull/N
Issue／プルリクエストの検索	gh search issues "q" --repo ...	WebFetch github.com/issues?q=...
リリース（バージョン、日付、ノート）	gh release view/list --repo owner/repo または gh api repos/.../releases	WebFetch github.com/.../releases — HTML 上の相対タイムスタンプが、学習時期の年に誤って変換されることがあります
CHANGELOG.md	gh api repos/.../contents/CHANGELOG.md	WebFetch blob/ または raw URL

検索時のルール

• バージョン確認には deps-dev：最新バージョン、非推奨化、インストール済みバージョンと最新バージョンの比較を行う場合は、必ず最初に deps-dev を使ってください。deps-dev でエラーが発生した場合、またはパッケージがプライベートの場合に限り、npm view または WebSearch に切り替えてください。
• まず llms.txt、context7 はその後：ライブラリのドキュメントを参照する場合は、context7 を使う前に、ドキュメントのドメインに対して scripts/llms-probe.sh を実行してください。作者が公開する llms.txt は、コミュニティによる編集の遅れや情報の拡張レイヤーがなく、幻覚が混入しないため、公開済みドキュメントを正確に反映しています。プローブで何も見つからない場合にのみ、context7 に切り替えてください。

llms.txt — 作者が公開する正式なライブラリドキュメント

多くのドキュメントサイトでは、llms.txt（ドキュメントページの URL をまとめた Markdown インデックス）と llms-full.txt（全コンテンツを連結したもの）が公開されています。これらは作者自身が公開するものであり、情報の拡張レイヤーやコミュニティによる編集の遅れがないため、デプロイ済みのドキュメントのバージョンを正確に反映しています。利用できる場合は、context7 よりもこちらを優先してください。

ステップ 1：利用可能か確認する

bash scripts/llms-probe.sh <docs-domain>

見つかったファイルについて、kind \t url \t size 形式の TSV を出力します。ルートと一般的なネストされたパス（/docs/、/en/）を調べ、リダイレクトをたどり、重複を除外します。何も見つからない場合は、ゼロ以外の終了コードを返します。

kind	意味
index	llms.txt — ドキュメントページの URL をまとめた Markdown リスト
full	llms-full.txt — ドキュメント全体を連結したもの

CDN が Content-Length と Content-Range の両方のヘッダーを削除すると、サイズは ? と表示されます（react.dev では Vercel がこのように処理します）。? は不明なサイズとして扱い、インデックスのパスを優先してください。

Step 2: 現状に応じて取得する

見つかったもの	対応
llms-full.txt が約 500 KB 以下	WebFetch で直接取得します。1 回のラウンドトリップでコーパス全体を取得できます
llms-full.txt が約 500 KB 超、またはサイズが不明	まず WebFetch で llms.txt を取得し、関連するセクションのリンクを選んで取得します
インデックスのみ（full なし）	WebFetch でインデックスを取得し、次に個別ページのリンクを取得します
プローブに失敗	context7（次のセクション）にフォールバックします

複数のセクションを取得する場合は、ページに対する WebFetch 呼び出しを並列で実行します。

公開が確認されている提供元

公開を確認済み（2026 年 4 月）：React（react.dev）、Next.js（nextjs.org、コンテンツは /docs/ 配下）、Vercel、Anthropic（docs.anthropic.com → platform.claude.com）、Cloudflare（docs.cloudflare.com → developers.cloudflare.com）、Supabase、Drizzle（orm.drizzle.team）、Hono（hono.dev）、Zod（zod.dev）、Expo（docs.expo.dev）、tRPC（trpc.io）、shadcn/ui（ui.shadcn.com）。Mintlify および GitBook でホストされているドキュメントの多くは、自動的に公開されます。

Tailwind、1.0 より前のライブラリの大半、および多くのコミュニティ製パッケージは公開していません。その場合は直接 context7 を使用します。

ルール

• 決めつける前にプローブします。 導入状況にはばらつきがあり、パスも異なります（ルート、/docs/、リダイレクトなど）。必ず llms-probe.sh を実行して TSV に基づいて対応し、URL をハードコードしないでください。
• full を取得する前にファイルサイズを確認します。 Cloudflare の llms-full.txt は約 46 MB、Supabase は ?（チャンク分割）を報告します。どちらも無条件に取得するとコンテキストウィンドウを超過します。500 KB のしきい値は目安です。残りのコンテキスト予算に応じて調整してください。
• 大規模なコーパスではインデックスからページへたどります。 llms.txt をルーティングテーブルとして扱います。セクションの見出しを解析し、質問に一致するページ URL のみを取得してください。

context7 — ライブラリドキュメント（フォールバック）

llms-probe.sh が何も返さない場合、つまりライブラリが llms.txt を公開していない場合や、ドキュメントのドメインに到達できない場合は、context7 を使用します。コミュニティがキュレーションしたインデックスを通じて約 33K のライブラリをカバーしていますが、公開元が作成した llms.txt では避けられる、不正確な情報を含む可能性のある補完レイヤーが加わるというトレードオフがあります。

公式の ctx7 CLI を使った 2 ステップのワークフローです。最初に一度だけ bunx ctx7@latest login を実行する必要があります（API キーの環境変数は不要です）。

Step 1: ライブラリ ID を解決する

bunx ctx7@latest library <name> [query]

Context7 ID（例：/websites/react_dev）、信頼度スコア、スニペット数とともに、ライブラリ候補を一覧表示します。省略可能な [query] を指定すると、関連度に基づいて結果を再ランク付けします。トピックがすでに分かっている場合は、常に指定してください。機械可読な出力にするには --json を追加します。

Step 2: ドキュメントを取得する

bunx ctx7@latest docs <libraryId> "<query>"

関連度順にランク付けされた Markdown スニペットを返します。構造化出力にするには --json を追加します。最初の回答が浅い場合やトピックから外れている場合は、--research を付けて再試行します。サンドボックス化されたエージェントがソースリポジトリを読み込み、ライブウェブ検索を実行しますが、コストは高くなります。

ルール：

• 初回のみセットアップします：bunx ctx7@latest login（対話式）。bunx ctx7@latest whoami で確認してください。
• 必ず最初にライブラリ ID を解決してください。ID を推測することはできません。
• 具体的なクエリを記述してください。「hooks」より「オブジェクトでの useState フック」のほうが適しています。クエリは両方のコマンドで関連度のランク付けに使われます。
• --research はデフォルトではなく、通常の回答が不十分だった場合の再試行としてのみ使用してください。処理に時間がかかり、コストも高くなります。

リファレンス：references/context7.md

Sourcegraph — リポジトリ横断検索とコードナビゲーション（MCP）

Sourcegraph のパブリックインスタンスは、https://sourcegraph.com/.api/mcp で HTTP MCP サーバーを公開しており、リポジトリ横断検索、コードナビゲーション、Git 履歴のための 13 以上のツールを提供しています。ora プラグインの .mcp.json で設定されており、ツールは Clio で自動的に利用できます。

GitHub、GitLab、Bitbucket にまたがる 200 万以上の OSS リポジトリをインデックス化しています。リポジトリ横断クエリはサブ秒で実行され、ローカルクローンのオーバーヘッドもありません。

目的別のツール：

意図	ツール
完全一致する識別子で検索（AND）	keyword_search — リテラル一致。すべての語句が必須です。フィルター：repo:、file:、lang:、rev:
概念で検索／語彙が不明	nls_search — OR ロジック＋語幹処理（handler で handle も一致します）。意味的な埋め込みではありません
単一ファイルを読み取る	read_file — 上限 128KB。repo、path、任意指定の revision／startLine／endLine
ディレクトリを一覧表示	list_files
リポジトリを検索	list_repos
シンボルをたどる	go_to_definition、find_references
Git の履歴／差分	commit_search、diff_search、compare_revisions
コントリビューターを検索	get_contributor_repos
コードベースを AI で統合・分析	deepsearch — 負荷が大きく、サブエージェントを起動します

ルール：

• わかっている内容に応じて keyword_search と nls_search を選びます。 具体的な識別子（関数名／クラス名／定数名、エラー文字列、リテラルの語句）なら keyword_search。語彙が不明／概念的な検索（「X はどのように動作するか」、ライブラリ間に共通するパターン）なら nls_search。理由：keyword_search は AND ＋リテラル一致のため、語句が 1 つでも欠けると結果はゼロになります。nls_search は OR ＋語幹処理のため、広く検索できますが、ランキングのノイズが増えます。
• nls_search の前にキーワードを抽出します。 疑問詞（how、what、where、does、is）や冠詞を取り除きます。文全体ではなく、意味のある名詞／動詞を 2～5 語渡します。例：「how does the router match incoming requests」→ router match request handler。理由：ツールは各語を語幹処理して OR 検索するため、自然言語のつなぎ言葉がシグナルを弱めます。
• repo:^...$ アンカーで範囲を絞り込み、フォークへの一致を避けます。 repo:foo/bar は foo/bar-fork にも一致しますが、repo:^github\.com/foo/bar$ は一致しません。
• パターン：検索 → パスを確認 → read_file。 検索結果に repo@revision（例：github.com/foo/bar@abc123）と注記されている場合は、分割して repo と revision を別々に read_file に渡します。revision を省略すると、デフォルトブランチの HEAD が通知なしに読み取られ、異なる内容が返される場合があります。
• 独立した検索は並列化します。 比較対象のリポジトリが 3 つある場合は、3 回の keyword_search／nls_search 呼び出しを順番にではなく、1 つのメッセージで実行します。
• 探索と調査を使い分けます。 「…するリポジトリを探す」場合は keyword_search／nls_search、1 つのリポジトリ内の 5 つ以上のファイルにわたる処理の流れを追う場合は git-clone を使います。
• インデックスの遅延 — 直近約 24 時間以内に公開されたコードは、インデックスに登録されていない場合があります。リリース直後のバージョンについては、git-clone --refresh に切り替えてください。
• リポジトリがインデックス未登録の場合はフォールバックします。 read_file が null のリポジトリを返した場合は、git-clone または gh api contents に切り替えてください。
• deepsearch は負荷が大きいです。 AI サブエージェントを起動します。keyword_search と read_file では回答をまとめられず、かつ対象が複数のリポジトリまたは GitHub 以外のホストにまたがる場合に限って使用してください。GitHub のみを対象とする統合には、同じ用途に特化した、より軽量な mcp__plugin_ora_morph__github_codebase_search を代わりに使ってください。
• プランの注意点 — Sourcegraph のドキュメントによると、MCP アクセスは Enterprise プランに含まれます。公開されている sourcegraph.com MCP エンドポイントの無料プランでの動作は未検証です。最初のツール呼び出しで 401／403 が返された場合は、git-clone に切り替えてください。

参考資料：Sourcegraph MCP のドキュメント

Morph github_codebase_search — GitHub でホストされているセマンティッククエリのデフォルト

mcp__plugin_ora_morph__github_codebase_search は、Morph の WarpGrep サブエージェントを対象の公開 GitHub リポジトリに対して実行し、ファイルと行番号の引用を含む統合された回答を返します。まずこれを試してください。「ライブラリ X は Y をどのように実装しているか」「パッケージ Z はケース W をどこで処理しているか」「リポジトリ R の機能 V におけるデータフローはどうなっているか」といった質問では、Morph の呼び出し 1 回で、クローンしてから grep し、読み込むという一連の作業を置き換えられます。

• 次の場合に使用します： 対象リポジトリが GitHub にあり、質問が概念的・意味的なもの（「どのように」「どこで」「X と Y は何によって接続されているか」）である場合。理由：Morph は、呼び出し元が通常順番に行うファイルごとの grep、読み込み、統合を並列化します。
• 次の場合は Sourcegraph を優先します： GitLab／Bitbucket のリポジトリ、複数リポジトリにまたがる横断検索、フィルター付きの完全一致識別子クエリ（repo:、lang:、rev:）、Git の履歴や差分。
• 次の場合は git-clone を優先します： 同じリポジトリ内で 3 ファイル以上を追加で調査する場合、ast-grep による構造検索、または質問が次々に分岐する場合（「次はこれがどこで呼び出されているかを見せて。今度はそのテストを見せて」など）。
• 引用を信頼し、結論を検証してください — Morph の file:line 参照は対象リポジトリ内の実在する場所を指しますが、統合された説明（そのコードが 何をするか、質問にどう答えるか）は誤っていることがあります。回答が重要な根拠となる場合は、gh api repos/.../contents/<path> または git-clone と Read で抜き取り確認してください。

git-clone — ソースコードの調査

公開 Git リポジトリを浅いクローンとしてローカルキャッシュに保存し、シェルツールで作業ツリーを調査します。キャッシュは ~/.cache/clio-repos/ に保存され、セッション間で再利用されます。

bash scripts/git-clone.sh <repo> [--branch X] [--refresh]

スクリプトはキャッシュされたクローンの絶対パスを出力します。同じリポジトリへの次回以降の呼び出しでは、キャッシュされたパスがすぐに返されます（再クローンは行われません）。

リポジトリ引数の形式：

• owner/repo — GitHub のショートカット（例：vercel/next.js）
• 完全な HTTPS URL — どのホストでも使用できます（https://gitlab.com/...、https://gitlab.jmango360.com/... など）
• SSH 形式 — git@host:path（SSH キーの設定が必要です）

並列化： クローンは I/O 待ちが中心です（小規模・中規模のリポジトリで 1～3 秒）。ドキュメントとソースコードの両方が必要なトピックを調査する場合は、クローンと llms-probe／context7／WebSearch を並行して実行してください。ドキュメントが返る頃には、クローンの調査準備が整っています。

ルール：

• スクリプトのソースコードは読まないでください。使い方を確認するには --help を指定して実行します。
• デフォルトのキャッシュは ~/.cache/clio-repos/ です。必要に応じて --cache-dir で変更します。
• キャッシュは再利用されます。最新のコミットが必要な場合に限り --refresh を指定してください。
• 正確なパスがわかっているファイルを 1 つだけ取得する場合は、クローンのオーバーヘッドがない gh api repos/.../contents/<path> を優先します。

deps-dev — パッケージのバージョン

公開レジストリから最新の安定版を照会します。API キーは不要です。

python3 scripts/get-versions.py <system> <pkg1> [pkg2] ...

対応するエコシステム：

エコシステム	システム ID	例
npm	npm	express、@types/node
PyPI	pypi	requests、django
Go	go	github.com/gin-gonic/gin
Cargo	cargo	serde、tokio
Maven	maven	org.springframework:spring-core
NuGet	nuget	Newtonsoft.Json
RubyGems	rubygems	rails、sidekiq

出力：package、version、published、status の列を含む TSV。

ルール：

• スクリプトのソースコードは読まないでください。そのまま実行するか、--help を使用します。
• 可能な場合は、1 回の呼び出しで複数のパッケージ名を渡してまとめて照会してください。
• 非推奨のパッケージにはフラグを立ててください。ステータスが deprecated の場合は、代替案を提案します。

参照：references/deps-dev.md