updating-knowledge

ナレッジの更新

基本原則

• 場当たり的な対応より体系的な対応 - 調査手法に従い、無作為に検索を繰り返さないでください
• クロスチェック - 複数の独立した情報源で主張を検証してください
• 確信度の追跡 - 単一の情報源に基づく主張や不足情報を明示してください
• 簡潔な出力 - 調査結果は効率よく提示し、内省は思考ブロックに記載してください

事前確認

このスキルを使用するには、web_search ツールへのアクセスが必要です。

続行する前に、利用可能かどうか確認してください。利用できない場合は、すぐにユーザーに伝えてください。 「調査タスクにはウェブ検索を有効にする必要があります。機能メニューで「ウェブ検索」をオンにしてください。」 そして、記憶だけを頼りに調査したり、回避策にコンテキストを費やしたりせず、そこで終了してください。

トリガーの判別

「更新」のような一般的な動詞だけでトリガーしないでください（ファイルやコードの変更を意味する場合があります）。上記の説明にある、知識を集める明確な依頼に基づいてトリガーしてください。

調査ワークフロー

1. 範囲の定義（内部）

思考ブロックで以下を特定します。

• 具体的に何を調査する必要があるか
• 現時点での知識の基準
• 既知の不足情報
• 必要な深さ（概要か、包括的な調査か）

2. 情報源の収集（ツール呼び出し 2～10 回）

情報源の優先順位：

1. 公式ドキュメント、プロジェクトのリポジトリ、企業の発表
2. 学術論文、専門性が明確な技術ブログ
3. コミュニティでの議論（エコシステムの背景情報に限る）

ツールの選択：

• web_search - 信頼できる情報源を探す
• web_fetch - 事前の検索なしで、任意の URL から全コンテンツを取得する
• 内部ツール（GitHub、Drive など）- 企業や個人のコンテキストを確認する
• 必要に応じて複数のツール種別を使用する

クロスチェックのため、最低 3～5 件の多様な情報源を収集してください。

3. 統合（内部）

思考ブロックで以下を行います。

• 主要な主張を複数の情報源でクロスチェックする
• 矛盾があれば明示する
• 公開日を記録する
• 情報源の信頼性を評価する
• 残っている不足情報を特定する

4. 出力（簡潔に）

調査結果を簡潔に提示します。

## [Topic]

**Key findings:**
[2-3 sentence summary with most important updates]

**Current state:**
[Concise description of what's true now]

**Changes since cutoff:**
[Only if relevant - what's different]

**Gaps:**
[Only if user needs to know - what wasn't found]

Sources: [URLs]

確信度の指標：

• 単一の情報源に基づく主張である場合は、明示してください
• 情報源間の矛盾を記載してください
• 未検証の情報に印を付けてください
• 不確かな場合は、確信度（高／中／低）を示してください

品質基準

最低要件：

• 独立した情報源を 3 件以上確認する
• 主要な主張をクロスチェックする
• 確信度を明示的に評価する
• 関連する場合は、残っている不足情報を特定する

避けること：

• 単一の情報源に基づく主張を、確定事項として提示する
• 公開日を無視する
• マーケティング表現を事実として扱う
• 最終出力で長々と検討内容を述べる（思考ブロックを使用してください）
• 調査プロセスをユーザーに過度に説明する

ツールの使用に関する注意

web_fetch の機能：

• 事前の検索結果がなくても、任意の URL を直接取得できます
• ドキュメントページや技術記事全体の取得に使用します
• 検索で情報源を特定した後、内容を深く抽出するのに効果的です

web_search のパターン：

• 具体的な検索から始め、必要に応じて範囲を広げます
• 似た検索を繰り返さないでください。検索ごとに内容を変えてください
• 関連する場合は、実際の現在の日付を使用してください。推測せず確認してください

内部ツール：

• 企業や個人のデータには、内部ツールを優先してください
• 比較分析には、ウェブツールと組み合わせてください

出力例

技術ドキュメントに関する問い合わせ：

TypeScript 5.3 (Nov 2023) added import attributes for JSON modules. The syntax uses `with` instead of deprecated `assert`. Runtime performance unchanged—validation happens at parse time.

Gap: No official benchmarks comparing validation overhead across bundlers.

Sources: [TS release notes, GitHub issue #54242, esbuild docs]

情報が矛盾する場合：

React Server Components ship in Next.js 13.4+ (stable) and Remix 2.0 (experimental). 

Contradiction: Meta's blog claims "production-ready" while Remix docs flag "breaking changes expected." Cross-validation shows Meta refers to Next.js implementation only.

Confidence: High on Next.js status, medium on Remix timeline.

Sources: [Next.js changelog, Remix docs, React.dev]

プロセスを語らない：

❌ "After conducting extensive research and cross-validating multiple authoritative sources..."
✓ Just present findings with source attribution