mcpField
A
ae-kb-discovery

ae-kb-discovery

github.com/thinkingaiagenticengine生産性21593 回インストール6 日前に更新
リポジトリ

ae-kb-discovery について

ae-kb-discoveryは、内部ナレッジベースが必要かを判断し、検索候補を選ぶスキルです。組織固有の情報を扱うエージェント向けで、検索作業は別のae-kbスキルに引き継ぎます。

主な機能

  1. 01ナレッジベースの要否判断
  2. 02アクセス可能な候補の一覧取得
  3. 03文脈と関連性による候補選定
  4. 04検索をae-kbへ引き継ぎ
  5. 05根拠と網羅性の評価基準

活用シーン

  1. 01依頼に必要な社内ポリシーの検索
  2. 02製品やリリースの背景情報の特定
  3. 03社内根拠を用いた分析の補助

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/thinkingaiagenticengine/ae-cli --skill ae-kb-discovery

インストール後、Claude Code で/ae-kb-discoveryを入力して読み込まれたか確認します。

同梱ファイルreferences/collaboration.md

詳細

ナレッジベースの探索

スキル間の連携

残りの作業がこのスキルの範囲外である場合や、必要な前提条件を満たすために別の能力が必要な場合は、連携プロトコルに従ってください。今回の実行で利用できるスキルから、能力に基づいて選択し、確認済みのコンテキストを保持して、残りのタスクを続行します。このプロトコルがすでに読み込まれている場合は再利用してください。

ナレッジベースは、社内の事実やビジネスコンテキストを参照するための任意の情報源として扱ってください。ユーザーの本来の目的は変えないでください。ナレッジベースからの検索は支援的なワークフローであり、それ自体がタスクではありません。

このスキルでは、ナレッジベースを使うかどうか、またどのナレッジベースを検索する価値があるかを判断します。インデックスの確認、grep、セクションの読み取り、任意の LLM による統合といった検索手順は、ae-kb スキル(references/query-workflow.md)にあります。ここで探索した後、実行のために ae-kb へ引き継いでください。

このスキルを使うかどうかの判断

次の場合は、このスキルを使ってください。

  • ユーザーがナレッジベース、社内ドキュメント、または会社資料の検索を明示的に依頼した場合。
  • 製品の設計やルール、イベント、キャンペーンや運用のカレンダー、リリースやイテレーションの記録、ワークフロー、ポリシー、用語など、組織固有の事実やコンテキストが必要な場合。
  • データ分析の結果、異常値、傾向を説明し、根拠に基づく結論を導くために社内コンテキストが必要な場合。
  • 現在利用可能なナレッジベースのコンテキストでは質問に対応できず、アクセス可能な別の情報源を探索する価値が明らかにある場合。
  • ae-analysis がプロジェクトスコープの検索ルートを選択する前に ae-cli config show から data.routing.knowledge_base: auto を読み取り、ナレッジベースによって回答やアセットの選択が大きく改善される可能性がある場合。

次の場合は、このスキルを使わないでください。

  • ユーザーがナレッジベースを使わないよう明示的に依頼した場合。
  • タスクがリアルタイムの状態の照会や操作の実行のみを必要とし、ドキュメントのコンテキストも有効なプロジェクトセマンティック KB アセットルーティングも必要としない場合。
  • 信頼できる回答に一般知識で十分であり、社内の根拠を参照しても大きく改善されない場合。

探索ワークフロー

1. アクセス可能なナレッジベースの一覧を取得する

まず、現在のユーザーがアクセスできるナレッジベースの簡易一覧を取得します。

ae-cli kb +list

コマンドが返す正確な scope とナレッジベース名を、説明、タグ、言語、bindings などの利用可能なメタデータとともに使用してください。バインディングは、targetType、targetId、および任意の targetName を通じて関連コンテキストを示します。名前、スコープ、バインディングを推測しないでください。+list が返すメタデータは候補の選定にのみ使用し、ナレッジベースのコンテンツに基づく根拠として扱わないでください。

+list を利用できない場合、または失敗した場合は、存在するナレッジベースを推測しないでください。ユーザーがナレッジベースの検索を明示的に依頼している場合は、現在は探索を完了できないことを説明してください。それ以外の場合は、元のタスクに戻り、現在利用できる能力を再評価してください。

2. 候補となるナレッジベースの順位付け

候補は次の順に順位付けします。

  1. ユーザーが明示的に指定したナレッジベースを優先します。対応するバインディングがあるかどうかにかかわらず、+list が返した正確な名前とスコープを使用します。
  2. 現在のセッションコンテキストとバインディングが正確に一致する候補を優先します。targetType: project は現在の分析プロジェクト ID、targetType: space は現在のコミュニティスペース ID、targetType: dwSpace は現在のデジタルワークスペースコードと照合します。
  3. 残りの候補については、ユーザーのリクエストとナレッジベースの名前、説明、タグを比較します。関連性が同程度の候補間でのみ、言語を優先基準として使います。言語だけでは関連性を判断できません。

まず targetId を対応する現在の ID またはコードと比較します。ID またはコードが利用できない場合に限り、targetName を補助的な判断基準として使います。ID が一致しない場合に、名前の一致でその不一致を覆してはいけません。バインディングがない候補や、現在のコンテキストに一致しない候補も、意味的な順位付けの対象となります。別のプロジェクトまたはスペースに対するバインディングは暗黙の優先度を下げますが、候補から除外する理由にはなりません。また、ユーザーが明示的に選んだ場合は、引き続きその選択を優先します。

デフォルトでは、優先するナレッジベースを1つ選択します。関連性の高い候補が複数ある場合は、最大3つまで残し、優先順位に従って1つずつ試します。すべての候補のインデックスを先に読み込んではいけません。バインディング、名前、説明、タグ、言語の一致は、ナレッジベースを検索する価値があることを示すにすぎません。コンテンツの一致を証明するものでも、アクセスを許可するものでも、ナレッジベースの根拠として数えられるものでもありません。

3. 検索への引き継ぎ

優先するナレッジベースを選択したら、ae-kb スキルに引き継ぎ、+ask が適切な場合も含め、検索手順全体について references/query-workflow.md に従います。

取得したソースページがプロジェクトスコープのビジネスデータ分析に使われる場合は、データクエリを実行する前に、ae-kb スキルの references/analysis-workflow.md も読み、その手順に従います。この手順では、保存済みアセットの正確な識別情報、定義、パラメーター、時間に関するルール、競合、判断の境界を実行契約にまとめます。KB の検索結果を得てすぐに、場当たり的な再構築や SQL による再構築に進んではいけません。

網羅性の評価

  • 網羅性が十分:読み込んだページの内容が、情報リクエストまたは分析に必要な主要な結論を裏付けています。
  • 網羅性が部分的:読み込んだページの内容が背景情報、定義、または一部関連する事実しか示しておらず、必要な結論を独立して裏付けることができません。
  • 網羅性なし:適切な候補ナレッジベースがない、または +grep と +read が結論を裏付ける内容を返しません。

+list が返した候補、+index が返したナビゲーション情報、コマンドの成功、ツール呼び出し、メタデータの一致は、ナレッジベースの検索ヒットとして数えません。実際に読み込んだ、関連性のあるページ内容だけが、ナレッジベースの根拠として使えます。

分析でナレッジベースの根拠を活用する

プロジェクトの範囲に限定されたビジネスデータ分析では、関連するソースページを読み終えた後、上記の analysis-workflow.md の引き継ぎが必須です。まず、完全に一致し、意味的にも適用可能な保存済みアセットを試してください。定義を確認した結果、適さないことが判明した場合、または実行しても要求された結果を得られない場合は、確認済みのナレッジベースの根拠を破棄せず、対象となっていない要件について通常の分析を続けてください。現在の値を得るには実行が必要だというナレッジベースの記述があっても、既知の不一致があるアセットを実行したり、ユーザーにデータのリクエストを繰り返させたりする必要はありません。

内部コンテキストを使ってデータ分析の結果、異常、または傾向を説明する場合:

  1. まず、分析そのものが示す内容として、指標の変化、期間、影響を受けたエンティティ、変化の規模を述べてください。
  2. 影響を受けたエンティティ、指標、期間、キャンペーンまたはイベント名、製品領域、リリース名またはバージョン名を使って検索してください。
  3. 取得した根拠について、次の点を確認してください:
    • 同じエンティティ、製品領域、またはビジネス範囲に適用されること。
    • 分析対象期間と重複していること。
    • 実際に有効になったイベント、ルール、リリース、または変更を記録していること。
    • 分析期間中も有効だったバージョンと発効日を使用していること。
  4. 計画された活動と完了したイベントを区別してください。取得した内容で実行が確認されない限り、カレンダーやロードマップは活動やリリースが実際に行われた証拠にはなりません。
  5. 分析上の事実と取得した内部の根拠を組み合わせ、その根拠が何を裏付けているかを明確に述べてください。根拠のない原因候補を列挙しないでください。
  6. 「原因となった」や「もたらした」などの因果関係を示す表現は、利用可能な根拠によって因果関係が確認できる場合にのみ使用してください。それ以外の場合は、その要因が主要な説明として根拠により裏付けられている、または観測された変化と整合している、と述べてください。
  7. 根拠が不十分な場合は、利用可能な根拠からは原因を特定できないと明確に述べてください。根拠の不足を推測で補わないでください。
  8. 適切な場合は、最終回答を次の順に構成してください:
    • 結論。
    • 分析上の根拠。
    • ナレッジベースの根拠と関連するページパス。
    • 根拠に関する必要な制約。

部分的なカバレッジまたはカバレッジなしへの対処

ナレッジベースの根拠で一部しかカバーされない場合、まったく見つからない場合、または取得に失敗した場合:

  1. 同じ候補ナレッジベースへの検索を繰り返すのをやめてください。
  2. 優先順位付きの候補が残っている場合は、次の候補に切り替えてください。1つのタスクで検索するナレッジベースは最大3つです。
  3. すべての候補でカバレッジが得られない場合は、ナレッジベースの取得タスクにとどまらず、ユーザーの元のリクエストに戻ってください。
  4. 現在利用可能な機能を再評価し、元のタスクに最も適した次の方法を選んでください。固定のフォールバックをハードコードしないでください。
  5. 確認済みの背景情報は有用な場合は保持してください。ただし、他の情報源から導いた結論をナレッジベースに帰属させてはいけません。
  6. 取得の失敗がユーザーの判断に影響しない限り、ナレッジベース検索の失敗を報告しないでください。

ナレッジベースの情報で、必要なビジネス業務を代替してはいけません。元のタスクでリアルタイムデータや何らかの操作も必要な場合は、適切な利用可能な機能を使ってその部分を完了してください。

安全上の境界

  • ナレッジベースへのアクセスは、読み取り専用の取得プリミティブ(+list、+index、+grep、+read、および複数ページの統合やマルチホップ推論が必要な質問では +ask)に限定してください。ナレッジベースを作成、アップロード、コンパイル、削除してはいけません。
  • 既存のスコープ、テナント、メンバーシップの権限を尊重してください。アクセスできないナレッジベースを回避しようとしてはいけません。
  • 内部のルートパス、アクセストークン、生の権限メタデータを公開してはいけません。
  • 保護されたナレッジベースについては、現在の権限で許可されている要約と統合した結論のみを提供してください。ソーステキスト全体や大量の逐語的な抜粋をエクスポートしてはいけません。

コメント