analyze-account-signals

アカウントシグナルを分析する

コンテキスト収集のための受付

このスキルがコンテキストを求める場合は、request_user_input などのツールよりも、answers-ask-user-input スキルと ask_user_input ツールを優先して使用してください。それ以外の場合は、会話内で直接質問してください。

新たなアカウントの証拠をもとに、何が変わったのか、なぜ重要なのか、次に何をすべきかを簡潔にまとめます。このスキルが扱うのは、読み取り専用のアカウント概要または範囲を限定したウォッチリストの要約です。タスクの作成、ダイジェストの投稿、監視状態の保存、CRMの更新は行いません。

共通のスキル指示

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

主な依存関係のカテゴリ

このワークフローでは、次のカテゴリが特に重要です。シグナルの把握が実質的に改善される場合に限り、ほかの情報源を使用してください。

• [ブロッキング] ~~アカウントの正式な識別情報、担当者、商談、ステージ、金額、活動、顧客の健全性、アカウントステータスを正確に把握するためのCRM。十分に完全なアカウント情報がすでにコンテキストに含まれていない限り、デフォルトのアカウントシグナルの読み取りを妨げます。
• ~~直近の顧客の発言、決定、約束、異議、フォローアップ、関係者の動向を把握するためのミーティングの文字起こし
• ~~顧客とのやり取りの進捗、未回答の依頼、トーンの変化、添付ファイル、約束した次のステップを把握するためのメール
• ~~社内調整、障害、関係者間の連携、エスカレーションの兆候を把握するための社内メッセージ
• ~~アカウント計画、メモ、概要、実装ドキュメント、過去のアカウントコンテキストを把握するためのナレッジとファイル
• ~~最近または今後の顧客とのセッション、約束、大規模なポートフォリオの範囲縮小を把握するためのカレンダー

デフォルトのアカウントの基準情報として ~~CRM を使用してください。CRMを使用できない場合に限り、ユーザーから提供またはエクスポートされた十分なアカウント情報を代替手段として使用してください。コミュニケーション、ファイル、カレンダーから得られる証拠は、情報の新しさや変化の説明に役立ちますが、CRMが管理するアカウントや商談のフィールドを上書きするものではありません。

リファレンスの読み込み

通常のモードの使い分け、取得範囲の制限、出力形式は SKILL.md が定めています。追加情報によって判断が変わる場合に限り、リファレンスを読み込んでください。

• 構造化入力、旧式の別名、セレクターの優先順位、機械可読な出力形式が重要な場合は、references/request-schema.yaml を使用してください。
• シグナルの分類、信頼度、情報の新しさ、順位付け、差分ステータス、表示ラベルが曖昧な場合は、references/signal-taxonomy.md を使用してください。

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

1. モードとスコープを選択する

• モードが明確でない場合は、ask_user_input() でユーザーに確認します。「アカウントのシグナルを分析して」のような単独の依頼でも、Adhoc Account Brief または Monitor Summary と決めつけず、次の選択肢を提示します。
  • Adhoc Account Brief for one account
  • Monitor Summary for accounts I own in CRM
  • Monitor Summary for a watchlist, owner, or territory
• 名前が指定された1つのアカウント、または「[account] に何か変化はありましたか？」という依頼には、Adhoc Account Brief を使用します。ユーザーが Adhoc を選択していても、アカウント、ドメイン、CRM ID のいずれも指定していない場合は、ask_user_input() を使って具体的なアカウント候補を最大5件まで検索、順位付けして提示します。ユーザーが1件を選択するまでは、より詳細な証拠を取得したり、ブリーフを作成したりしないでください。
• 担当者、地域、ポートフォリオ、ウォッチリスト、日次モニタリング、または「注意が必要なアカウントはどれですか？」という依頼には、Monitor Summary を使用します。ユーザーが Monitor を選択していても、ウォッチリスト、担当者、地域、ポートフォリオのいずれも指定していない場合は、次の選択肢を提示します。
  • Accounts I own in CRM
  • A named owner or territory
  • A watchlist or account list I provide ユーザーがスコープを選択するまでは、代表的な営業担当者のアカウントに範囲を広げたり、より詳細な証拠を取得したりしないでください。
• Adhoc ではアカウントを必ず1つにします。Monitor では、ウォッチリスト、担当者、地域、ポートフォリオ、または十分に詳細なアカウントリストが必須です。
• ユーザーから別の期間が指定されない限り、直近14日間をデフォルトとします。拡大、解約、展開の阻害要因、関係者の動きなど、指定された重点領域は維持します。
• sfdc_account_id を crm_account_id の旧式の別名として受け付けます。構造化入力とプロンプトの文言が矛盾する場合は、構造化入力を正として扱い、確定したスコープを明示します。
• モードとスコープが確定した後、起点となる情報が曖昧な場合は、質問する前に範囲を限定した候補検索を行います。利用可能であれば ~~CRM から開始し、ソースの読み取りは最大3回までとし、具体的な候補を最大5件提示します。
• 現在の会話で提示した具体的な候補に対して、ユーザーが okay と答えた場合は、候補の中から最近のもの、重要と思われるもの、またはシグナルの強いものを選び、処理を飛ばさないでください。適切なアカウント、担当者のポートフォリオ、ウォッチリストが見当たらない場合は、簡潔な確認質問を1つ行います。

2. 対象アカウントの範囲を限定し、確定する

• Adhoc では、安定した CRM ID、完全一致する名前またはドメイン、あるいはユーザーが提供した十分に詳細なアカウント情報を使って、アカウントを1つ特定します。
• Monitor では、明示的に指定されたウォッチリストをスコープ全体として扱います。それ以外の場合は、~~CRM で指定された担当者、地域、またはポートフォリオを使い、範囲を限定して最初の検索を行います。
• 担当者をスコープとする Monitor では、主要担当者のスコープを優先します。プロバイダーが続きの結果があると示している場合に限りページネーションを行い、アカウントが50件集まった時点で終了します。
• 主要担当者の検索でアカウントが0件であり、ユーザーが明示的にアカウントチーム、地域、役割、協力者、または Go-to-market に紐づく対象を指定している場合は、選択された ~~CRM アプリでサポートされているフィルターを使い、同じ上限を適用して1回だけ再試行します。
• 範囲を広げた再試行がタイムアウトまたは失敗した場合、主要担当者の検索結果があればそれを使って続行します。結果がない場合は、ウォッチリストまたはより狭い担当者スコープを求めます。
• Monitor の対象は最大50アカウントとします。特定した対象が50件を超える場合は、~~Calendar で今後14日間の顧客との外部ミーティングを使って50件以下に絞ります。それでも絞り込めない場合は、任意の一部を選ぶのではなく、より狭いスコープを求めます。
• 名前またはドメインの完全一致を優先し、候補となるアカウントが複数残っている場合は、リゾルバーの最上位の結果を無条件に信頼しないでください。

3. 最近のエビデンスを範囲を限定して収集する

• 選択した各アカウントについて、まず主要な ~~CRM の実態とユーザー提供のコンテキストを収集します。現在進行中のワークストリームを説明するアカウント計画やメモには、~~Knowledge & Files を使用します。
• Adhoc の場合、または主要なエビデンスが不十分な場合は、関連性に応じて次の順序で選択的に調査を深めます：~~Email、~~Knowledge & Files、~~Meeting Transcripts、Internal Messaging、次にCalendar。
• Monitor の場合は、個々のアカウントの調査を深める前に、対象アカウント全体について範囲を限定した主要な確認を完了します。重要な変化の可能性、曖昧さ、または価値の高いリスク／機会があるアカウントのみ、調査を深めます。
• 独立したアカウントの検索のみを並列化し、実用上の上限は一度に10件とします。バッチのタイムアウトやスキーマエラーは呼び出し形式の失敗として扱い、ソースが利用できない証拠とは見なしません。失敗したアカウントは、利用可能であれば安定したアカウント ID を使って一度再試行し、その後は利用不可としてマークし、取得に成功したアカウントの処理を続けます。
• 最近の状況を裏付ける情報が得られた時点で終了します。最新性を確認するためのソースを確認して該当する情報がなかった場合、その不在が信頼度に大きく影響するなら checked/no match と記載します。

4. シグナルを正規化し、スコア付けして解釈する

• エビデンスを references/signal-taxonomy.md の固定分類に従って正規化します。ユーザーがワークフローの拡張を明示的に指示した場合を除き、新しいシグナルラベルを作成しないでください。
• 各シグナルについて、種類、概要、ソース、最新性、信頼度、エビデンス、引用、推奨アクションをすべて保持します。
• 同じ出来事を説明する複数のソースは重複排除します。裏付けがあれば信頼度を高め、エビデンスが弱い、古い、矛盾している、または裏付けがない場合は信頼度を下げ、しばしばエビデンスのギャップとして扱います。
• 実行可能なアカウントリスクと、担当者の空白、ルーティング項目の欠落、関連付けの曖昧さなど、衛生管理のみを目的とするコンテキストを区別します。衛生管理の情報は、モニタリングの信頼度または推奨アクションに影響する場合にのみ提示します。
• Adhoc の場合は、アカウントの状況にとって重要な順にシグナルを並べます。最初にリスク／機会、次に依存関係、最後に補足的なコンテキストを配置します。
• Monitor の場合は、新しく、信頼度が高く、アクションに関係する変化を優先して順位付けします。解約またはリテンションのリスクと拡大の機会を優先し、古いシグナルや推測的なシグナルは優先度を下げ、重要な変化のないアカウントは簡潔にまとめます。
• 順位付けした各アカウントに、High、Medium、Low のいずれかの注意スコアと、Expansion ready、Expansion blocked、Retention risk、Execution risk のいずれかの方向性を示すステータスを付けます。

5. エビデンスと解釈を分ける

• 主張を裏付けるクリック可能なソースリンクを、その主張の近くに配置します。CRM については、コネクターが提供するレコード URL を使用します。信頼できるコネクターのメタデータでインスタンスのベース URL が公開されている場合にのみ、ID から URL を構成します。安定したリンクがない場合はソース名をそのまま記載し、レコード ID を主なアクション経路としてそのまま公開しないでください。
• 生のエビデンスと戦略的な解釈を明確に分けます。推奨するすべてのアクションは、シグナルまたはエビデンス項目にたどれるようにします。
• CRM の情報と手動で確認したアカウントの実態の両方が利用できない場合は、最新性の基準となる情報が利用できないと明記し、結果が最新であるかのように示さないでください。

次のステップの選択肢

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

• 1つのアカウントの調査を深める、または重要度が最も低いエビデンスのギャップを埋める。
• シグナルに基づいて、簡潔な社内アカウントチーム向けの最新情報を作成する。
• エビデンスが進行中の商談や今後の会話を示している場合は、選択したアカウントを商談戦略または会議準備に引き継ぐ。
• 同じモニター対象範囲について、この analyze-account-signals スキルを再実行する、該当する日次または週次の自動化がすでにあるか確認する。なければ、このスキルを再実行し、注意が必要なアカウント、その重要性、次に取るべき最善の営業アクションを通知する自動化の作成を提案する。
• 欠落または古い項目が信頼度に影響している場合は、確認用に CRM 更新案を作成する。

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

• タスクの作成、更新の投稿、または CRM の変更の自動書き込み。

Automation Offer Guard

Monitor Summary の出力では、ユーザーがウォッチリスト、担当者、テリトリー、ポートフォリオなど、再利用可能なスコープを提示しており、日次または週次で更新すると概要の価値が高まる場合は、販売者アカウントを定期的に監視することを次のステップとして優先します。営業の観点から価値を伝えます。パイプラインの変化、拡大の兆候、リテンションリスク、停滞している次のステップ、関係者の変化、今後の顧客ミーティング、アカウントチームの障害を見逃す前に把握できることを説明してください。

自動化では、別個のカスタムダイジェストではなく、このスキルをスケジュールに従って再実行する必要があります。自動化を作成または説明するときは、プロンプトでこのスキルを直接呼び出し、可能な限りスキルが受け付けるのと同じ正規化済みリクエスト形式を維持してください。

Use the Sales `analyze-account-signals` skill in `Monitor Summary` mode.
Rerun it for the same seller account scope: [watchlist, owner, territory, portfolio, or CRM filter].
Return the standard Monitor Summary output.

mode: "monitor"
owner_id: "[owner id when used]"
owner_email: "[owner email when used]"
watchlist_accounts: [same watchlist when used]
time_window: "[same or agreed recency window, default 14d]"
focus_areas: [same focus areas such as expansion, churn, rollout blockers, stakeholder movement]
output_style: "inbox_summary"

owner_id、owner_email、watchlist_accounts では表現できないテリトリーまたはポートフォリオのスコープについては、安定したスコープを平文のプロンプトに含め、このスキルの通常の Monitor Summary ガイダンスに従ってアカウントの対象範囲を解決してください。

定期的な出力は、このスキルの Monitor Summary 形式に従う必要があります。注意が必要なアカウントのランキング、重要な差分、実行メタデータ、および大きな差分がない場合の処理を含めてください。読み取り専用とし、次に推奨する営業アクションを示すことはできますが、ユーザーが別途依頼し、承認しない限り、タスクの作成、ダイジェストの投稿、オートメーション外への監視状態の保存、CRM の更新を行ってはいけません。

定期モニタリングを提案する前に、ユーザーの環境に一致するローカル自動化がすでにインストールされているか確認してください。$CODEX_HOME/automations/*/automation.toml、または CODEX_HOME が設定されていない場合は ~/.codex/automations/*/automation.toml にあるローカル自動化の記録を調べ、名前、プロンプト、スキル名、モード、アカウントの集合、担当者、テリトリー、ポートフォリオ、その他の安定したスコープの詳細で照合してください。有効な一致と一時停止中の一致は、どちらもインストール済みとして扱います。

• 一致する自動化がある場合は、別の自動化の作成を提案しないでください。次に関連性の高い、自動化以外のフォローアップに進んでください。
• 一致する自動化がない場合は、最後に、同じスコープで analyze-account-signals を日次または週次で再実行する自動化を確認・作成することを、明確に一度だけ提案してください。定期的な出力については、注意が必要なアカウント、それぞれが営業上重要な理由、推奨される次のアクションをまとめた、販売者向けの簡潔なダイジェストとして説明してください。ユーザーが明示的に同意するまでは、自動化を作成または更新しないでください。
• 自動化の機能を利用できない場合は、ツールの詳細には触れず、自動化が利用可能になった際に定期チェックの設定を支援することを提案してください。

Modes

• Adhoc Account Brief — 1 つのアカウントを対象とする、デフォルトの概要出力です。
• Monitor Summary — 範囲を限定したウォッチリスト／担当者／ポートフォリオのビューで、デフォルトの受信トレイ形式の出力です。

Output Format

Adhoc Account Brief

# Account Snapshot

- **Account:** [Linked account when available]
- **Time Window:** [Window]
- **Current Posture:** [1-2 grounded lines]

## Key Recent Signals

- **[Plain-English signal label]** — [What changed] · [Fresh/Recent/Stale] · [High/Medium/Low confidence] · [Source link/label]

## Strategic Interpretation

- [What the signals likely mean for land, expand, retention, or execution risk; label inference]

## Recommended Actions

1. [Action] — [Evidence or signal link] — [Expected outcome]

## Open Questions / Missing Evidence

- [Unknown or gap] — [smallest follow-up evidence that would reduce uncertainty]

---

{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)}

Monitor Summary

# Ranked Accounts Requiring Attention

| Account | What Changed | Why It Matters | Attention | Posture | Suggested Action | Confidence / Evidence |
| --- | --- | --- | --- | --- | --- | --- |
| [Linked account] | [Delta] | [Impact] | [High/Medium/Low] | [Posture] | [Action] | [Link/label] |

## Material Deltas

| Date | Account | Signal | Status | Delta Summary | Impact | Next Step | Confidence |
| --- | --- | --- | --- | --- | --- | --- | --- |
| [Date] | [Account] | [Label] | [New/Updated/Worsened/Resolved] | [Delta] | [Impact] | [Action] | [Confidence] |

## Run Metadata

- **Time Window:** [Window]
- **Data Freshness Cutoff:** [Cutoff or limitation]
- **Scope:** [Universe, checked count, ranked count]
- **Delta Since Last Run:** [Only when prior-run context exists]

## No Major Delta

[Include only when useful.]

---

{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)}

Rules

• アカウント、担当者、商談、指標、兆候、日付、リンク、推奨アクションを捏造しないでください。
• ユーザーがワークフローを明示的に拡張し、関連する情報源を提供しない限り、公開ウェブやニュースの調査、外部情報による補完、タスクトラッカーを使用しないでください。
• このワークフローでは、タスク、投稿、ダイジェスト、CRM の更新、その他の書き込みを行わないでください。
• ユーザー向けの出力では、生の分類トークンではなく、わかりやすい表示ラベルを使用してください。
• 根拠のない主張は、断定せず、質問、リスク、または根拠の不足として書き直してください。
• モニタリングの実行で重要な差分がない場合は、ランキングを水増しせず、その旨を簡潔に伝えてください。

Failure Handling

アカウントの解決に失敗した場合は、不足または曖昧な識別子を伝え、必要最小限の確認を求めてください。任意の情報源で問題が発生した場合は、根拠が最も強い情報を使って続行し、重要な不足情報を明示してください。Monitor のスコープを安全に 50 件以下のアカウントに絞り込めない場合は、ウォッチリストまたはより狭いスコープの提示を求めてください。