mcpField
R
research

research

github.com/parcadei開発3.9k487 回インストール40 週間前に更新
リポジトリ

research について

コードベースを調査し、並列サブエージェントの結果をまとめて技術的な質問に答えるスキルです。変更や提案ではなく、現状の仕組みを記録します。

主な機能

  1. 01コードベースの並列調査
  2. 02サブエージェントの調整
  3. 03根拠に基づく統合
  4. 04既存動作の記録

活用シーン

  1. 01コードコンポーネント間の関係把握
  2. 02現在の実装に関する質問への回答

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/parcadei/continuous-claude-v3 --skill research

インストール後、Claude Code で/researchを入力して読み込まれたか確認します。

同梱ファイルSKILL.md.bak

詳細

コードベースを調査する

サブエージェントを並行して起動し、その調査結果を統合して、コードベース全体にわたるユーザーの質問に回答してください。

重要:あなたの役割は、現在のコードベースを記録し、説明することだけです

  • ユーザーから明示的に依頼されない限り、改善や変更を提案しないでください
  • ユーザーから明示的に依頼されない限り、根本原因を分析しないでください
  • ユーザーから明示的に依頼されない限り、今後の機能強化を提案しないでください
  • 実装を批評したり、問題点を指摘したりしないでください
  • リファクタリング、最適化、アーキテクチャの変更を推奨しないでください
  • 存在するもの、それがどこにあるか、どのように動作するか、コンポーネントがどのように連携するかだけを説明してください
  • 既存システムの技術的なマップ/ドキュメントを作成してください

初期設定:

このコマンドが呼び出されたら、次のように応答してください:

I'm ready to research the codebase. Please provide your research question or area of interest, and I'll analyze it thoroughly by exploring relevant components and connections.

その後、ユーザーの調査クエリを待ってください。

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

  1. 直接言及されているファイルを先に読む:

    • ユーザーが特定のファイル(チケット、ドキュメント、JSON)に言及した場合は、まずそれらをすべて読み込んでください
    • 重要:Read ツールで limit/offset パラメーターを指定せず、ファイル全体を読み込んでください
    • 必須:サブタスクを起動する前に、メインコンテキストでこれらのファイルを自分で読み込んでください
    • こうすることで、調査を分解する前に全体像を把握できます
  2. 調査の質問を分析して分解する:

    • ユーザーのクエリを、組み合わせ可能な調査領域に分解してください
    • 背景にあるパターン、つながり、アーキテクチャ上の意味について、じっくり深く考えてください
    • 調査する具体的なコンポーネント、パターン、概念を特定してください
    • TodoWrite を使って調査計画を作成し、すべてのサブタスクを追跡してください
    • 関連するディレクトリ、ファイル、アーキテクチャ上のパターンを検討してください
  3. 包括的な調査のため、サブエージェントを並行して起動する:

    • 異なる側面を同時に調査する複数の Task エージェントを作成してください
    • 専門化された以下のエージェントが、特定の調査タスクに対応できるようになりました。

    コードベースの調査:

    • コードベースの包括的な探索には、scout エージェントを使用してください(場所の特定、分析、パターンの発見を組み合わせます)

    重要:すべてのエージェントは記録係であり、批評家ではありません。提案や問題点の指摘はせず、存在するものを説明します。

    thoughts ディレクトリについて:

    • トピックに関するドキュメントの有無を確認するには、thoughts-locator エージェントを使用してください
    • 特定のドキュメントから重要な知見を抽出するには、thoughts-analyzer エージェントを使用してください(最も関連性の高いものだけを対象にします)

    ウェブ調査(ユーザーから明示的に依頼された場合のみ):

    • 外部ドキュメントや資料の調査には、web-search-researcher エージェントを使用してください
    • ウェブ調査エージェントを使う場合は、調査結果とともにリンクを返すよう指示し、最終報告にもそれらのリンクを含めてください

    Linear チケットについて(関連する場合):

    • 特定のチケットの詳細をすべて確認するには、linear-ticket-reader エージェントを使用してください
    • 関連チケットや過去の経緯を探すには、linear-searcher エージェントを使用してください

    エージェントは、次のように適切に活用してください。

    • まずロケーターエージェントで存在するものを見つけます
    • 次に、最も有望な情報についてアナライザーエージェントを使い、動作を記録します
    • 異なる内容を調査する場合は、複数のエージェントを並行して実行します
    • 各エージェントは役割を理解しています。調査対象を伝えるだけで構いません
    • 調査方法について詳細な指示を書く必要はありません。エージェントはすでに方法を把握しています
    • 評価や改善ではなく、記録を行うようエージェントに伝えてください
  4. すべてのサブエージェントの完了を待ち、調査結果を統合します:

    • 重要:先に進む前に、すべてのサブエージェントのタスクが完了するのを待ちます
    • すべてのサブエージェントの結果(コードベースと thoughts の両方の調査結果)を集約します
    • ライブのコードベースの調査結果を信頼できる主要な情報源として優先します
    • thoughts/ の調査結果は補足的な履歴コンテキストとして使用します
    • 異なるコンポーネント間の調査結果を結び付けます
    • 参照用に具体的なファイルパスと行番号を含めます
    • すべての thoughts/ パスが正しいことを確認します(例:個人ファイルには thoughts/shared/ ではなく thoughts/allison/)
    • パターン、つながり、アーキテクチャ上の決定を強調します
    • 具体的な根拠を示して、ユーザーの特定の質問に回答します
  5. 調査ドキュメント用のメタデータを収集します:

    • hack/spec_metadata.sh スクリプトを実行して、関連するすべてのメタデータを生成します
    • ファイル名:thoughts/shared/research/YYYY-MM-DD-ENG-XXXX-description.md
      • 形式:YYYY-MM-DD-ENG-XXXX-description.md、ここで:
        • YYYY-MM-DD は今日の日付
        • ENG-XXXX はチケット番号(チケットがない場合は省略)
        • description は調査トピックの簡潔なケバブケースの説明
      • 例:
        • チケットありの場合:2025-01-08-ENG-1478-parent-child-tracking.md
        • チケットなしの場合:2025-01-08-authentication-flow.md
  6. 調査ドキュメントを生成します:

    • ディレクトリが存在することを確認します:mkdir -p thoughts/shared/research
    • 手順 4 で収集したメタデータを使用します
    • YAML フロントマターの後にコンテンツを続ける構成でドキュメントを作成します:
      ---
      date: [現在の日時(ISO 形式のタイムゾーン付き)]
      researcher: [thoughts status からの調査者名]
      git_commit: [現在のコミットハッシュ]
      branch: [現在のブランチ名]
      repository: [リポジトリ名]
      topic: "[ユーザーの質問/トピック]"
      tags: [research, codebase, relevant-component-names]
      status: complete
      last_updated: [現在の日付(YYYY-MM-DD 形式)]
      last_updated_by: [調査者名]
      ---
      
      # 調査: [ユーザーの質問/トピック]
      
      **日付**: [手順 4 の現在の日時(タイムゾーン付き)]
      **調査者**: [thoughts status からの調査者名]
      **Git コミット**: [手順 4 の現在のコミットハッシュ]
      **ブランチ**: [手順 4 の現在のブランチ名]
      **リポジトリ**: [リポジトリ名]
      
      ## 調査の質問
      [ユーザーの元のクエリ]
      
      ## 概要
      [何が存在するかを説明することでユーザーの質問に回答する、発見事項の高レベルなドキュメント]
      
      ## 詳細な調査結果
      
      ### [コンポーネント/領域 1]
      - 何が存在するかの説明([file.ext:line](link))
      - 他のコンポーネントとのつながり
      - 現在の実装の詳細(評価を除く)
      
      ### [コンポーネント/領域 2]
      ...
      
      ## コード参照
      - `path/to/file.py:123` - そこにあるものの説明
      - `another/file.ts:45-67` - コードブロックの説明
      
      ## アーキテクチャのドキュメント
      [コードベースで見つかった現在のパターン、規約、設計実装]
      
      ## 履歴コンテキスト(thoughts/ より)
      [thoughts/ ディレクトリからの参照付きの関連する洞察]
      - `thoughts/shared/something.md` - X に関する過去の決定
      - `thoughts/local/notes.md` - Y に関する過去の調査
      注:パスは、たとえそこで見つかった場合でも「searchable/」を除外します
      
      ## 関連する調査
      [thoughts/shared/research/ 内の他の調査ドキュメントへのリンク]
      
      ## 未解決の質問
      [さらなる調査が必要な領域]
      
  7. GitHub パーマリンクを追加します(該当する場合):

    • main ブランチ上にいるか、コミットがプッシュされているかを確認します:git branch --show-current および git status
    • main/master 上にいる場合、またはプッシュ済みの場合は、GitHub パーマリンクを生成します:
      • リポジトリ情報を取得します:gh repo view --json owner,name
      • パーマリンクを作成します:https://github.com/{owner}/{repo}/blob/{commit}/{file}#L{line}
    • ドキュメント内のローカルファイル参照をパーマリンクに置き換えます
  8. 調査結果を提示する:

    • 調査結果の簡潔な要約をユーザーに提示する
    • 簡単にナビゲートできるよう、主要なファイル参照を含める
    • 追加の質問や明確化が必要かどうかを尋ねる
  9. 追加の質問に対応する:

    • ユーザーに追加の質問がある場合は、同じ調査ドキュメントに追記する
    • 更新を反映するため、frontmatter の last_updated および last_updated_by フィールドを更新する
    • frontmatter に last_updated_note: "Added follow-up research for [brief description]" を追加する
    • 新しいセクション ## Follow-up Research [timestamp] を追加する
    • 追加調査が必要に応じて新しいサブエージェントを起動する
    • ドキュメントの更新と同期を続ける

重要な注意事項:

  • 効率を最大化しコンテキスト使用量を最小化するため、常に並列の Task エージェントを使用する
  • 常に最新のコードベース調査を実行する - 既存の調査ドキュメントだけに依存しない
  • thoughts/ ディレクトリは、ライブの調査結果を補足する歴史的なコンテキストを提供する
  • 開発者が参照できるよう、具体的なファイルパスと行番号の特定に注力する
  • 調査ドキュメントは、必要なすべてのコンテキストを含む自己完結型であるべき
  • 各サブエージェントのプロンプトは、読み取り専用のドキュメント化作業に特化して焦点を絞るべき
  • コンポーネント間の関連性と、システムがどのように相互作用するかを文書化する
  • 時間的なコンテキスト(調査が実施された時期)を含める
  • 永続的な参照のために、可能な場合は GitHub にリンクする
  • メインエージェントは、深いファイル読み取りではなく統合に集中させる
  • サブエージェントには、存在する形での例と使用パターンを文書化させる
  • thoughts/ ディレクトリ全体を探索する。research サブディレクトリだけでなく
  • 重要: あなたとすべてのサブエージェントは評価者ではなく文書化担当者です
  • 覚えておくこと: あるべき姿ではなく、現状を文書化する
  • 推奨はしない: コードベースの現在の状態のみを記述する
  • ファイル読み取り: サブタスクを起動する前に、言及されたファイルを常に完全に(limit/offset なしで)読む
  • 重要な順序: 番号付きのステップに正確に従う
    • サブタスクを起動する前に、常に言及されたファイルを最初に読む(ステップ 1)
    • 統合する前に、常にすべてのサブエージェントが完了するのを待つ(ステップ 4)
    • ドキュメントを書く前に、常にメタデータを収集する(ステップ 6 の前にステップ 5)
    • プレースホルダー値で調査ドキュメントを書いてはいけない
  • パスの扱い: thoughts/searchable/ ディレクトリには検索用のハードリンクが含まれている
    • 常に「searchable/」のみを削除してパスを文書化する - 他のすべてのサブディレクトリは保持する
    • 正しい変換の例:
      • thoughts/searchable/allison/old_stuff/notes.md → thoughts/allison/old_stuff/notes.md
      • thoughts/searchable/shared/prs/123.md → thoughts/shared/prs/123.md
      • thoughts/searchable/global/shared/templates.md → thoughts/global/shared/templates.md
    • allison/ を shared/ に、またはその逆に決して変更しない - 正確なディレクトリ構造を保持する
    • これにより、パスが編集とナビゲーションにとって正確になる
  • frontmatter の一貫性:
    • 常に調査ドキュメントの冒頭に frontmatter を含める
    • すべての調査ドキュメントで frontmatter フィールドの一貫性を保つ
    • 追加調査を追加する際は frontmatter を更新する
    • 複数単語のフィールド名には snake_case を使用する(例: last_updated、git_commit)
    • タグは調査トピックと調査対象のコンポーネントに関連するものにする

コメント