web-researcher

Stars9

Forks4

UpdatedJuly 27, 2026 at 12:25

Web research skill that prioritizes official documentation while covering broad literature. Searches, fetches, and synthesizes findings into a structured actionable report. Use when: - 「調べて」「リサーチして」「公式ドキュメント確認して」 - "research X", "look up", "find docs for" - Evaluating libraries, frameworks, or approaches - Investigating errors, migration guides, or breaking changes - Needing up-to-date information beyond training data

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

Kaikei-e

Kaikei-e/Alt

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Market Research Analysts and Marketing SpecialistsBusiness and Financial Operations Occupations·SOC 13-1161

SKILL.md

readonly

More from this repository

same repository

tdd-workflow

Kaikei-e/Alt

Drive Alt changes test-first in outside-in order — E2E (Playwright/Hurl) → CDC (Pact) → Unit (RED-GREEN-REFACTOR) — and close with a local CI parity sweep (format/lint/type/security) for every touched microservice. Use when implementing a feature, fixing a bug, or refactoring, when deciding what test to write first, or when the user says "TDDで". Also use before declaring work complete, since "tests pass" is not "CI will pass".

2026-07-319

alt-adr-writer

Kaikei-e/Alt

Alt の Architecture Decision Record を日本語で `docs/ADR/NNNNNN.md` に書き起こす。番号採番、frontmatter（title/date/status/tags/affected_services/aliases/supersedes）、Context・Decision・Consequences の書き分け、wikilink 形式、OSS 公開向けの情報衛生を扱う。実装が一段落して決定を記録するときに使う。ユーザが「ADR書いて」「ADRにまとめて」「ADRに記録して」「実装が終わったのでドキュメントに」と言ったとき、または設計上の判断を伴う変更を終えたときに使う。

2026-07-319

grill-with-docs

Kaikei-e/Alt

Interrogate a plan against the project's documented decisions and domain language — challenging fuzzy terms, cross-referencing the code, and surfacing where the plan contradicts an existing ADR or canonical contract. Use when the user wants a plan stress-tested against what the project has already decided, rather than in the abstract. Prefer plain grill-me when there is no documented model to test against, and plan-context-loader when the goal is to gather vault context rather than be questioned.

2026-07-319

improve-codebase-architecture

Kaikei-e/Alt

Hunt for deepening opportunities — shallow modules whose interface costs as much to learn as their implementation saves — and present them as a visual before/after report, informed by the decisions already recorded in docs/ADR/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, reduce the cost of understanding a subsystem, or make code more testable. Use clean-architecture instead when the question is whether a specific change violates Alt's layer rules.

2026-07-319

plan-context-loader

Kaikei-e/Alt

設計・計画タスク時に、Obsidian vault から関連 ADR・contract・review・runbook を必要最小限だけ集めて計画の精度を上げる。次のときに使う: - 「計画を立てて」「設計して」「プランを作って」 - ADR や過去の決定を確認したい - Knowledge Trail / Knowledge Home や reproject-safe / immutable 設計が絡む

2026-07-319

bp-go

Kaikei-e/Alt

Alt の Go 規約を適用する。エラーラップ、context 第一引数、slog、テーブル駆動テスト、http.Server の 4 タイムアウト、Redis Streams の XACK/XAUTOCLAIM 対、fail-fast 設定を扱う。Go のコードを書く・直す・レビューするときに使う。ユーザが「Go」や規約名に触れなくても、Go サービス（alt-backend, auth-hub, pre-processor, search-indexer, mq-hub, rag-orchestrator, altctl）の実装・修正に入るなら使う。

2026-07-279

name	web-researcher
description	Web research skill that prioritizes official documentation while covering broad literature. Searches, fetches, and synthesizes findings into a structured actionable report. Use when: - 「調べて」「リサーチして」「公式ドキュメント確認して」 - "research X", "look up", "find docs for" - Evaluating libraries, frameworks, or approaches - Investigating errors, migration guides, or breaking changes - Needing up-to-date information beyond training data
allowed-tools	WebSearch, WebFetch, Read, Write, Agent
argument-hint	<research topic or question> [--depth=shallow\|deep] [--lang=en\|ja]

Web Researcher

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

原則:

公式ドキュメントを最優先。非公式情報は公式で埋まらないギャップにのみ使う
検索は段階的に広げる。最初から広く探さない
取得した情報は必ず出典付きで構造化する
古い情報・矛盾する情報は明示的にフラグを立てる
量より質。3 件の高信号ソースは 20 件の低信号ソースに勝る

引数の解釈

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

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

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

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

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

手順

公式サイトを特定する
- 調査対象の公式ドキュメントサイトのドメインを推定する
- 例: React → react.dev, Go → go.dev, Rust → doc.rust-lang.org, Python → docs.python.org
ドメイン限定検索を実行する
- WebSearch で公式サイトに絞って検索
- 検索クエリは具体的に。曖昧な単語の羅列ではなく、ドキュメントに含まれそうなフレーズを使う
- site:<official-domain> をクエリに含めて公式ドメインに絞る
GitHub リポジトリも公式扱いする
- ライブラリの場合、GitHub の README, CHANGELOG, Issues, Discussions も公式情報源
- 対象リポジトリに関する情報を検索
見つかった重要ページを WebFetch で読む
- 検索結果の上位 2-3 件を WebFetch で取得
- 取得時は「このページから <調査目的> に関する情報を抽出して」と目的を明確にする

この Phase で十分な場合

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

Phase 2: 広範な文献検索

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

手順

Phase 1 の結果を評価する
- 何がわかったか、何がまだ不明か、を整理する
- 不明点がなければこの Phase をスキップ
コミュニティソースを検索する
- WebSearch でドメイン制限なしの広範検索を実行
- 必要に応じて複数のクエリを使う（異なる角度から検索）

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

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

有望なページを WebFetch で深読みする
- Tier A-B のソースから 2-3 件を選んで WebFetch
- 公式ドキュメントと矛盾する記述がないか確認

Agent による並列取得

複数の URL を WebFetch する場合、Agent を使って並列化できる:

Agent で以下の URL を並列に WebFetch して要約:
- URL1: <目的>
- URL2: <目的>
- URL3: <目的>

ただし、5 件以上の並列取得は避ける。質が落ちる。

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

目標: エッジケース、既知の問題、代替案を洗い出す。

--depth=shallow の場合はスキップ。

手順

既知の問題・落とし穴を検索する
- "<技術名> gotcha", "<技術名> pitfall", "<技術名> common mistakes" で検索
- GitHub Issues で label:bug や is:issue is:open を狙う
代替技術・アプローチを検索する
- "<技術名> vs", "<技術名> alternative" で検索
- 比較記事から客観的なトレードオフを抽出
最新動向を確認する
- リリースノート、ロードマップ、deprecation notice を確認
- 破壊的変更の予定がないか確認

Phase 4: レポート作成

目標: 発見を構造化し、行動可能な形でまとめる。

出力テンプレート

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

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

### 要約
<3-5行で調査結果の要約。最も重要な発見を先に書く>

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

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

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

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

### 情報の鮮度
- 調査日: <date>
- 最も古いソース: <date/URL>
- 鮮度に関する注意: <該当があれば>

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

レポートの原則

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

守ること

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