web-researcher

name	web-researcher
description	Web research skill that prioritizes official documentation while covering broad literature. Searches, fetches, and synthesizes findings into a structured, source-cited, actionable report. This is the lightweight, in-repo researcher; for a deep, multi-agent, adversarially-verified report prefer the built-in `deep-research` skill.
when_to_use	Use when the user says 「調べて」「リサーチして」「公式ドキュメント確認して」, "research X", "look up", "find docs for"; when evaluating libraries, frameworks, or approaches (e.g. wasmtime APIs, WIT/Component Model, WASI 0.3, quinn/redb/openraft/foca); when investigating errors, migration guides, or breaking changes; or when up-to-date information beyond training data is needed.
allowed-tools	WebSearch, WebFetch, Read, Write, Agent
argument-hint	<research topic or question> [--depth=shallow|deep] [--lang=en|ja]

Web Researcher

公式ドキュメントを最優先に、幅広い文献をカバーするウェブリサーチスキル。 目的は「大量に検索する」ことではなく、信頼性の高い情報を構造化して届けること。

原則:

• 公式ドキュメントを最優先。非公式情報は公式で埋まらないギャップにのみ使う
• 検索は段階的に広げる。最初から広く探さない
• 取得した情報は必ず出典付きで構造化する
• 古い情報・矛盾する情報は明示的にフラグを立てる
• 量より質。3 件の高信号ソースは 20 件の低信号ソースに勝る
• Plecto は仕様変動の速い領域（WASI 0.3 / Component Model / wasm32-wasip3）に立脚するので、 取得日と「確定事実 / 現時点の計画（projected）」の区別を常に明示する

引数の解釈

$ARGUMENTS から以下を確定する:

• 調査対象: 技術名、ライブラリ名、エラーメッセージ、概念など
• 調査目的: 導入検討、エラー解決、ベストプラクティス確認、移行ガイドなど
• 深さ: --depth=shallow なら Phase 2 までで終了。--depth=deep か指定なしなら全 Phase 実行
• 言語: --lang=ja なら日本語ソースも積極的に検索。デフォルトは英語優先

目的が不明確な場合は、まず仮説を立ててから検索を開始する。 検索前に「何を知りたいのか」を 1 行で明文化する。

Phase 1: 公式ドキュメント検索

目標: 公式情報源から正確な情報を得る。

手順

1. 公式サイトを特定する

   • 調査対象の公式ドキュメントサイトのドメインを推定する
   • 例: Rust → doc.rust-lang.org, wasmtime → docs.wasmtime.dev, Component Model/WIT → component-model.bytecodealliance.org, WASI → wasi.dev / WASI repos, Anthropic skills → docs.claude.com

2. ドメイン限定検索を実行する

   • WebSearch で公式サイトに絞って検索
   • 検索クエリは具体的に。曖昧な単語の羅列ではなく、ドキュメントに含まれそうなフレーズを使う
   • site:<official-domain> をクエリに含めて公式ドメインに絞る

3. GitHub リポジトリも公式扱いする

   • ライブラリの場合、GitHub の README, CHANGELOG, Issues, Discussions も公式情報源
   • Bytecode Alliance / WASI の WIT 仕様・proposal リポジトリは一次ソース

4. 見つかった重要ページを WebFetch で読む

   • 検索結果の上位 2-3 件を WebFetch で取得
   • 取得時は「このページから <調査目的> に関する情報を抽出して」と目的を明確にする

この Phase で十分な場合

公式ドキュメントだけで調査目的が達成できる場合（API リファレンス確認、設定方法の確認など）、 Phase 2-3 をスキップして Phase 4 に進んでよい。

Phase 2: 広範な文献検索

目標: 公式ドキュメントでカバーされないギャップを埋める。

手順

1. Phase 1 の結果を評価する — 何がわかったか、何がまだ不明か、を整理する。不明点がなければスキップ

2. コミュニティソースを検索する — WebSearch でドメイン制限なしの広範検索。必要なら複数クエリ

3. 情報源の信頼性でフィルタする

   Tier	ソース種別	扱い方
   S	公式ドキュメント、RFC/proposal、公式ブログ	そのまま採用
   A	GitHub Issues/PR (公式リポ)、著名な技術ブログ	高信頼、ただし日付を確認
   B	Stack Overflow (高スコア回答)、カンファレンス資料	参考にするが裏取りする
   C	個人ブログ、Medium 記事、Qiita/Zenn	複数ソースで裏取りできた場合のみ採用
   D	未検証フォーラム投稿、古い記事 (2年以上前)	原則不採用。採用する場合は警告付き

4. 有望なページを WebFetch で深読みする — Tier A-B から 2-3 件。公式と矛盾しないか確認

Agent による並列取得

複数の URL を WebFetch する場合、Agent（subagent_type=Explore 等）を使って並列化できる。 ただし、5 件以上の並列取得は避ける。質が落ちる。

Phase 3: 深掘り調査 (deep のみ)

目標: エッジケース、既知の問題、代替案を洗い出す。--depth=shallow の場合はスキップ。

1. 既知の問題・落とし穴を検索する — "<技術名> gotcha/pitfall/common mistakes"、GitHub Issues label:bug
2. 代替技術・アプローチを検索する — "<技術名> vs", "<技術名> alternative"、比較記事からトレードオフ抽出
3. 最新動向を確認する — リリースノート、ロードマップ、deprecation notice、破壊的変更予定

Phase 4: レポート作成

## Web Research Report: <調査対象>

### 調査目的
- <1行で目的を記述>

### 要約
<3-5行。最も重要な発見を先に>

### 公式ドキュメントからの発見
- <発見> ([出典](URL))

### コミュニティ情報からの発見
- <発見> ([出典](URL), Tier X)

### 注意事項・落とし穴
- <既知の問題や注意点>

### 推奨アクション
1. <具体的な次のステップ>

### 情報の鮮度
- 調査日: <date>
- 最も古いソース: <date/URL>
- 確定事実 / projected の区別: <仕様変動領域なら必ず明記>

### Sources
| # | Title | URL | Tier | Note |
|---|-------|-----|------|------|
| 1 | <タイトル> | <URL> | S | <簡潔な説明> |

レポートの原則

• 公式情報を先に、非公式を後に配置する
• 矛盾する情報がある場合は両方記載し、どちらが信頼できるか判断を添える
• 「わからなかった」ことも明示する。沈黙より正直な不明が価値がある
• URL は必ず含める。Tier 評価で読者が信頼度を即座に判断できるようにする

守ること

• 検索前に目的を明文化する／公式ドキュメントを必ず最初に当たる
• 情報源の信頼性を常に意識する／古い情報には日付を明記して警告する
• 出典のない主張は書かない／検索結果が不十分でも捏造しない
• レポートは簡潔に。10 件以上並べるより 3-5 件の高信号ソースを深く読む