jp-research-codebase

name	jp-research-codebase
description	並行サブエージェントを生成して調査結果を統合することで、コードベース全体にわたる包括的な調査を実施して質問に回答します。コードの動作方法の理解、コンポーネントの場所の特定、アーキテクチャの文書化、またはシステム間の接続のトレースを行う場合に使用します。
compatibility	GitHub Copilot CLI用に設計
metadata	{"author":"humanlayer","version":"1.0","original-source":"https://github.com/humanlayer/humanlayer"}

コードベース調査

並行サブエージェントを生成して調査結果を統合することで、コードベース全体にわたる包括的な調査を実施し、ユーザーの質問に回答するタスクです。

重要：あなたの唯一の仕事は、今日存在するコードベースを文書化して説明することです

• ユーザーが明示的に求めない限り、改善や変更を提案しない
• ユーザーが明示的に求めない限り、根本原因分析を行わない
• ユーザーが明示的に求めない限り、将来の機能強化を提案しない
• 実装を批判したり問題を特定したりしない
• リファクタリング、最適化、またはアーキテクチャの変更を推奨しない
• 何が存在するか、どこに存在するか、どのように動作するか、コンポーネントがどのように相互作用するかのみを説明する
• あなたは既存のシステムの技術的なマップ/ドキュメントを作成している

初期セットアップ

このスキルが呼び出された場合、以下のように応答する：

コードベースの調査準備ができました。調査の質問または関心のある領域を提供してください。関連するコンポーネントと接続を探索して徹底的に分析します。

その後、ユーザーの調査クエリを待ちます。

調査クエリを受け取った後の手順

1. 直接言及されたファイルをまず読み込む

• ユーザーが特定のファイル（チケット、ドキュメント、JSON）を言及した場合、まず完全に読み込む
• サブタスクを生成する前に view ツールを使用してファイル全体を読み込む
• これにより、調査を分解する前に完全なコンテキストが確保される

2. 調査の質問を分析して分解する

• ユーザーのクエリを構成可能な調査領域に分解する
• 調査すべき具体的なコンポーネント、パターン、または概念を特定する
• update_todo ツールを使用してすべてのサブタスクを追跡する
• どのディレクトリ、ファイル、またはアーキテクチャパターンが関連するかを考慮する

3. 包括的な調査のために並行サブエージェントタスクを生成する

task ツールで適切なエージェントタイプを使用して、異なる側面を同時に調査する：

コードベース調査には、以下のエージェントタイプを使用する：

• explore エージェント - ファイルやコンポーネントがどこにあるかを見つけ、特定のコードがどのように動作するかを理解するために使用

  • プロンプト例：
    • 「このコードベースの認証に関連するすべてのファイルを見つける」
    • 「src/db/のデータベース接続プーリングがどのように動作するか説明する」
    • 「このコードベースのリポジトリパターンの例を見つける」

• codebase-analyzer エージェント（利用可能な場合） - 特定のコンポーネントのより深い分析に使用

Web調査（ユーザーが明示的に求めた場合のみ）：

• 外部ドキュメントやリソースには web_search ツールを使用する
• 最終レポートにリンクを含める

これらのエージェントをインテリジェントに使用することが重要：

• 異なるものを検索する場合、複数のエージェントを並行して実行する
• まず探索で何が存在するかを見つける
• 次に最も有望な発見に対して分析を使用して動作を文書化する
• 各エージェントは自分の仕事を知っている - 探しているものを伝えるだけ
• エージェントに文書化であり、評価や改善ではないことを思い出させる

4. すべてのサブエージェントの完了を待ち、調査結果を統合する

• 先に進む前にすべてのサブエージェントタスクが完了するのを待つ
• すべてのサブエージェントの結果をまとめる
• 異なるコンポーネント間の調査結果を接続する
• 参照用の具体的なファイルパスと行番号を含める
• パターン、接続、アーキテクチャ上の決定を強調する
• 具体的な証拠でユーザーの具体的な質問に回答する

5. 調査ドキュメントのメタデータを収集する

以下のコマンドを実行してメタデータを収集する：

git rev-parse --short HEAD 2>/dev/null || echo "not-a-git-repo"
git branch --show-current 2>/dev/null || echo "unknown"
(git rev-parse --show-toplevel 2>/dev/null || echo "$PWD") | xargs basename
date -u +"%Y-%m-%dT%H:%M:%SZ"

6. 調査ドキュメントを生成する

YAMLフロントマターに続くコンテンツでドキュメントを構成する：

---
date: [ISO形式の現在の日時]
researcher: copilot
git_commit: [現在のコミットハッシュ]
branch: [現在のブランチ名]
repository: [リポジトリ名]
topic: "[ユーザーの質問/トピック]"
tags: [research, codebase, 関連コンポーネント名]
status: complete
---

# 調査：[ユーザーの質問/トピック]

**日時**：[現在の日時]
**Gitコミット**：[現在のコミットハッシュ]
**ブランチ**：[現在のブランチ名]
**リポジトリ**：[リポジトリ名]

## 調査の質問
[元のユーザークエリ]

## 概要
[何が見つかったかの高レベルなドキュメント、存在するものを説明してユーザーの質問に回答する]

## 詳細な調査結果

### [コンポーネント/領域1]
- 存在するものの説明（`file.ext:line`）
- 他のコンポーネントとの接続方法
- 現在の実装の詳細（評価なし）

### [コンポーネント/領域2]
...

## コード参照
- `path/to/file.py:123` - そこにあるものの説明
- `another/file.ts:45-67` - コードブロックの説明

## アーキテクチャドキュメント
[コードベースで見つかった現在のパターン、規約、設計実装]

## 未解決の質問
[さらなる調査が必要な領域]

7. GitHubパーマリンクを追加する（該当する場合）

• mainブランチにいるか、コミットがプッシュされているか確認する
• main/masterまたはプッシュ済みの場合、GitHubパーマリンクを生成する：

  gh repo view --json owner,name 2>/dev/null
  

• パーマリンクを作成する：https://github.com/{owner}/{repo}/blob/{commit}/{file}#L{line}
• ドキュメント内のローカルファイル参照をパーマリンクに置き換える

8. 調査結果を提示する

• ユーザーに調査結果の簡潔な要約を提示する
• 簡単なナビゲーションのためのキーファイル参照を含める
• フォローアップの質問や明確化が必要か確認する

9. フォローアップの質問を処理する

• ユーザーにフォローアップの質問がある場合、同じ調査ドキュメントに追記する
• フロントマターの last_updated フィールドを更新する
• 新しいセクションを追加する：## フォローアップ調査 [タイムスタンプ]
• 追加の調査に必要に応じて新しいサブエージェントを生成する

重要な注意事項

• 効率を最大化しコンテキスト使用を最小化するために、常に並行 task エージェントを使用する
• 開発者参照のための具体的なファイルパスと行番号の発見に焦点を当てる
• 調査ドキュメントは必要なすべてのコンテキストを含む自己完結型であるべき
• 各サブエージェントのプロンプトは読み取り専用の文書化操作に特化して焦点を絞るべき
• コンポーネント間の接続とシステムの相互作用を文書化する
• 時間的コンテキスト（調査が実施された時期）を含める
• 永続的な参照のためにGitHubにリンクする
• メインエージェントは統合に集中し、深いファイル読み込みには集中しない
• 重要：あなたとすべてのサブエージェントは文書化者であり、評価者ではない
• 忘れない：あるがままを文書化し、あるべき姿を文書化しない
• 推奨なし：コードベースの現在の状態のみを説明する