mcpField
F
find-key-internal-sources

find-key-internal-sources

github.com/openaiマーケティング・グロース56040 回インストール4 週間前に更新
リポジトリ

find-key-internal-sources について

find-key-internal-sources は、社内の担当者、管理されたドキュメント、チャンネル、意思決定の場を探す営業担当者向けの読み取り専用スキルです。根拠付きの簡潔なルート案と最初の問い合わせ文案を作り、投稿やシステム変更は行いません。

主な機能

  1. 01担当者、ドキュメント、チャンネルへの案内
  2. 02正規の社内ソースを優先
  3. 03関連性と根拠に基づく候補の順位付け
  4. 04既定で検索範囲を限定
  5. 05送信せずに最初の問い合わせを作成
  6. 06網羅性の不足と確信度の制約を明示

活用シーン

  1. 01顧客や製品の質問に関する担当者探し
  2. 02承認済みガイダンスや管理文書の検索
  3. 03適切な公開サポートチャンネルの特定
  4. 04ブロッカーのエスカレーションと意思決定経路の整理

インストール

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

$npx skills add https://github.com/openai/role-specific-plugins --skill find-key-internal-sources

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
references/
company-context.md
search-patterns.md

詳細

重要な社内情報源を見つける

販売担当者が回答を得たり、作業を進めたりするのに役立つ、信頼できる最小限の社内ルートを見つけます。対象は、適切な担当者、維持管理されているドキュメント、公開チャンネル、意思決定の場、エスカレーション経路です。通常の出力は、根拠に基づく簡潔なルート案内と、そのまま送信できる最初の問い合わせ文案です。このワークフローは読み取り専用であり、投稿、割り当て、システムの更新は一切行いません。

共通スキルの指示

必須:まだコンテキストに含まれていない場合は、plugins/sales/skills/index/SKILL.md## Cross-Skill Best Practices を読み、厳密に従ってください。

主な依存カテゴリ

選択したルートに必要なカテゴリだけを使用します。デフォルトでは、すべての情報源を横断して検索しないでください。

  • ~~Knowledge & Files:維持管理されている信頼できる情報源のページ、担当者メタデータ、Wiki、フィールドガイド、プレイブック、FAQ、ランブック、ローンチ資料、意思決定記録
  • ~~Internal Messaging:公開チャンネル、チャンネルトピック、スレッド、活動中の貢献者、エスカレーション経路、サポートチャンネル、意思決定の場
  • ~~CRM:顧客またはアカウントの識別情報、担当者、商談の状況、アカウント固有の質問を明確にするCRMで確認可能な障害要因

チャットでの言及より、正式な担当者情報と信頼できる情報源を優先してください。~~CRMはアカウントに関する事実の確認には使えますが、それだけでは社内の回答の担当者を特定できません。

参照資料の読み込み

通常のルート選択、範囲を限定した検索、順位付け、出力マップについては、SKILL.md に従います。参照資料は、追加の詳細が必要な場合にのみ読み込みます。

  • クエリの検索範囲、複合ファセット、情報源ごとの検索、または検索の終了条件について詳しく確認する必要がある場合は、references/search-patterns.md を使用します。
  • 一般的な検索を行った後、ユーザー提供またはコネクターで確認できる用語によってルートが変わりそうな場合にのみ、references/company-context.md を使用します。

用語

  • 信頼できる情報源のページ: 最も権威ある回答の情報源として扱うべき、維持管理されているドキュメント、Wiki、トラッカー、またはページです。
  • DRI: 直接の責任者。トピック、意思決定、またはその後の対応に責任を負う人です。
  • SME: 分野の専門家。責任者でなくても、トピックについて実務的な深い知識を持つ人です。
  • 意思決定の場: 選択肢の検討や承認を行う、定期的な会議、チャンネル、ドキュメント、またはグループです。

ワークフローのガイダンス

1. トピックとルートを特定する
  • 具体的な topic_or_task を必須とします。対象には、顧客からの質問、製品に関するトピック、異議、実装上の問題、アカウントの障害要因、取り組み、信頼できる情報源の不足が含まれます。
  • 明確な場合は、現在のスレッドまたは提供された営業関連の出力から推測します。それでも曖昧な場合は、最大3件の情報源を読む範囲限定の候補検索を行ってから、具体的な候補を最大5つ挙げ、親しみやすく質問を1つします。
  • 会社名のようにも見える曖昧な名称は、アカウントの手がかりである可能性も考慮します。アカウント固有のルート案内を社内ドキュメントやメッセージに頼る前に、利用可能であれば範囲を限定して~~CRMを検索します。
  • デフォルトでは簡易検索を行います。詳細検索は、依頼された場合、または重要性の高い質問でより幅広い裏付けが明らかに必要な場合にのみ使用します。

依頼を満たす最小限の回答ルートを選択します。

  • owner_route — 誰が担当、承認、把握しているか、または誰に連絡すべきか
  • doc_route — 何を読むべきか、どのページが維持管理されているか、またはどの表現が承認済みか
  • channel_route — どこで質問、議論、エスカレーション、またはサポートの依頼をすべきか
  • full_map — 依頼で専門家、ドキュメント、チャンネルのすべてが本当に必要な場合に、それらをまとめて提示します
2. まず正規の情報源を検索する
  • owner_route では、まず保守されている担当情報、ディレクトリ、ルーティング、または信頼できる唯一の情報源となるページを確認し、現在の慣行の確認や不足情報の補完にはメッセージを使います。
  • doc_route では、まず保守されているドキュメント、タイトル/見出しの一致、リンクされたハブ、担当者欄、更新時期を確認し、ランキングの前に最有力候補だけを取得します。
  • channel_route では、まず公開チャンネル名、トピック、目的、文書化されたエスカレーション経路を確認し、確度が変わる場合に限り最近の公開スレッドを確認します。
  • ルートが顧客固有の場合は、アカウントの特定と商談の状況把握に ~~CRM を最初に使い、その後、社内の担当者を確認するために ~~Knowledge & Files または ~~Internal Messaging を使います。
  • quick では、正規の情報源を一度試し、最初の検索結果が空、情報不足、または誤解を招く場合に限り、範囲を絞った代替検索を一度行います。最有力候補ごとに取得またはスレッドの閲覧は最大一度までにします。
  • 最初の検索結果が弱い場合、トピックが異なる複数の情報面にまたがる場合、またはユーザーが詳細な調査を求めている場合に限り、検索範囲を広げます。根拠のある適切なルートが見つかった場合、結果が安定した場合、または追加検索で確度の低い重複候補しか得られない場合は終了します。
3. 役立つ検索ファセットを組み立てる
  • まずトピックの正確な用語を使い、次に別名、略語、旧称/現行名、製品名/チーム名、担当者、承認、ポリシー、ランブック、プレイブック、FAQ、サポート、エスカレーションなど、タスクの性質を表す語句を追加します。
  • 複合的な質問では、製品/アカウントの情報面と、管理/プロセスの情報面を分けて検索します。ポリシーに関する有力な検索結果で製品のルーティングを代替したり、ローンチページで承認担当を代替したりしないでください。
  • クエリの展開、情報源別の検索、または検索の終了ルールについて詳しい情報が必要な場合は、references/search-patterns.md を使います。
  • 会社固有の用語は、ユーザーまたはコネクターから確認できる信頼できる情報源に由来する場合に限り使います。社内の名称、チャンネルのパターン、URL、担当者に関する慣例をでっち上げないでください。
  • 組織固有の検索語の展開は、一般的な候補の取得後にのみ適用し、基本スコアを優先します。コンテキストに基づく候補ごとのブースト合計は +0.25 を上限とします。
4. 候補を取得し、スコアを付けてランク付けする

候補を種類、タイトルまたは名前、URL、情報源、根拠、担当者のシグナル、新しさで正規化します。ほぼ同一の項目は重複を排除します。

以下の基準でランク付けします。

  1. 求められている回答ルートとの直接的な関連性
  2. 権威性と保守状況を示すシグナル
  3. 新しさ
  4. 複数の情報源による裏付け
  5. 営業担当者の次のアクションにとっての実用性
  • プロフィールだけ、または言及だけに基づく一致より、根拠を直接示すリンクを優先します。
  • 単発のメモより、保守されている信頼できる唯一の情報源となるページ、現場向けガイド、FAQ、プレイブックを優先します。
  • トピックに言及しているだけのチャンネルより、トピック、目的、リンクされたガイド、または最近のスレッドから担当への経路が確認できるチャンネルを優先します。
  • 主に ~~Internal Messaging から推定した人物については、最近の担当または専門性を示すシグナルを必須とし、特に指定がなければ過去90日以内のものを基準にします。古い候補は除外するか、順位を下げます。
  • 無効化済みまたは非アクティブなユーザーは除外します。特に指定がない限り公開チャンネルのみを対象とし、プライベートチャンネル、グループDM、ダイレクトメッセージ、または外部共有チャンネルを含めるのは、ユーザーが明示的に求め、アクセスが適切な場合に限ります。
  • トピックが製品/GTM のガイダンスと、ポリシー、セキュリティ、実装、価格設定、または承認の担当にまたがる場合は、それぞれ異なるルートを維持します。
5. ルーティングマップを作成する
  • リクエストに必要な深さだけを返します。単一のルートの場合、他の必須セクションは「クイックパスでは検索していません」または「信頼度の高い候補は見つかりませんでした」として簡潔にまとめます。
  • 各候補の回答経路の種類を説明します。DRI、承認者、SME、メンテナー、責任を負うチーム、意思決定の場、ローンチ責任者、エスカレーション窓口、サポート窓口、フィードバック窓口などです。
  • 1行の根拠、入手可能な場合は直接リンク、証拠となる情報、信頼性に関わる場合は鮮度または確信度を含めます。
  • ユーザーの表現で2つの対象が混同されている場合は、その違いを説明する短い補足を加え、情報源の安全性がその違いによって変わらない限り、両方のルートを提示します。
  • 推奨する最初の問い合わせには、最適な担当者または公開チャンネルに販売担当者が送信できる具体的な文案を含めます。チャット上で文案を作成し、投稿はしません。
  • 対応範囲の不足には、利用できないカテゴリまたは根拠が弱いカテゴリ、確信度への影響、最小限の有効な次のステップを記載します。
次のステップの選択肢

最初の出力の後、以下の選択肢から最も関連性の高いフォローアップを提案します。メニューではなく、明確な移行を1つ提示してください。別の選択肢のほうが明らかに有用であると確信できる場合を除き、以下のみを提案します。

  • 推奨する担当者、専門家、または公開チャンネルへの最初の問い合わせ文案を作成する。
  • ユーザーの質問に関する最も信頼できる情報源の文書を開き、その内容をまとめる。
  • 推奨されるルートでエスカレーションが必要な場合、簡潔なエスカレーションメモを作成する。
  • 確認済みの担当者、文書、チャンネル、注意事項を含む、再利用可能なルーティングメモを作成する。
  • 担当者または承認に関する不足を解消できる、最小限の情報源を見つける。

避けるべき次のステップ:

  • 自動で投稿、割り当て、エスカレーション、または担当者情報の更新を行うこと。

モード

  • quick — デフォルト。エキスパート、文書、チャンネルについてそれぞれ最大3件を、範囲を限定して検索します。
  • deep — 根拠の質が十分な場合に、それぞれ5〜8件を提示します。
  • owner_route、doc_route、channel_route、full_map — 回答形式を指定するルートです。quick または deep と組み合わせて使用します。

出力形式

# Internal Routing Map: [Topic]

[Optional framing note when the topic spans distinct ownership surfaces.]

## Experts
- **[Name / team]** — [DRI / approver / SME / other type]; [why this route]. [Evidence link] · [confidence/freshness]

## Docs
- **[Doc]** — [source-of-truth / field guide / FAQ / other type]; [why it matters]. [Link] · [confidence/freshness]

## Channels
- **[#channel]** — [support / escalation / decision forum / other type]; [why ask here]. [Link] · [confidence/freshness]

## Recommended First Ask
> [Draft-ready question or handoff, addressed to the best owner or public channel.]

## Coverage Gaps
- [Missing or weak source, confidence impact, and smallest useful next step]

---

{Follow the instructions and output format/conditions in [Limitations and Improvements](../index/SKILL.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../index/SKILL.md#4-next-steps)}

プロンプト例

  • Find the key internal sources for a customer question.
  • Find who owns the Enterprise SSO rollout path for ExampleCorp.
  • Find the docs and channels for answering a customer's security review question.
  • Route this implementation blocker to the right internal people and source of truth.

ルール

  • 担当者、専門家、チャンネル、文書、信頼できる情報源への経路、リンク、または担当の確実性を捏造しないでください。
  • 事実と推測を分けてください。担当が不確かな場合は「可能性が高い」または「可能性がある」と明記します。
  • ルーティングマップの作成段階では、読み取り専用を維持してください。投稿、送信、割り当て、更新は行わないでください。
  • ノイズの多い長いリストより、信頼度の高いルートを少数提示してください。
  • 役立つリンクがある場合は、常にハイパーリンク付きで情報源を明記してください。リンクがないことが重要な場合は、「有用なリンクはありません」と記載します。

コメント