| name | research-to-inbox |
| description | ユーザーが与えたテーマについて、モデルの事前知識と徹底したweb検索を統合したdeep researchを行い、引用付きの調査メモを inbox/ に保存するSkill。ユーザーが「〜について調べてメモにして」「deep researchして」「リサーチしてinboxに入れて」「research-to-inboxして」のように依頼したら必ずこのSkillを使うこと。sources/ への取り込みは inbox-to-sources、wiki化は source-to-wiki の範囲で、このSkillは調査とメモ作成だけを行う。 |
research-to-inbox
ユーザーが与えたテーマをdeep researchし、調査メモを inbox/ に1ファイルで保存する。
sources/ への取り込みと wiki/ の更新はこのSkillの範囲外。
最初にテーマを確認し、テーマが与えられていなければユーザーに確認して終了する。
--dry-run が指定された場合は、手順1〜2 (スコープ確認とサブ質問分解) だけを行い、調査計画 (サブ質問と検索方針の一覧) を提示して終了する。web検索とファイル作成は行わない。
併用するSkill
メモ本文を書く前に、local skill の japanese-tech-writing と stop-ai-slop-jp を読む。
これらのskillが環境に無い場合は、この節をスキップし、後述の本文方針に従って書く。
ルール
- 1テーマ = 1ファイル：調査結果は
inbox/ 直下の1つのMarkdownにまとめる。sources/ や wiki/ に直接書かない。
- 知識は統合する：モデルの事前知識とweb検索の結果を書き分けず、統合して完成度の高い本文を書く。ただし事前知識だけに頼らず、本文の柱になる主張はweb検索で確認する。
- 主張には出典：重要な主張には
[n] 形式で出典番号を付け、末尾の参照一覧と対応させる。
- 一次情報源を優先：公式ドキュメント、論文、公式発表を優先する。まとめ記事だけを根拠にしない。
- 日英両方で検索する：テーマの言語に関わらず、英語と日本語の両方で検索する。
- 時点を意識する：検索前に現在日付を確認し、事前知識が古い可能性を前提に動く。変化の速い話題は情報の時点を本文に明記する。
- 矛盾は明示する：情報源同士が食い違う場合は、どちらかに寄せず違いを書く。
- 特定agent専用機能に依存しない：このSkillはClaude Code以外のcoding agentでも使う。特定製品のツール名や他skillの呼び出しを前提にせず、その環境で使えるweb検索・並列実行の手段を使う。
手順
1. スコープを確認する
テーマの目的 (何のための知識か)、範囲、求める深さを把握する。
テーマが曖昧で調査方針が分かれる場合だけ、ユーザーに2〜3個質問して絞り込む。明確なら質問せずに進む。
2. サブ質問に分解する
テーマを3〜8個のサブ質問に分解する。
各サブ質問に、日英それぞれの検索クエリ案を用意する。
事前知識で全体像の仮説を立て、「どこが不確かか」「どこが古くなっていそうか」を優先的にサブ質問へ落とす。
3. サブ質問ごとに調査する
サブ質問ごとにweb検索と本文の読み込みを行う。
- subagentや並列タスクが使える環境では、サブ質問単位で並列に調査する。各調査は生の検索結果ではなく、蒸留したノート (要点、出典URL、公開日、信頼度) を返す。
- 並列実行が使えない環境では、サブ質問を順番に調査する。
- 1サブ質問につき検索クエリを複数試す。検索結果の一覧だけで判断せず、有望なページは本文まで読む。
- 一次情報源に当たれる主張は、まとめ記事で止めずに一次情報源まで遡る。
4. 品質ゲートを確認する
執筆前に調査の量と質を確認する。目安は次の通り。
- 参照する情報源が全体で10件以上、5ドメイン以上ある。
- 各サブ質問に答えられるだけの材料が揃っている。
- 本文の柱になる主張が、事前知識だけでなく情報源で裏付けられている。
満たさない場合は手順3に戻って追加調査する。
テーマが狭く情報源が構造的に少ない場合は、無理に件数を稼がず、その旨を後の報告に含める。
5. 欠落と反論を点検する
ドラフトを書く前に、次を自問する。
- 答えられていないサブ質問は残っていないか。
- 主要な主張への反例、反論、代替案を見落としていないか。
- 結論を変えうる新しい動き (直近のリリース、仕様変更) を見落としていないか。
欠けが見つかったら手順3に戻る。
6. メモを執筆する
調査結果と事前知識を統合し、日本語で本文を書く。構成の基準は次の通り。
# <テーマ>
## 結論
<テーマへの答えを最初に書く>
## <論点ごとの節>
<サブ質問をそのまま見出しにせず、論点で括り直してよい>
## 未解決・要検証事項
## 参照
- [1] <タイトル> — <URL> (<公開日または参照日>)
- 結論を最初に書き、根拠を後に続ける。
- 情報源の羅列にせず、判断とその理由まで書く。
- 引用番号
[n] は参照一覧と対応させる。
7. inbox/ に保存する
inbox/YYYY-MM-DD_<slug>.md として保存する。日付は当日、slugはテーマが分かる短い名前にする。
frontmatterは _template/source.md に従い、model に生成した自分のモデル名を入れる。
---
title: "<title>"
created: "<YYYY-MM-DD>"
updated: "<YYYY-MM-DD>"
model: "<model>"
---
created はファイル名の日付と一致させる。title は内容に沿った題名にする (日本語可)。ファイル名との一致は求めない。
8. 検証する
oxfmt で作成したMarkdownを整形する。- 引用番号
[n] と参照一覧が対応していることを確認する。
報告
次を簡潔に報告する。
- 作成したメモのパス
- 調査したサブ質問と、参照した情報源の概況 (ドメインの偏り、情報が薄かった論点)
- 未解決・要検証として残した事項
- 最後に「sources/ への取り込みはこのSkillの範囲外 (inbox-to-sources が担う)」と1行添える。
