find-docs

name	find-docs
description	ライブラリ・フレームワーク・SDK・API・CLI ツール・クラウドサービス (React, Next.js, Prisma, Express, Tailwind, Django, Spring Boot 等の著名なものを含む) について質問された際に、Context7 CLI で最新の公式ドキュメントを取得してから回答する。 API 構文・設定方法・バージョン移行・ライブラリ固有のデバッグ・セットアップ手順・CLI ツールの使用方法が対象。ライブラリのドキュメントに関しては Web 検索よりこちらを優先する。 リファクタリング・ゼロからのスクリプト作成・ビジネスロジックのデバッグ・コードレビュー・一般的なプログラミング概念の質問には使わない。

技術調査 (ライブラリドキュメント取得)

ライブラリ、フレームワーク、SDK、API、CLI ツール、またはクラウドサービスについて質問された際は、Context7 CLI (コマンドは ctx7、後述のとおり npm:ctx7@latest 経由で実行する) を使用して最新のドキュメントを取得する。

たとえ答えを知っていると思われる場合でも、学習データには最新の変更が反映されていない可能性があるため、この手順を優先する。API のシグネチャ・設定オプション・バージョン依存の挙動は特に陳腐化しやすいので、学習データに頼らず現行ドキュメントで裏取りする。ライブラリのドキュメントに関しては、Web 検索よりもこちらを優先して使用する。

適用する場合 / 適用しない場合

判定軸は「対象がライブラリかどうか」ではなく「質問の意図がライブラリ・フレームワーク・SDK・API・CLI の最新仕様や使い方を問うているか」。

• 適用する: API 構文・設定方法・バージョン移行・ライブラリ固有のデバッグ・セットアップ手順・CLI ツールの使用方法を問う質問。
• 適用しない: リファクタリング、ゼロからのスクリプト作成、ビジネスロジックのデバッグ、コードレビュー、一般的なプログラミング概念の質問。対象コードがライブラリを import していても、意図が上記なら起動しない。

実行手順

ライブラリ名を ID に解決してから、その ID でドキュメントを引く 2 段階。

Step 1: ライブラリの特定

次の library コマンドで、パッケージ・プロダクト名を Context7 互換のライブラリ ID に解決し、候補一覧を得る。

deno run --no-lock --allow-env --allow-sys=osRelease,homedir --allow-read --allow-net=context7.com,registry.npmjs.org npm:ctx7@latest library <name> "<user's question>"

<name> が複数語の場合はクォートで囲む (例: library "Spring Boot" "...")。

query 引数は必須で、結果のランキングに直接影響する。ユーザの質問全文をクエリに使う。同名のライブラリが複数ある場合の曖昧性解消にも効く。

出力フィールド

各候補は以下を含む。選択基準 (後述) はこれらの値を見て判断する。

• Library ID — Context7 互換の識別子 (形式: /org/project)。
• Name — ライブラリ・パッケージ名。
• Description — 短い概要。
• Code Snippets — 利用可能なコード例の数。
• Source Reputation — ソースの信頼性 (High/Medium/Low/Unknown)。
• Benchmark Score — 品質指標 (100 が最高)。
• Versions — バージョン一覧 (存在する場合)。バージョン指定がある場合はここから選ぶ。形式は /org/project/version。このフィールドが無い候補の扱いは「バージョン指定」の節に従う。

選択基準

最適なライブラリ ID を次の優先順位で決定する。上位で差がつかない場合のみ下位で tie-break する。

1. 正式名称の一致 (完全一致を優先)。
2. ソースの信頼性 (High/Medium を推奨)。
3. ベンチマークスコア (高いほど良い、最高 100)。
4. Description の関連性。全候補が汎用的な説明文で質問への関連度に差が読み取れない場合は同点として次へ進む。
5. Code Snippets の数 (多いほど良い)。

ID の種別 (公式リポジトリ系 /org/project、ドキュメントサイト系 /websites/... 等) は判断材料にせず、上記 (1) から (5) で機械的に決める。「公式リポジトリを選びたい」といった直感で順位を覆さないこと。選択基準で上位が複数並ぶ場合は、その旨を述べた上で最上位の 1 つで進める。どの候補も選択基準を満たさない場合は、その旨を伝えてクエリの見直しを提案する。

数値指標 (ベンチマークスコア等) での比較は、差がごく僅か (差 2.0 以下、境界を含む) なら同点とみなし、次の基準で tie-break する。この閾値は厳密な分岐条件ではなく「僅差を決定打に昇格させない」ための目安であり、境界ぎりぎりの判定で結論を反転させない (迷ったら同点側に倒して次の基準へ進む)。

(1) の正式名称の一致は、ユーザの意図に照らして判定する。フレームワーク本体の組み込み機能を問うているのか、特定のサードパーティライブラリを名指ししているのかを見る。質問キーワードがサードパーティライブラリに強く一致しても、ユーザがフレームワーク本体の機能を問うているならフレームワーク本体を選ぶ。

選択結果が直感 (「公式リポジトリを選びたい」等) に反する場合や、上位が僅差だった場合は、その ID を選んだ理由を回答に 1 行添える (例: 選択基準 (1) から (3) で上回るため)。

Step 2: ドキュメントの取得

選択したライブラリ ID で、最新のドキュメントとコード例を取得する。

deno run --no-lock --allow-env --allow-sys=osRelease,homedir --allow-read --allow-net=context7.com,registry.npmjs.org npm:ctx7@latest docs <libraryId> "<user's question>"

docs のクエリは library と同一文である必要はない。初回から対象の API 名・機能語 (例: @@unique) を加えて絞ってよい。

取得結果には 2 種類の内容が含まれうる。両方あれば両方を見る。

• コードスニペット — タイトル付きで、言語タグ付きのコードブロック。
• info スニペット — パンくず文脈付きの散文による解説。

クエリによっては片方 (コードスニペットのみ等) しか返らない。その場合はある方だけで判断してよい。

取得したドキュメントに基づいて回答する。

クエリの書き方

クエリの質が結果の質を直接左右する。具体的かつ詳細に書く。曖昧な単語 1 つでは一般的すぎる結果しか返らない。

クエリはドキュメントの主要言語 (多くは英語) で書き、ユーザの質問の意図を表現する。ユーザが日本語など他言語で質問した場合は、意図と具体性を保ったまま英語に翻訳してクエリにする。「質問全文を使う」とは原文の言語をそのまま使う意味ではなく、語句の具体性を削らないという意味。

良し悪し	例
良い	"How to set up authentication with JWT in Express.js"
良い	"React useEffect cleanup function with async operations"
悪い	"auth"
悪い	"hooks"

バージョン指定

バージョン固有のドキュメントは、ユーザが特定バージョンを明示した場合、またはバージョン依存の挙動を問うている場合にのみ使う。その際は library コマンドの出力 (Versions フィールド) から、そのバージョンを指す ID を使う。ID の形式は問わない (/org/project/version 形式の例は /vercel/next.js/v14.3.0、バージョン別のドキュメントサイト系の例は /websites/v3_xxx)。

そのバージョンを指す ID が無い場合は、当該バージョンが現行であれば通常の ID (バージョンなしの ID やドキュメントサイト系の ID) を代替として使ってよい。指定がなければバージョンなしの ID を使う。Versions フィールドが無くても、候補の Name や ID 文字列にバージョン記号 (v3、v2 等) を含むものがあれば、それを当該バージョンを指す ID とみなす。

差分や移行を問う質問で「現行」側を選ぶ際、どの候補にも明示的なバージョン記号が無ければ、最上位の通常 ID を現行とみなし、その前提 (現行がどのバージョンか) を回答に明示する。候補の Description が対象バージョンへの対応を示していれば、それを優先する。現行が具体的にどのバージョンかは、学習データではなく取得したドキュメント本文のバージョン記載で確認する。

2 つのバージョン間の差分や複数ライブラリの比較を問う質問では、新しい方 (現行) を通常 ID で取得することを主とする。旧バージョンの取得は、現行側のアップグレードガイド等に旧仕様が併記されているかをまず確認し、併記で差分を把握できれば省く。併記が無く差分の把握に旧仕様が必要な場合のみ、旧バージョンを指す ID (形式は問わない) から実行上限内で追加取得する。

エラー処理

コマンドがクォータエラー (Monthly quota reached/quota exceeded 等) で失敗した場合は、Context7 のクォータを使い切っており、これ以上はドキュメントを取得できない旨をユーザに伝える。

取得できなかった場合に学習データから回答してはならない。Context7 のドキュメントに基づかない API 仕様・設定値の回答は、注記を添えても返さないこと。取得不可の事実だけを伝え、回答は保留する。

注意事項

• MUST: クエリに機密情報 (API キー、パスワード、認証情報、個人データ、proprietary なコード) を含めないこと。
• ユーザから /org/project 形式で直接 ID が提供されない限り、必ず最初に library コマンドを実行して有効な ID を取得すること。
• deno の権限は --allow-net で通信先を、--allow-sys でシステム情報アクセスを絞り、外部への露出を抑える方針。--allow-env と --allow-read は ctx7 が読む対象が多く、read のパスも deno キャッシュ位置に依存して壊れやすいため絞らない。--allow-write は不要。ctx7 の更新で Requires sys access to "X" 等が出たら、その権限を該当フラグに追記する。
• ライブラリ ID は / 始まり。/facebook/react であって facebook/react ではない。
• 質問内容は、「nextjs」ではなく「Next.js」、「customerio」ではなく「Customer.io」、「threejs」ではなく「Three.js」など、正しい句読点を用いた公式のライブラリ名を使用すること。
• CLI ツールやコマンドについて問われた場合、library のクエリ名にはツール単体の名前ではなく、それが属するプラットフォーム・プロダクトの正式名称を優先する (例:「Wrangler」より「Cloudflare Workers」、「gcloud」より「Google Cloud」)。ツール名で関連性の低い結果しか出ない場合はプラットフォーム名で引き直す。
• 1 つの質問につき 3 回を超えてコマンドを実行しないこと。これはハード上限であり、library の引き直しや docs の再取得もこの回数に含まれる。上限内で核心に到達できるよう、初回 library のクエリ名を正確に選ぶこと。
• docs の取得結果が質問の核心 (主要なユースケースや対象 API) を直接カバーしていない場合は、上記の実行上限内で観点を絞ったクエリ (機能名やメソッド名を加える等) で再取得してよい。
• 残りの実行回数の使途が複数 (旧バージョンの追加取得・核心の絞り込み再取得等) で競合する場合は、質問の核心 (新しい側の新仕様や対象 API) を厚くする取得を、旧側の補完取得より優先する。
• ドキュメントソースは既定で pre-release・canary チャネルを指すことがある (例: /vercel/next.js)。取得したドキュメントが canary・開発版由来で、用語や API 名が安定版の広く知られた仕様と食い違う場合は、その差異を回答で明示し、どのバージョンの話かを添える。開発版の名称を現行の標準であるかのように提示しないこと。