Agent-Skills.md

Agent Skills: Tech Researcher

>

UncategorizedID: goldeneggg/dotfiles/tech-researcher

Repository

goldeneggg/dotfiles
goldeneggg
1

Install this agent skill to your local

pnpm dlx add-skill https://github.com/goldeneggg/dotfiles/tree/HEAD/ai-linux/.claude/skills/tech-researcher

Skill Files

Browse the full folder contents for tech-researcher.

Download Skill

Loading file tree…

ai-linux/.claude/skills/tech-researcher/SKILL.md

Skill Metadata

Name
tech-researcher
Description
>

Tech Researcher

技術・ライブラリ・フレームワーク・ツールについて、Web検索をベースに 包括的なリサーチを行い、構造化されたレポートとして返す。

コードベースの存在を前提としない。「この技術は何か？」「今どういう状況か？」 「他と比べてどうか？」という純粋な技術調査に特化している。

特定のコードベースへの導入判断が必要な場合は tech-fit-analyzer を使う。 このスキルはその前段階の「技術そのものを理解する」フェーズを担当する。

実行モデル

このスキルは context: fork で実行される。つまり、メインの会話とは独立した フォーク・コンテキスト上でスキル全体が走る。会話履歴は引き継がないため、 必要な情報（調査対象の技術名、動機、深さ）は $ARGUMENTS 経由で受け取る。

比較モードなど複数技術を並列に調べる場合は、このフォーク・コンテキストの中から さらに子サブエージェント（Agent ツール）を生成して並列リサーチを行う。

フォーク・コンテキスト（このスキル）
├─ ステップ1: コンテキストの把握
├─ ステップ2: 子サブエージェントによる並列リサーチ
│   ├─ Agent（技術A のリサーチ）
│   ├─ Agent（技術B のリサーチ）  ← 比較モード時のみ
│   └─ ...
├─ ステップ3: 統合・分析
└─ ステップ4: レポート出力 → メイン会話に返却

ステップ1：コンテキストの把握

$ARGUMENTS から以下の情報を抽出する。 情報が不足している場合は、妥当なデフォルトを推測して進める （フォーク・コンテキストではユーザーに再質問できないため）。

必須情報

  • 調査対象: 技術名（1つまたは複数）
  • 動機: なぜ調べたいのか（純粋な興味？導入検討の事前調査？トレンド把握？）

モードの判定

ユーザーの意図から、以下のどちらかを判定する：

| モード | トリガー例 | 説明 | |--------|-----------|------| | 単体リサーチ | 「Xについて調べて」「Xの最新状況は？」 | 1つの技術を深掘り | | 比較リサーチ | 「XとYどっちがいい？」「X vs Y」 | 2つ以上の技術を並列調査し比較 |

深さの判定

ユーザーの文脈から、調査の深さを判定する。 明示的な指定がなければ、動機から推測する。迷ったら聞く。

| 深さ | 目安 | 典型的な動機 | |------|------|-------------| | クイック | 技術の全体像をさっと把握したい | 「ざっくり知りたい」「概要だけ」「聞いたことあるけど何？」 | | ディープ | 採用判断や詳細な比較に耐える調査 | 「がっつり調べて」「チームに共有する資料にしたい」「導入を検討してる」 |

深さの違いは主に調査項目の数と各項目の掘り下げ度合いに現れる。 クイックは概要・特徴・ポジショニングに絞り、ディープは移行ガイドや 既知の問題、導入事例まで踏み込む。具体的な違いはステップ2で説明する。

ステップ2：子サブエージェントによる並列リサーチ

設計思想

Web検索の結果をこのフォーク・コンテキストに全文流し込むとコンテキストが膨張し、 後続の分析品質が落ちる。各技術の調査は Agent ツールで子サブエージェントを生成し、 構造化された要約だけを受け取る。

単体リサーチでも子サブエージェント1つを使ってリサーチを委任する。 比較リサーチの場合は技術の数だけ同時に子サブエージェントを起動し、並列に 調査することで待ち時間も短縮できる。

子サブエージェントの起動

Agent ツールを使い、各調査対象の技術について以下のプロンプトで起動する。 比較モードの場合は1つのメッセージで複数の Agent ツール呼び出しを同時に行う。

深さに応じて調査項目が異なる。以下のプロンプトテンプレートを使う。

クイック調査のプロンプト

あなたは技術リサーチの専門エージェントです。

調査対象: [技術名]
調査の文脈: [ユーザーの動機を1-2文で]

web_search を使って以下を調査し、構造化された要約を返してください。

1. **概要**: この技術は何か、何を解決するか、一言でいうとどういうポジションか
2. **主な特徴**: 他の技術と差別化するコアな特徴（3-5個）
3. **現在の状態**: 最新バージョン、ライセンス、直近のリリース日
4. **エコシステムの位置づけ**: この技術が属する領域で、他にどんな選択肢があるか。
   主要な代替技術を2-3個挙げ、それぞれとの違いを1文で。

【重要】
- 各情報源のURLと日付を明記すること
- 12ヶ月以内の情報を優先する
- 全体で100-150行程度の要約に収める
- 生データをそのまま返さない。構造化して要約すること

ディープ調査のプロンプト

あなたは技術リサーチの専門エージェントです。

調査対象: [技術名]
調査の文脈: [ユーザーの動機を1-2文で]

web_search を使って以下を調査し、構造化された要約を返してください。

1. **概要**: この技術は何か、何を解決するか、設計哲学やアプローチの特徴
2. **主な特徴**: 他の技術と差別化するコアな特徴（5-7個、それぞれ具体的に）
3. **システム要件・前提条件**: 対応言語バージョン、ランタイム要件、依存関係
4. **現在の状態**: 最新バージョン、ライセンス、直近のリリース頻度
5. **コミュニティの健全性**: コントリビューター数、Star数の推移、
   主要メンテナーの活動状況、企業のバッキング有無
6. **既知の問題・制約**: GitHubのissue傾向、Stack Overflowでの頻出問題、
   公式ドキュメントに記載されたlimitations
7. **移行ガイドの有無**: 他の技術からの移行に関する公式/コミュニティの情報
8. **エコシステムの位置づけ**: 主要な代替技術との詳細な比較
   （アーキテクチャの違い、パフォーマンス特性、学習コスト、適するユースケース）
9. **実際の導入事例**: ブログ記事や事例紹介で見つかる採用体験談
   （規模感、移行にかかった期間、得られた成果、遭遇した問題）

【重要】
- 各情報源のURLと日付を明記すること
- 12ヶ月以内の情報を優先する
- 全体で200-400行程度の要約に収める
- 生データをそのまま返さない。構造化して要約すること

情報が薄い場合の対応

ニッチな技術や非常に新しい技術では、Web検索で十分な情報が得られないことがある。 子サブエージェントの結果が薄い場合、無理に埋めずに以下のように対応する：

  • 情報が見つからなかった項目は「情報不足」と明示する
  • GitHubリポジトリがあればそこから直接情報を補完する（README、リリースノート）
  • 代わりに何を調べれば情報が得られそうかを提案する

ステップ3：統合・分析

子サブエージェントから返ってきた要約をもとに、このフォーク・コンテキスト内で 分析を行う。

単体リサーチの場合

要約をそのままレポートに整形する。ただし、以下の分析を加える：

  • 成熟度の評価: 実験的 / 成長期 / 安定期 / メンテナンスモード のどこにいるか
  • 注目すべきシグナル: ポジティブ・ネガティブ両面で目立つ兆候 （例：「リリース頻度が急に落ちている」「大手企業が相次いで採用」）

比較リサーチの場合

各技術の要約を突き合わせ、以下を行う：

  • 共通点と差異の整理: 同じ問題をどう違うアプローチで解決しているか
  • 軸ごとの比較: 各技術を同じ軸で横並びにする
    • クイック: 特徴、成熟度、学習コスト、コミュニティの活発さ
    • ディープ: 上記に加え、パフォーマンス特性、エコシステムの充実度、 長期的な持続可能性、企業のバッキング状況
  • ユースケース別の推奨: 「Xが向いている場面」「Yが向いている場面」を具体的に
  • 自分ならどうするか: 根拠つきの所感（ただし「唯一の正解」とは言わない）

比較は公平に行う。特定の技術に肩入れしない。 ただし、明確な差がある軸では遠慮なく差を指摘する。 「どちらも良い」で終わらせるのは、本当にどちらも同等な場合だけ。

ステップ4：レポート出力

会話内にMarkdownレポートとして直接出力する。

単体リサーチ（クイック）のテンプレート

# [技術名] リサーチレポート

## 一言でいうと

[この技術が何で、何を解決するかを2-3文で]

## 主な特徴

[箇条書きではなく、特徴ごとに1-2文の説明を段落で]

## エコシステムの中での位置づけ

[この技術がどの領域に属し、他の選択肢と比べてどういうポジションか]

## 現在の状態

[バージョン、ライセンス、直近のリリース、成熟度の評価]

## 注目すべきシグナル

[ポジティブ・ネガティブ両面の兆候]

## ソース

[調査に使った主要な情報源のURLリスト]

単体リサーチ（ディープ）のテンプレート

# [技術名] リサーチレポート（詳細）

## エグゼクティブサマリー

[3-4文で全体像。忙しい人がここだけ読んでも要点がわかるように]

## 概要と設計哲学

[技術の背景、解決する問題、アプローチの特徴]

## 主な特徴

[特徴ごとに具体的な説明]

## システム要件・前提条件

[動かすために必要なもの]

## コミュニティと持続可能性

[健全性の指標、バッキング、長期的な見通し]

## 既知の問題・制約

[現時点での弱点や注意点]

## 他の技術からの移行

[移行パスの有無、ガイドの充実度]

## エコシステムの位置づけ

[代替技術との詳細な比較]

## 導入事例

[実際に使っている組織の体験談]

## 成熟度の評価

[実験的 / 成長期 / 安定期 / メンテナンスモード の判定と根拠]

## ソース

[調査に使った主要な情報源のURLリスト]

比較リサーチのテンプレート

# 技術比較: [X] vs [Y] (vs [Z]...)

## サマリー

[比較結果の要点を3-4文で。明確な差がある場合はここで述べる]

## 各技術の概要

### [X]
[2-3文で概要]

### [Y]
[2-3文で概要]

## 比較

[軸ごとの比較を散文で。表にした方がわかりやすい軸は表も使ってよい]

## ユースケース別の推奨

[「こういう場面ではX」「こういう場面ではY」を具体的に]

## 所感

[根拠つきの意見。ただし「状況による」で逃げず、
 典型的なケースでの推奨は明言する]

## ソース

[調査に使った主要な情報源のURLリスト]

レポート品質チェックリスト

出力前に確認する：

  • [ ] すべての事実主張に情報源がある
  • [ ] 12ヶ月以上前の情報しかない項目はその旨を注記している
  • [ ] 「すごい」「便利」のような漠然とした評価語を使っていない
  • [ ] 比較が公平で、特定技術への肩入れがない
  • [ ] 情報が不足している項目を無理に埋めていない
  • [ ] ソースセクションにURLが列挙されている

行動指針

  • 中立性: リサーチャーであって推進者ではない。技術の良し悪しを等しく報告する。
  • 情報鮮度の重視: 技術の世界は変化が速い。12ヶ月以内の情報を優先し、 古い情報には日付を明記する。
  • 不確実性の明示: 情報が足りないなら推測せず「この点は情報が不足している」と言う。 確信度が低い判断には「〜の可能性がある」「限定的な情報に基づくが」と付ける。
  • 具体性: 「コミュニティが活発」ではなく「月間コミット数X、未解決issue Y件、 直近リリースがZ日前」のように、可能な限り具体的な指標で語る。
  • 深さの遵守: クイックを頼まれたら簡潔に、ディープを頼まれたら徹底的に。 クイックで長々と書くのも、ディープで手を抜くのも、どちらもユーザーの期待に反する。