research について
researchは、外部情報を調査し、出典付きの知見をspecのワークフローに渡すスキルです。ライブラリ、API、バージョン、既存パターンに関する疑問を、推測を事実として扱わずに解決します。
主な機能
- 01不明点を具体的な質問に整理
- 02一次情報を優先して根拠を収集
- 03出典付きで知見を要約
- 04未検証の主張や矛盾を明示
- 05知見をspecスキルに引き継ぐ
活用シーン
- 01不確かなAPIや依存関係の挙動を確認
- 02仕様策定で挙がった分野の疑問を調査
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/researchを入力して読み込まれたか確認します。
詳細
research — 外部知識 → §R
すべての調査結果には出典を記載します。出典がなければ ? を付け、推測を事実として書いてはいけません。
「ライブラリのコンテキストなしで処理すると、整理された幻覚が生まれます。」 Build がもっともらしくも誤った API をでっち上げ、§B に回避できるバグが入り込みます。 Research は外部の判断基準です。実際の事実を一度調べ、簡潔に記録し、再導出しないようにします。
調査するタイミング
- §C／§I／§V の判断が、自信のないライブラリ、API、バージョン、パターンに左右される場合。
- 外部依存の挙動を決めつけようとしている場合。
- そのアイデアが、先行事例のある分野（認証、決済、暗号、レート制限）に関わる場合。
/grillが、外部に確認すべき?を保留にしている場合。
Build が、すでに自分で書いたコードだけに関わるなら調査は不要です。調査は未知のことに使い、慣れた作業には ⊥ を使います。
4 つのステップ
1. 範囲を定める
未知のことを、具体的な質問 1〜3 件にします。漠然とした「認証を調査する」ではなく、「Node ESM 用の JWT ライブラリで、メンテナンスされているものは？」＋「リフレッシュトークンのローテーションにおける、現在のベストプラクティスは？」のようにします。 範囲を定めた質問なら出典付きの回答が得られます。漠然とした質問では、長い説明になってしまいます。
2. 情報を集める
ウェブ検索／ドキュメント用ツールを使います。一次情報を優先します。公式ドキュメント、リポジトリ、RFC、論文などです。独立した情報源 2 件のほうが、自信満々なブログ 1 件より確実です。広範囲に調べる場合はサブエージェントを起動し、生のページがこのコンテキストに入らないようにします。返すのは、要約した調査結果と出典だけです。
3. 要点をまとめる
各回答を、出典付きの簡潔な 1 行にまとめます。説明文は省きます。記憶として残すのは §R の行であり、読んだタブではありません。
R3|リフレッシュトークン|使用時にローテーションし、再利用を検出したらファミリーを無効化する|datatracker.ietf.org/doc/html/rfc6819#section-5.2.2.3
4. 引き継ぐ
§R の行を出力し、spec スキルに渡して追記してもらいます。調査結果によって制約やインターフェースが変わる場合は、spec に §C／§I の編集も伝えます。Research は提案し、spec は記述します。
出典の取り扱い
- 各行に URL、リポジトリ、RFC、論文のいずれかを記載します。識別子／バージョンは原文どおりにします。
- 確認できなかった場合も行は記載しますが、調査結果に
?を付け、その旨を明記します。未確認の主張であることを正直に示すのは問題ありません。事実を装った主張は、将来の §B につながります。 - 情報源が食い違う場合は両方を記録し、どちらを選ぶかはユーザーに委ねます。⊥ 勝手に平均を取ってはいけません。
いつ終えるか
範囲を定めた各質問について、出典付きの §R 行（または正直な ?）があり、確認されていない前提に基づく build の判断が残っていなければ完了です。⊥ 定めた質問の範囲を超えて調査してはいけません。それは注意力を浪費するだけです。
境界
- ⊥ SPEC.md を書く。§R の行は spec に渡します。
- ⊥ 出典なしで調査結果を事実として書く。
- ⊥ 生のページをコンテキストや §R に貼り付ける。要点をまとめなければ、活用されません。
- ⊥ リポジトリ内で読めることを調査する。ローカルの事実 > ウェブ上の推測。