study-repo

リポジトリを調査する

ファイル名から推測するのではなく、コードベースを読んで質問に答えてください。

プロセス

1. 質問を分類する

ユーザーが必要としている回答の種類を特定します。

• システム概要 — リポジトリが何をするもので、どのように構成されているか。
• 機能の追跡 — 特定の動作がどのように実装されているか。
• 使用方法の確認 — ユーザーが API、コマンド、パッケージ、コンポーネント、パターンを特定の方法で使用できるかどうか。
• 外部パッケージの動作 — 依存関係のドキュメントに記載された仕様、実装、バージョン、既知の制限が実際にどうなっているか。
• 変更の準備状況 — 変更を計画する前に何を理解しておく必要があるか。

分類に基づいて必要な根拠を選びます。範囲の説明に役立つ場合を除き、分類を明言する必要はありません。

2. 根拠を見つける

質問に答えられる最小限の主要な情報源を読みます。以下は選択肢であり、必須の読み進める順序ではありません。根拠が質問に答えた時点で調査を終え、現在のコンテキストを再利用します。

1. リポジトリレベルのドキュメントとパッケージ／設定ファイルで全体像を把握します。
2. 質問に関連するエントリーポイント、ルート、コマンド、公開エクスポート、テストを確認します。
3. 関連する関数、型、コンポーネント、モジュールの定義と呼び出し箇所を確認します。
4. 意図された動作を示す既存のテストや例を確認します。
5. 外部パッケージについては、インストール済み、または指定されたバージョンに関する公式ドキュメント、リリースノート、ソースコード、テスト、例、型定義を確認します。

意味に基づくナビゲーションと高速検索を優先します。ドキュメントは参考にしつつ、可能であればコードと照らし合わせて動作を検証します。

適切なツールが利用できる場合は、パッケージの検証に使用します。

• 公式ドキュメントの情報源を使って、ドキュメントに記載された API、設定、バージョンごとの動作を確認します。利用可能であれば、Context7 などを使用します。
• ソース検索またはパッケージのソースを使って、実装、テスト、例、型定義を調べます。利用可能であれば、Octocode や GitHub のソース検索などを使用します。
• ローカルプロジェクトでパッケージのバージョンが固定されている場合は、インストール済みのバージョンを優先します。固定されていない場合は、調査したバージョンまたはブランチを明記します。
• ドキュメントとソースの内容が食い違う場合は、矛盾を報告し、無理に整合させないでください。

3. 処理の流れを追う

機能に関する質問では、重要な状態変化、入出力、ドメイン上の判断が見えるまで、公開エントリーポイントから内部へ動作を追います。

使用方法に関する質問では、次の点を検証します。

• ユーザーが呼び出す公開インターフェース。
• 必要な入力、設定、順序、環境。
• エラーが発生する状況とサポートされないケース。
• 使用方法を裏付ける既存のテスト、例、ドキュメント。

4. 確実性のレベルを分ける

回答の正確さを保ちます。

• 事実 — コード、テスト、ドキュメント、コマンド出力によって直接裏付けられていること。
• 推論 — 構造や命名から導かれる可能性の高い結論。
• 不明点 — 利用可能な情報源からは証明できないこと。

推論を事実として提示しないでください。

出力

次の内容を含む簡潔な回答を返します。

• 要約 — まず直接的な回答を示します。
• 仕組み — リポジトリ内の重要な処理の流れを説明します。
• コード参照 — 回答を裏付けるファイルとシンボルを示します。
• 注意点 — サポートされていないケース、不明点、前提を示します。
• 次のステップ — コード変更が必要な場合は、/plan-it を推奨します。

完了条件

ユーザーが次の点を把握できたら、調査は完了です。

• 関連する動作がどこにあるか。
• 主な処理の流れ、API の仕様、またはパッケージの動作がどうなっているか。
• 回答を裏付ける根拠は何か。
• 不確かな点が残っている場合、それは何か。