| 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: 公式ドキュメント検索
目標: 公式情報源から正確な情報を得る。
手順
-
公式サイトを特定する
- 調査対象の公式ドキュメントサイトのドメインを推定する
- 例: 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
-
ドメイン限定検索を実行する
WebSearch で公式サイトに絞って検索- 検索クエリは具体的に。曖昧な単語の羅列ではなく、ドキュメントに含まれそうなフレーズを使う
site:<official-domain> をクエリに含めて公式ドメインに絞る
-
GitHub リポジトリも公式扱いする
- ライブラリの場合、GitHub の README, CHANGELOG, Issues, Discussions も公式情報源
- Bytecode Alliance / WASI の WIT 仕様・proposal リポジトリは一次ソース
-
見つかった重要ページを WebFetch で読む
- 検索結果の上位 2-3 件を
WebFetch で取得
- 取得時は「このページから <調査目的> に関する情報を抽出して」と目的を明確にする
この Phase で十分な場合
公式ドキュメントだけで調査目的が達成できる場合（API リファレンス確認、設定方法の確認など）、
Phase 2-3 をスキップして Phase 4 に進んでよい。
Phase 2: 広範な文献検索
目標: 公式ドキュメントでカバーされないギャップを埋める。
手順
-
Phase 1 の結果を評価する — 何がわかったか、何がまだ不明か、を整理する。不明点がなければスキップ
-
コミュニティソースを検索する — WebSearch でドメイン制限なしの広範検索。必要なら複数クエリ
-
情報源の信頼性でフィルタする
| Tier | ソース種別 | 扱い方 |
|---|
| S | 公式ドキュメント、RFC/proposal、公式ブログ | そのまま採用 |
| A | GitHub Issues/PR (公式リポ)、著名な技術ブログ | 高信頼、ただし日付を確認 |
| B | Stack Overflow (高スコア回答)、カンファレンス資料 | 参考にするが裏取りする |
| C | 個人ブログ、Medium 記事、Qiita/Zenn | 複数ソースで裏取りできた場合のみ採用 |
| D | 未検証フォーラム投稿、古い記事 (2年以上前) | 原則不採用。採用する場合は警告付き |
-
有望なページを WebFetch で深読みする — Tier A-B から 2-3 件。公式と矛盾しないか確認
Agent による並列取得
複数の URL を WebFetch する場合、Agent（subagent_type=Explore 等）を使って並列化できる。
ただし、5 件以上の並列取得は避ける。質が落ちる。
Phase 3: 深掘り調査 (deep のみ)
目標: エッジケース、既知の問題、代替案を洗い出す。--depth=shallow の場合はスキップ。
- 既知の問題・落とし穴を検索する —
"<技術名> gotcha/pitfall/common mistakes"、GitHub Issues label:bug
- 代替技術・アプローチを検索する —
"<技術名> vs", "<技術名> alternative"、比較記事からトレードオフ抽出
- 最新動向を確認する — リリースノート、ロードマップ、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 件の高信号ソースを深く読む
