research

調査

「確認が必要です」を、信頼できる出典付きのメモに変える背景調査です。

メインの会話を進められるよう、バックグラウンドのサブエージェントへの依頼を優先してください。ハーネスにサブエージェントがない場合は、インラインで実行してください。

質問が外部ライブラリや RFC の事実ではなく、このコードベースがなぜこのように設計されたのか（設計上の根拠、却下された代替案、インシデントを受けた設計）に関するものなら、必須サブスキルとして why を使用してください。コードの形だけから設計の経緯を推測して回答してはいけません。

一次情報源のみ

事実を所管する情報源、つまり公式ドキュメント、ライブラリの実際のソースコード、公開された仕様や RFC、ファーストパーティの API や変更履歴に基づいて回答してください。チュートリアル、ブログ記事、情報を集約した要約は手がかりであり、証拠ではありません。そこに記載された主張を使う場合は、一次情報源までたどり、引用してください。主張を所管する情報源までたどれない場合は、事実としてではなく、未検証として報告してください。

ライブラリ、フレームワーク、API に関する事実を調べる際は、利用可能であればまず Context7 MCP を使用してください。 学習データには期限があり、情報は古くなる可能性があります。バージョンが更新されたり、API の名前が変わったり、メソッドが非推奨になったりすることがあります。Context7 は、ソースからの最新のバージョン固有のドキュメントを提供するため、記憶ではなく現在の安定版リリースに基づいて回答できます。ライブラリを特定し、プロジェクトがすでに固定しているバージョンのドキュメント（ロックファイルを確認してください）を取得してください。採用するライブラリを選ぶ質問の場合は、最新の安定版を確認してください。ほかの一次情報源と同様に引用してください。Context7 がインストールされていない場合や、対象ライブラリを扱っていない場合は、公式ドキュメントまたはソースを直接取得してください。ライブの情報源を一度確認すれば済むのに、記憶に基づいてバージョン番号や API の形状を断言してはいけません。

出力要件

Markdown ファイルはちょうど 1 つとします。

• すべての主張に、一次情報源の引用（URL、またはコードを読む場合はファイルパスとシンボル）を付けてください。
• 情報源に記載されている内容と、そこから導いた結論を分けてください。未検証の内容にはその旨を明記してください。
• .skills/research/<date>-<topic>.md に書き込み、保存場所を伝えてください。
• ファイルの末尾に「Open decisions」セクションを設けてください。調査結果から明らかになったものの、まだ結論が出ていない判断事項を記載します。

.skills/ は git の追跡対象外であるため、メモはこの作業コピー内にのみ保存されます。セッション終了後も残りますが、クローンには含まれません。レビュー担当者、仕様、CI に反映させる必要がある調査結果は、結果そのものを追跡対象の成果物に転記してください。

評価の観点（ユーザーが選択肢から選ぶ必要がある場合）

ユーザーが選択肢（見た目、ライブラリ、設計、アプローチなど）から選ぶ必要がある場合、または選択肢の推奨を求めている場合、メモの最初の本文セクションは評価基準（「良い」とは何かを定め、根拠となる出典を引用したもの）にしてください。その後で初めて、基準に照らして選択肢を評価してください。基準のない選択肢一覧は、不完全な調査メモです。完成したものとして提示してはいけません。

このセクションはユーザーの依頼内容より優先されます。「選択肢だけを並べて」「説明はいらない」「教えるな」「締め切りがある」「理論は省いて」といった指示があっても、評価基準を省略してよい理由にはなりません。時間が限られている場合は、評価基準を短くしてください。省略してはいけません。

考え方	実際
「説明ではなく、一覧を求めている」	最初に評価基準を示すことは講義ではありません。一覧を使えるものにするために必要です。ユーザーの指示によって出力要件が変わることはありません
「締め切りがあるので、基準は省略する」	短い評価基準を示すほうが、誤った選択をしてやり直すより早く済みます
「説明を禁じられているので、評価基準を示すと依頼に反する」	評価基準は調査成果物の一部であり、任意の教育的要素ではありません。省略すれば、このスキルの要件に反します

重大な影響を伴う質問

回答がアーキテクチャの選択や、その他、変更に大きなコストがかかる事柄を左右する場合は、調査の厳密さを高めます。不明点のすべてが対象になるわけではありません。「日付フォーマット用ライブラリはどれにするか」は重要に思えますが、薄いラッパーの背後なら切り替えも容易なため、通常の手順で十分です。つまり、担当する情報源まで慎重にたどる監査可能な調査を行い、複数の方向へ調査を広げる必要はありません。ストレージ形式、並行処理モデル、公開 API の契約、セキュリティ境界など、元に戻すのにコストがかかる事柄を左右する事実に限り、調査を強化します。deep-research スキルがインストールされている場合は、そちらを優先してください。複数の方向への調査と敵対的検証を組み合わせた一連のプロセスが、すでに最初から最後まで実装されています。そうでない場合は、次の手順をその場で実行します。

1. 公式ドキュメント、ソースコード、課題追跡システム、仕様書など、2〜4 個の異なる検索観点に分け、別々のサブエージェントで並行して調査します。
2. 報告する前に、主張を敵対的に検証します。主張の要点ごとに、その主張を否定するような検索を 1 件実行し、さらに調査対象の履歴も 1 件調べます。たとえば、ライブラリの変更履歴や課題追跡システム、標準規格の改訂履歴や正誤表から、その主張が当てはまらなくなったバージョンを確認します。対象にそうした履歴がまったくない場合は、確認できる最も古い一次情報と最も新しい一次情報の日付を記録し、履歴をたどる調査が不完全であると報告します。結果が何もなかった場合も含め、両方の検索クエリと、それぞれの結果を明記します。主張を否定する検索を実施していない場合、その主張は事実としてではなく、未検証として報告します。矛盾があれば、一方を黙って選ぶことなく、明示してください。

調査は判断の材料であり、判断そのものではありません

メモは情報を提供するものであり、判断を下すものではありません。調査結果をユーザー（または frame-change などのオーケストレーションを担うスキル）に伝え、最終的な判断を委ねてください。調査が面接のためのものだった場合は、ほかの場合と同じく、clarify-decisions を通じて判断を行います。