wiki-research
複数回のWeb検索を自律的に実行してトピックを調査し、収集した情報を統合してObsidian wikiに構造化された形で保存します。ユーザーが「/wiki-research [トピック]」「〜を調べて」「〜について徹底的に調査して」などと指示した場合や、Web情報をもとにした包括的な知識をwikiに直接まとめてほしいときに使用するスキルです。
description の原文を見る
> Autonomously research a topic via multi-round web search, synthesize findings, and file structured results into the Obsidian wiki. Use this skill when the user says "/wiki-research [topic]", "research X", "find everything about Y", "do a deep dive on Z", "autonomous research on X", or wants comprehensive, web-sourced knowledge on a topic filed directly into their wiki.
SKILL.md 本文
Wiki Research — 自動マルチラウンドリサーチ
あるトピックに関する自動リサーチループを実行し、発見内容を合成して、結果を Obsidian wiki に永続知識として保存します。
開始前に
- 設定の解決 —
llm-wiki/SKILL.mdの Config Resolution Protocol に従う (CWD から.env→~/.obsidian-wiki/config→ プロンプト設定を検索)。これによりOBSIDIAN_VAULT_PATHとOBSIDIAN_LINK_FORMAT(デフォルト:wikilink) が得られます。 $OBSIDIAN_VAULT_PATH/index.mdを読んで、wiki に既に何があるかを理解する — wiki が既にカバーしている内容を再リサーチしない$OBSIDIAN_VAULT_PATH/hot.mdが存在すれば読む — 最近のコンテキストが表示されます$OBSIDIAN_VAULT_PATH/references/research-config.mdが存在すれば確認する — ソースの優先度、スキップするドメイン、またはこのvaultの信頼性ルールを定義しているかもしれません
生成されたページで内部リンクを記述する際は、llm-wiki/SKILL.md (Link Format セクション) のリンク形式を OBSIDIAN_LINK_FORMAT 値を使用して適用します。
リサーチトピックが曖昧な場合はユーザーに確認します。その後、進めます。
リサーチ設定 (オプション)
vault に references/research-config.md が存在する場合、それを読んで定義されているルールを適用します:
- ソースの優先度 (例: 学術的ソースを優先、特定ドメインを避ける)
- スキップするドメイン
- 信頼性スコアリングの調整
- トピック固有の制約
ファイルが存在しない場合は、デフォルト設定で進めます。
ラウンド1 — 広範なサーベイ
目標: トピックの広い地図を得る。
- トピックを 3~5個の異なる観点 に分解 (例: 「ベクトルデータベース」の場合: それが何か、いつ使うか、主要な実装、トレードオフ、本番運用での落とし穴)
- 各観点について、さまざまな表現を使用して2~3回の
WebSearchクエリ を実行 - 観点ごとの上位2~3結果に対して、
WebFetch(または利用可能な場合はdefuddle <url>— よりクリーンな抽出) を使用してコンテンツを取得 - 取得したページから抽出:
- 主張 — ソースが明示的に述べていること
- 概念 — 導入されたアイデア、用語、フレームワーク
- エンティティ — 言及されたツール、人物、組織
- 矛盾 — ソース間で意見が一致しない箇所
進行に伴い、何がカバーされていて何が不足しているかを追跡します。
ラウンド2 — ギャップ埋め
目標: ラウンド1で残された穴を埋める。
ラウンド1の結果を確認:
- ソースが提起したが答えられなかった質問は?
- ソース間で矛盾している場所は?
- どの観点がカバーが薄い?
これらのギャップに特に対応した 最大5回の的を絞った検索 を実行します。リンク集約よりも一次情報源、公式ドキュメント、権威ある分析を優先します。
発見事項を作業セットに追加します。矛盾リストを更新します。
ラウンド3 — 合成チェック
目標: 矛盾を解決; 十分な深さが達成されたか確認。
重大な矛盾が未解決の場合:
- 1回の最終的な的を絞った検索 (2~3回の検索) を実行して権威ある解決を見つける
- 解決が不可能な場合は、合成ページで矛盾を明示的に指摘します
ラウンド2後に矛盾が軽微であるか、トピックが十分カバーされている場合は、追加検索をスキップして提出に進みます。
停止条件: 十分な深さが達成されたか3ラウンドが完了したら停止 — 無限にループしません。
提出 — Wiki ページを記述
すべての発見事項を4つの出力エリアにわたって wiki ページに整理します:
1. sources/ — 主要参照ごとに1ページ
重要なソースごとに (通常、合計4~8ページ):
---
title: >-
<Source title>
category: references
tags: [<2-4 domain tags>]
sources:
- "<URL>"
source_url: "<URL>"
created: <ISO-8601 timestamp>
updated: <ISO-8601 timestamp>
summary: >-
<このソースが何をカバーしているかを説明する1~2文、≤200文字>
provenance:
extracted: 0.X
inferred: 0.X
ambiguous: 0.X
base_confidence: <0.17 + 0.5 × classify(url) for a single source>
lifecycle: draft
lifecycle_changed: <ISO date today>
---
本文: タイトル、URL、カバー内容、主要な主張 (provenance マーカー付き)、制限事項。
2. concepts/ — 実質的な概念ごとに1ページ
ソース全体で浮上した重要な概念ごと:
標準的な概念 frontmatter + 本文。概念を互いに、またはソースページにリンクします。
3. entities/ — ツール、組織、人物
遭遇した重要なエンティティごと (ツール、ライブラリ、企業、主要な著者):
標準的なエンティティ frontmatter。エンティティを使用する概念と、それが表示されるソースにリンク戻します。
4. synthesis/Research: [Topic].md — マスター合成
主要な出力: 発見されたすべてのものの構造化された合成。
---
title: >-
Research: <Topic>
category: synthesis
tags: [<3-5 domain tags>, research]
sources: [<ソースURL またはページパスのリスト>]
created: <ISO-8601 timestamp>
updated: <ISO-8601 timestamp>
summary: >-
<トピック>に関する<N>ラウンドリサーチの合成。<≤200文字の主要な発見>をカバーします。
provenance:
extracted: 0.X
inferred: 0.X
ambiguous: 0.X
base_confidence: <min(N_unique_sources/3,1.0)×0.5 + avg_source_quality×0.5>
lifecycle: draft
lifecycle_changed: <ISO date today>
---
# Research: <Topic>
## Overview
<リサーチが何を発見したかの2~4文のエグゼクティブサマリー>
## Key Findings
<最も重要な主張の箇条書きリスト、各々に[[ソースページ]]引用付き>
## Core Concepts
<作成された概念ページへのリンク、1行の説明付き>
## Entities & Tools
<エンティティページへのリンク、1行の説明付き>
## Contradictions & Open Questions
<ソース間で矛盾している場所またはリサーチが限界に達した場所>
## Sources Consulted
<参照したすべてのソースページのリンク付きリスト>
クロスリンク
すべてのページを提出した後:
- すべての概念ページは少なくとも2つのソースページにリンクすべき
- すべてのソースページは、それが知らせた概念ページにリンクすべき
- 合成ページは生成されたすべての概念、エンティティ、ソースページにリンクすべき
index.md で同じトピックの既存ページを確認 — 重複を作成するのではなく既存ページにマージします。
トラッキングファイルを更新
.manifest.json — research エントリを追加:
{
"type": "research",
"topic": "<topic>",
"researched_at": "TIMESTAMP",
"rounds_completed": 3,
"sources_fetched": N,
"pages_created": ["..."],
"pages_updated": ["..."]
}
index.md — 該当するセクションの下にすべての新しいページを追加します。
log.md — 追加:
- [TIMESTAMP] WIKI_RESEARCH topic="<topic>" rounds=N sources_fetched=N pages_created=M
hot.md — Recent Activity をリサーチトピックと主要な発見で更新します。これが進行中であれば Active Threads を更新します。updated タイムスタンプを更新します。
品質チェックリスト
- 3ラウンド完了 (または十分な深さで停止)
-
synthesis/Research: [Topic].mdに合成ページが存在 - 主要な参照についてソースページが記述されている
- 重要な項目について概念とエンティティページが記述されている
- 合成ページで矛盾が指摘されている
- すべてのページがクロスリンクされている
-
index.md、log.md、hot.md、.manifest.jsonが更新されている
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- ar9av
- リポジトリ
- ar9av/obsidian-wiki
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/ar9av/obsidian-wiki / ライセンス: MIT
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理(非同期ジェネレータを含む)、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。