AgentSkillsCN

research

研究（专门用于调查的模式）

SKILL.md
--- frontmatter
name: research
description: Research (調査専用モード)

Research (調査専用モード)

重要: このスキルは調査専用です。ファイルの作成・編集・削除は一切行わないでください。

注意: バグの原因特定や問題の修正が目的の場合は、このスキルではなく /debug-flow スキルを使用すること。

ユーザーの質問やトピックについて徹底的に調査し、必ず結論を出して報告します。

最重要原則: 結論を出す義務

調査の最終目標は、ユーザーの質問に対する明確な回答を提供することです。

  • •調査結果がどうであれ、必ず結論セクションで回答を出すこと
  • •「情報が不足している」「追加調査が必要」だけで終わることは禁止
  • •不確実性がある場合でも、現時点で得られた情報に基づく最善の推論を提示すること
  • •確信度が低い場合は、確信度を明示した上で結論を述べること (例: 「確信度 60%: おそらく X が原因」)

結論を出せない場合の対処

結論を出すのに情報が不足していると感じた場合:

  1. •まず追加調査を自分で実行する - ユーザーに聞く前に、自分で調べられることは調べ尽くす
  2. •それでも不明な場合は、仮説を立てて提示する - 「A である可能性が高い」「B の可能性も否定できない」など
  3. •最後の手段として、次のステップを具体的に提案する - 「X を確認すれば Y が判明する」など、ユーザーが取れる具体的なアクションを示す

調査プロセス

1. 調査計画の立案

調査を開始する前に、以下を明確にする:

  • •調査目的: 何を明らかにしたいのか
  • •調査観点: どのような角度から調査するか (例: 実装方法、ベストプラクティス、既存コードとの整合性、パフォーマンス、セキュリティなど)
  • •情報源: どこから情報を得るか (コードベース、公式ドキュメント、Web 検索など)
  • •調査手順: 効率的な調査順序

計画を立てたら、ユーザーに調査計画を簡潔に共有してから調査を開始する。

2. タスク前コンテキスト確認 (実装関連の調査の場合)

実装タスクに関連する調査の場合、以下を必ず確認する:

A. 類似実装の調査

  • •類似機能のファイルを検索 (Grep/Glob)
  • •ディレクトリ構造と命名規則を把握
  • •既存の実装パターンを特定

B. アーキテクチャ制約の確認

以下のファイルを確認し、プロジェクト固有の制約を把握:

  • •CLAUDE.md - プロジェクト固有の制約
  • •README.md / docs/architecture.md / docs/adr/
  • •.github/CONTRIBUTING.md

C. 実行環境の確認

以下を確認し、環境制約を把握:

  • •Dockerfile / docker-compose.yml
  • •.github/workflows/ - CI/CD 設定
  • •terraform/ / infrastructure/
  • •.env.example

D. テスト規約の確認

  • •テストファイルの配置場所
  • •命名規則、テストフレームワーク

3. 並列調査の実行

複数の観点で調査が必要な場合は、必ず Task ツールで複数のサブエージェントを並列起動する。

モデル指定: サブエージェントは model: "sonnet" を指定して起動すること (コスト効率と速度のバランスが良い)。

code
例: 「React の状態管理ライブラリを比較調査」
→ 並列で起動:
  - サブエージェント 1: Redux の最新動向と使用例を調査
  - サブエージェント 2: Zustand の特徴と使用例を調査
  - サブエージェント 3: Jotai の特徴と使用例を調査
  - サブエージェント 4: 既存コードベースの状態管理パターンを分析

各サブエージェントには以下を明確に指示する:

  • •調査対象と範囲
  • •収集すべき情報 (具体例、コード例、数値データなど)
  • •出典の明記を必須とすること

4. 調査結果の報告

調査完了後、以下の形式で報告する。結論セクションは必須。

  1. •

    結論 (必須・最初に記載):

    • •ユーザーの質問に対する直接的な回答
    • •1-3 文で簡潔に述べる
    • •確信度が低い場合は明示する (例: 「確信度 70%」)
    • •複数の可能性がある場合は、最も可能性が高いものから順に記載
    markdown
    ## 結論

[問題の原因/質問への回答を 1-3 文で明確に述べる]

確信度: [高/中/低] (根拠: [なぜその確信度か])
  2. •

    詳細: 結論を裏付ける調査結果

    • •発見事項
    • •具体例やコード例
    • •出典 (URL、ファイルパス、ドキュメント参照)
  3. •

    仮定リスト (実装関連の調査の場合): 調査に基づく仮定を明示

    markdown
    ## 仮定リスト

以下は調査に基づく仮定です。間違っている場合はご指摘ください。

1. [仮定1] - 根拠: [なぜそう考えたか]
2. [仮定2] - 根拠: [なぜそう考えたか]
  4. •

    次のステップ (オプション): 結論に基づいて推奨されるアクション

    • •結論が出た上で、さらに調査や実装が必要な場合のみ記載
    • •具体的で実行可能なアクションを提示

禁止事項

  • •Edit, Write ツールの使用
  • •Bash でのファイル操作 (作成、編集、削除)
  • •git commit, git push などの変更を伴う操作

調査結果に基づいて実装が必要な場合は、調査完了後にユーザーに確認を取ること。