index

ChatGPT web の Chat モード停止ゲート（最初にお読みください）

システムまたは開発者からの肯定的なシグナルによって、surface = chatgpt_web と mode = chat の両方が特定された場合、このスキルのほかのガイダンスを適用する前に停止してください。分析リクエストの最初のターンでは、Data Analytics は Work Mode で最も効果を発揮するため、Work Mode に切り替えることを簡潔に提案する回答だけを返してください。そのターンでは、分析に特化したスキルを読み込んだり、データや情報源を確認したり、ツールを呼び出したり、事前質問をしたり、分析を実行したり、成果物を作成したりしないでください。希望する場合は、Chat モードで続行するよう明示的に依頼できることをユーザーに伝えてください。

提案を提示した後、ユーザーが続行する、進める、または Chat モードを維持することを明示した場合にのみ、Chat モードで続行してください。元のリクエストを繰り返すこと、データを追加すること、以前の質問に回答することは、オーバーライドとして扱いません。ユーザーが提案を明示的にオーバーライドしたら、リクエストを言い直してもらうことなく、元の分析リクエストを再開し、以下の ChatGPT web Work Mode ランタイム分岐に従って、事前確認、永続化、出力を行ってください。現在の分析リクエストではこのオーバーライドを維持してください。Chat モードで新しい分析リクエストが始まった場合は、再びこの停止ゲートから開始してください。

適格性ゲート（ルーティングの前にお読みください）

構造化レコード、数値指標、定量的な根拠、ダッシュボード／指標の定義、またはそうした根拠に基づくビジネス／製品上の意思決定を必要とするリクエストの解決に限り、このプラグインを使用してください。「レポート」「プレゼンテーション」「ダッシュボード」「市場」「検証」「エクスポート」といった分析を思わせる言葉だけでは、対象となりません。データや根拠なしに通常の文章作成、書式設定、レイアウト、変換、定性的な説明として完了できるタスクは、ここにルーティングしないでください。明示的にタグ付けされた共有フローは独自の引き継ぎに対応できます。一般的な共有／エクスポートのリクエストから、このインデックスが共有先を推測してはいけません。

指標や成果物がまだ具体的に指定されていなくても、データ、指標、ダッシュボード、または定量的なビジネス上の根拠の解釈に明らかに依存する場合は、詳細が不足しているリクエストも対象として扱ってください。インデックスを読み込み、現在のセッションのコンテキストを確認するか、必要最小限の追加情報を尋ねたうえで、最も範囲の狭い特化スキルを選んでください。事前に指標名の指定を求めないでください。ただし、根拠の解釈が不要な、機械的な変換、書式設定、コード修正、構文スニペット、一般的な説明のみのタスクは対象外としてください。

対象となる場合は、最も具体的な分析スキルを選んでください。判断に迷う場合は、汎用的なレポート／エクスポートスキルを開くのではなく、確認質問を1つしてください。

製品ローンチ／セグメント判断の目安

対象となる製品分析リクエストには、明示された、または収集予定の前提や制約に基づき、製品ローンチ、段階的な展開、優先順位付け、セグメンテーション、実験結果の評価、A/B テストの解釈、リリース／保留／反復の判断に関する提案が含まれる場合があります。指標、信頼度／不確実性、ガードレール、セグメント、構造化された根拠のいずれかが挙げられている場合は、最初の手順がコンテキストの収集であっても、分析ワークフローとして扱ってください。コンテキストを product-business-analysis と組み合わせ、ユーザーがレポート作成を明示的に免除するか、別の主な成果物を選択した場合を除き、product-business-analysis を選択する際は必ず build-report も含めてください。

指標の定義／信頼できる情報源に関する見解の相違

チーム間で、意思決定や経営層への回答にどの指標定義、ダッシュボード、抽出データ、担当者、または信頼できる情報源を用いるべきかについて意見が分かれている場合（例：売上／ARR、アクティベーション、リテンション、ファネル、地域別合計）は、直近の成果物が簡潔な Slack／メールでの提案であっても、分析としてルーティングしてください。比較可能性、バックフィル、粒度、情報源の不整合が問題であれば analyze-data-quality を優先し、標準となる定義やガードレールの管理が問題であれば design-kpis を優先してください。どの定義を採用すべきかが問われている場合は、両方を使用してください。

段階的な分析ワークフローの継続

1 つのリクエストで、まずオーナー、制約、前提、コンテキストを尋ねる、または収集し、その情報を分析上の判断、提案、ダッシュボード、レポートに使用するよう求められた場合、確認だけで終わらせないでください。$gather-business-context を読み込み、その後、最も関連性の高い分析スキルを読み込んでください。そのスキルが $product-business-analysis、$metric-diagnostics、$kpi-reporting、または $market-sizing の場合、ユーザーがレポートの作成を明示的に免除したか、別の主要成果物を選択した場合を除き、同じルートの一部として $build-report を読み込んでください。その他の永続的なナラティブ形式の成果物では、確認を求める前に $build-report を読み込んでください。情報がまだ不足している場合は、これらのスキルを読み込んだ後に確認してください。

スキルの目的

幅広いデータ分析のリクエストを、適切な特化型ワークフローに振り分けます。このインデックスの呼び出しは、定量的なエビデンス、情報源の検証、指標に関する推論、またはデータに基づく判断が必要な場合に、このプラグインを使用する強い意図の表れとして扱ってください。汎用的なレポート作成やエクスポートの処理よりも、特化型の分析スキルを優先してください。

スキルの設定

ランタイムのルーティング

surface と mode は別々に分類し、システムまたは開発者からの明示的なシグナル、あるいは真に排他的なツールがある場合にのみ判定してください。

• surface = codex_desktop：環境が Codex デスクトップであると明示されている場合、またはデスクトップ専用の codex_app ツールが利用できる場合。
• surface = chatgpt_web：環境がウェブブラウザー上の ChatGPT であると明示されている場合。
• mode = work_mode：環境が Codex Work Mode であると明示されている場合。
• mode = chat：環境が標準の ChatGPT チャットであると明示されている場合。
• それ以外の場合は、該当する値を unknown に設定します。

surface、利用できないツール、ツールの失敗、オペレーティングシステム、ファイルパス、サンドボックスの詳細、ネットワークの詳細から mode を推測しないでください。明示的なコンテキストは、ツールの利用可否よりも優先されます。web_work_mode は、surface = chatgpt_web と mode = work_mode の両方が明示的に確認された場合にのみ true としてください。mode = work_mode で surface = unknown の場合は、ウェブ Work Mode のシグナルが部分的にあるものとして扱い、surface = codex_desktop が明示的に確認されない限り、永続的なレポートやダッシュボードの配信に Data Analytics MCP UI を選択しないでください。

surface と mode を分類した後、最も具体的に一致するランタイム分岐を選択してください。

実行環境の分岐	インテーク	セマンティックレイヤーの永続化	出力先
ChatGPT web Chat モード（surface = chatgpt_web、mode = chat）	インテークの前に、上記の停止ゲートを適用します。明示的な上書きの後は、以下の ChatGPT web Work Mode インテークのガイダンスに従います。	明示的な上書きの前に、永続化を作成または更新しないでください。上書きの後は、以下の ChatGPT web Work Mode 永続化のガイダンスに従います。	明示的な上書きの前に、出力を作成しないでください。上書きの後は、以下の ChatGPT web Work Mode 出力のガイダンスに従います。
Codex デスクトップ（surface = codex_desktop）	利用可能な場合は、構造化されたインテークに request_user_input を使用します。利用できない場合は、簡潔な会話形式の選択肢を代替のインテーク方法として使用します。	セマンティックレイヤーの設定または保守は create-data-context に振り分けます。ローカルで作成する場合、ユーザーが別の保存先を選択しない限り、このスキル既定の $CODEX_HOME/skills/<area>-semantic-layer を使用します。	Data Analytics MCP UI の表示先が利用可能です。レポートモードの作業は $build-report に振り分けられます。既定では mcp-app を使用し、明示的なフォールバックルールに該当する場合のみ HTML を使用します。
ChatGPT web Work Mode（web_work_mode = true）	利用可能な場合は、構造化されたインテークに $answers-ask-user-input または同等のネイティブ構造化インテークアクションを使用します。利用できない場合は、簡潔な会話形式の選択肢を代替のインテーク方法として使用します。	セマンティックレイヤーの設定または保守は create-data-context に振り分けます。実行中に Skills のインストール先が利用可能な場合は、ChatGPT の個人用 Skills 永続化を使用します。	インラインでの提供がすでに選択されている場合に限り、ネイティブの Work Mode レンダリングを使用します。サポート対象の bar、line、pie、scatter のいずれか1つだけの場合、charts_widget_v2 は直接表示されるものとして扱い、フォールバックの前にライブの genui コンテンツ参照を出力します。利用不可と独自に判断したり、検索したり、ペイロードをそのまま JSON で出力したりしないでください。app_block はホストに表示される場合に限って使用します。永続レポートとダッシュボードの既定形式は HTML とします。ユーザーが選択した場合は、接続済みの BI または別の MCP 以外の保存先を使用します。MCP サーバーやその他の呼び出し可能なツールは、引き続き有効なデータソースです。
不明な表示先の Work Mode（mode = work_mode、surface = unknown）	利用可能な場合は、構造化されたインテークに $answers-ask-user-input または同等のネイティブ構造化インテークアクションを使用します。利用できない場合は、簡潔な会話形式の選択肢を代替のインテーク方法として使用します。	セマンティックレイヤーの設定または保守は create-data-context に振り分けます。実行中に ChatGPT の個人用 Skills インストール先が明示的に利用可能な場合を除き、移植可能な永続化を使用します。	レポートとダッシュボードの提供先は、既定で Web 対応として扱います。HTML、接続済みの BI、または別の MCP 以外の保存先を選択します。Work Mode であることが明確に確認されている場合、不明な表示先から Data Analytics MCP UI での提供先を選択しないでください。
それ以外：その他または不明なすべての実行環境	利用可能な場合は、$answers-ask-user-input または同等のネイティブ構造化インテークアクションを使用します。構造化インテークが利用できない場合に限り、簡潔な会話形式の選択肢を使用します。	セマンティックレイヤーの設定または保守は create-data-context に振り分けます。このスキルは、公開されている ChatGPT Skills、ローカルの Codex、または移植可能なパッケージの保存先を選択します。	実行環境が公開している出力先と、対象スキルのルールを使用します。実行環境固有の出力先を利用できると明確に確認できない場合は、移植可能な出力を既定とします。

提供されたコンテキストを現在の回答に使用する通常の分析作業では、コンテキストを現在のセッション内にのみ保持し、該当する分析ワークフローを続行します。

保存データコンテキストとセマンティックレイヤー

通常の分析ワークフローでは、保存データコンテキストの設定は不要です。リクエスト、会話、接続済みソースからの読み取り、アップロードされたファイル、貼り付けられた成果物、ローカルリポジトリのファイル、明示的に指定されたセマンティックレイヤー、または現在のランタイムで検出可能なユーザー作成のセマンティックレイヤーのスキルから、現在のセッションのコンテキストを使用してください。保存コンテキストやセマンティックレイヤーのライフサイクルに関するリクエストは、create-data-context にルーティングしてください。それ以外の分析コンテキストは現在のセッション内にとどめ、「ランタイムのルーティング」に従ってください。

ガイド付きフローとソースの設定

このインデックスは、タスクの選択、設定に関連するルーティング、ガイド付きワークフローの継続を担います。プラグインの利用意図が確立した後、使い始めのリクエスト、自由形式のプロンプトの探索、アップロードまたはデモデータに関するリクエスト、ウォークスルーに関する質問には、ステートレスな初回タスクフローを適用してください。機能の概要のみを求めるリクエストは、「幅広い案内とヘルプのリクエスト」に送ってください。ユーザーがすでに具体的なタスクを提示している場合は、ヒアリングを省略し、カスタム質問として扱ってください。

現在の会話、表示されているインストール済みプラグインとスキル、現在の実行で得られたツールの結果、アップロードまたは貼り付けられたコンテキスト、ローカルファイルのみを使用してください。ソース、プロジェクト、ダッシュボード、テーブル、SQL、ファイル、コネクター、プロバイダーを選択する画面は表示しないでください。ユーザーがデータ分析を求めているものの、データ、ソース、または呼び出し可能なソースが見つからない場合は、役に立つ最小限のデータ成果物を求めるか、アップロードまたはサンプルデータを使う代替手段を提示してください。ユーザーが明示的に求めない限り、このフローから保存データコンテキストを作成しないでください。

初回タスクのヒアリング

以下の構造化フォームの契約に従ってください。Codex デスクトップでは、利用可能な場合は必ず request_user_input を呼び出してください。それ以外のすべてのサーフェスまたはモードでは、利用可能な場合は必ず $answers-ask-user-input を呼び出してください。サーフェスに適した構造化ヒアリングアクションを利用できず、ランタイムが同等のネイティブな構造化ヒアリングアクションを公開している場合は、そのアクションを使用してください。ランタイムが chatgpt_web、work_mode、または不明な環境であるという理由だけで、会話形式の選択肢に切り替えないでください。構造化ヒアリングが利用できない場合は、通常の会話の中で、同じタスクまたは代替手段を簡潔に提示してください。

接続済みソースの選択肢を提示する前に、ランタイムから提供されたスキル一覧、インストール済みアプリとプラグイン、おすすめプラグインの一覧、呼び出し可能なツール、現在の会話、アップロードまたは貼り付けられた成果物、ローカルファイル、検出可能なセマンティックレイヤーのスキルから、関連する可能性のあるデータレーンを特定してください。分析タスクでは、ウェアハウスや SQL データベース、BI ダッシュボード、プロダクト分析システム、スプレッドシート、ソース定義のドキュメント、関連するコミュニケーションのコンテキストなど、信頼できるデータソースとなるレーンを積極的に探してください。呼び出し可能なツール、アップロードまたは貼り付けられた成果物、ローカルファイル、現在の実行で得られたソースの読み取り結果を使って、どのレーンをすぐに利用できるか判断してください。

関連するソースレーンをすぐに呼び出せない場合は、おすすめプラグインとインストール済みプラグインのメタデータを使って、設定またはインストールの方法を特定してください。

tool_search が利用できず、ランタイムが ALL_TOOLS を公開している場合は、ALL_TOOLS の名前、説明、プラグインの提供元を調べてください。呼び出し可能なツールは、インストールの推奨よりも、ソースへすぐにアクセスできることを示す強い根拠として扱ってください。

ウェアハウスまたはソースシステムのツールを呼び出せる場合は、「接続済みソースの選択肢の文面」に記載された信頼できるデータソースの順位に従い、ウェアハウスを使うタスクを最初に提示してください。

1. ユーザーが具体的なタスクを指定している場合は、インテークをスキップし、Custom-question access に進みます。
2. それ以外の場合は、ランタイムから提供されるインストール済みの Apps と Plugins のインベントリ、およびセッション内ですでに確認できる呼び出し可能なツールのみを確認します。これには、必要なソースを読み取れるカスタム MCP サーバーやその他の呼び出し可能なツールも含まれます。コネクターの記録を読み取ったり、functions.list_available_plugins_to_install を呼び出したり、.app.json の宣言をインストール済みとして扱ったりしないでください。ツールが遅延読み込みされる場合は、利用可能なら tool_search を使用し、そうでなければ ALL_TOOLS などのランタイムの呼び出し可能ツールレジストリを使用してください。すでに確認できるコネクター、カスタム MCP サーバー、その他の呼び出し可能なツール、またはユーザーが名前を挙げたものについて、その名前、ソースの種類、またはタスクに関連する機能で検索し、呼び出し可能かどうかを確認してください。固定されたプロバイダーカタログだけを検索しないでください。
3. 役立つ接続済みソースが1つ以上ある場合は、Codex デスクトップでは request_user_input を、それ以外では $answers-ask-user-input を1回呼び出し、既存のインストール済みコネクターまたは呼び出し可能なツールで対応できる異なるタスクを2つ、その後に Upload your own を、正確に3つの選択肢として提示してください。異なるソースファミリーを優先してください。役立つソースが2つ未満の場合は、同じ接続済みソースの機能から、重複しない複数のタスクを導き出してください。サンプル、インストール、または未対応の選択肢は含めないでください。
4. 役立つ接続済みソースがない場合は、Upload data に続けて Use sample data のみを提示してください。Connect a data source は追加しないでください。

ヘッダーには Dashboard、Report、または Data task を使用してください。成果物が決まっている場合は What should the dashboard be about? または What should the report be about? と尋ねてください。それ以外の場合は The Data Analytics plugin turns data into insights, recommendations, and decision-ready artifacts. Try it out with one of these prompts: と尋ねてください。ラベルは80文字未満にし、推奨事項の追記は省略してください。カスタム質問用に、組み込みの自由記述式 Other フィールドを維持してください。画面に適した構造化インテークアクションが利用できない場合は、同じ選択肢をチャット内に簡潔に表示してください。キャンセルまたは空の送信があった場合は、フローを保留します。

接続済みソース用フォーム：{ id: "data_task", options: [{ label: "{connected task 1}", description: "{connected-source description 1}" }, { label: "{connected task 2}", description: "{connected-source description 2}" }, { label: "Upload your own", description: "Upload or paste your own data and produce an analytics report with findings and next steps." }] }。

ソースがない場合のフォーム：{ id: "data_task", options: [{ label: "Upload data", description: "Upload or paste your data and produce an analytics report with findings and next steps." }, { label: "Use sample data", description: "Analyze sample product-growth data and produce an analytics report." }] }。

選択後の処理

• 接続済みソースのタスク：既存のコネクターまたは呼び出し可能なツールを使用し、示唆された範囲に絞ったワークフローを開始してください。事前入力された接続済みソースの選択肢では、必ず $product-business-analysis、$visualize-data、$build-report を呼び出してください。制御に使用するソースは自動的に選択し、プラグインのインストール画面を開かないでください。ソースから予期せず利用可能な証拠を取得できない場合は、以下のフォールバックフォームを使用してください。
• Upload your own または Upload data：役立つ最小限のエクスポート、SQL の結果、データの形式、スクリーンショット、メトリクスの定義、またはファイルを尋ね、その後待機してください。
• Use sample data：確認を求めず、ただちにデモの手順を開始してください。
• 「use sample data」または「using the sample data」を明示的にリクエストし、ユーザーが別のサンプルを指定または添付していない場合は、Use sample data を選択してください。ワークスペースを検索したりアップロードを求めたりせず、同梱のデモをただちに使用してください。
• その他のテキスト：ユーザーが作成したカスタム質問として扱い、Custom-question access に進んでください。

プロバイダー、プロジェクト、テーブル、ダッシュボード、クエリ、またはエクスポートをユーザーに選ばせないでください。利用可能なデータやソースが提供されておらず、見つからない場合は、実際に不足しているデータ成果物を求めてください。すでに利用可能なソース同士が回答に影響する形で競合している場合に限り、ソースの確認を求めてください。

カスタム質問へのアクセス

インストールを実行できるのは、ユーザーのメッセージまたは受付フォームの「その他」欄に記載された具体的なタスクがある場合のみです。対象を絞ったワークフローを選び、既存のプラグイン、アプリ、コネクター、カスタム MCP サーバー、その他の呼び出し可能なツール、アップロードまたは貼り付けられたファイル、ローカルファイル、または現在の実行コンテキストから、十分に新しく信頼できる根拠を得られるか判断してください。得られる場合は、根拠となる情報源を選んで開始します。

根拠が不足している場合は、ネイティブコネクターをインストールする前に、必要な情報源を読み取れる、表示中または遅延読み込み可能なカスタム MCP サーバーとその他の呼び出し可能なツールを確認してください。カスタム MCP サーバーまたはその他の呼び出し可能なツールについて、そのサーバー名またはツール名、説明、アクションのスキーマ、あるいはユーザーが指定した情報源から、必要な情報源のカテゴリを読み取れると判断できる場合は、関連するものとして扱ってください。設定済みの preferred_plugins と .app.json の項目はルーティングの手がかりであり、情報源の全体を網羅するものではありません。

必要な根拠がまだ不足しており、利用可能なコネクターの候補がある場合は、.app.json のアプリカテゴリを使って情報源の種類を割り当て、functions.list_available_plugins_to_install を一度呼び出してください。現在の実行コンテキストに、抑制対象となったプラグインインストールの ID が正確に列挙されている場合は、その ID のみを削除してください。抑制対象を取得するためだけに、旧式の事前確認を実行してはいけません。その後、タスクに役立つ、返されたすべての候補に対して、functions.request_plugin_install を順番に呼び出してください。ID を推測したり、汎用的な「最適」候補を 1 つに絞ったり、役立つ候補が最初に見つかった時点で止めたり、インストールを並列実行したり、request_connector_setup を使ったりしてはいけません。インストールが拒否された、または確認されない場合は、record_plugin_install_suppression.py を使ってその正確な ID を記録し、ほかの役立つ候補に進んでください。

データウェアハウスの例外：カスタムタスクで構造化データが必要で、利用可能なデータウェアハウスがなく、ユーザーが指定していない場合は、返されたデータウェアハウス候補をすべて残してください。候補をすべて挙げて、どのデータウェアハウスを使うかユーザーに尋ね、選ばれた候補の正確な ID のみをインストールします。候補が 1 つだけ返された場合は、その候補を直接提示してください。マニフェストの順序や設定済みの優先設定に基づいて選んではいけません。

セットアップが利用できない、拒否された、確認されていない、キャンセルされた、または根拠が依然として不足している場合は、同じターンを終了する前に、必ず次のフォールバック質問をしてください：{ id: "fallback_next_step", question: "I don't have enough data to complete this task. How do you want to proceed?", header: "Next step", options: [{ label: "Upload data", description: "Upload or paste your data and produce an analytics report with findings and next steps." }, { label: "Use sample data", description: "See a clearly labeled synthetic product-growth demo; it will demonstrate the workflow without answering the real-data question." }] }。カスタムの選択肢や追加の推奨文を付け加えてはいけません。

セットアップが成功したら、対象を絞ったワークフローを自動的に開始してください。セットアップ後にフロー制御の選択肢を表示してはいけません。

情報源がない場合の完了時の不変条件

現在のタスクで使用できるデータがないと判断した場合、どの経路でも、ターンが終了する前に「Upload data」と「Use sample data」を提示しなければなりません。これには、利用できる接続済みの情報源がない場合、必要な情報源を利用できない場合、インストール用ツールが利用できない場合、インストールのプロンプトが拒否、閉じられた、キャンセルされた、または未確認のままの場合、インストールに成功しても使用可能な根拠を取得できない場合、接続済みの情報源に予想外に十分な根拠がない場合が含まれます。

情報源がないことの説明だけ、インストールの提案だけ、または情報源に接続して再試行するよう指示するだけで終えてはいけません。インストールのプロンプトをフォールバック質問の前に表示してもかまいませんが、セットアップが成功し、現在の実行で情報源から使用可能な根拠を取得できた場合を除き、フォールバック質問の代わりにはなりません。具体的なタスクには、上記の正確な fallback_next_step 形式を使ってください。「Use sample data」を選ぶ場合は、同梱のデモが合成データであり、ユーザーの実データに関する質問への回答ではなく、ワークフローを実演するものであることを明確に伝えてください。

接続ソースのオプション文言

表示されているインストール済みのサーフェスまたは呼び出し可能なサーフェスについて、名前、説明、またはアクションがデータウェアハウス、SQL、クエリ、テーブル、スキーマ、データセット、データベースへのアクセスを示している場合は、データウェアハウス系として扱います。有用なオプションは、信頼できる情報源としての適合性に基づいて順位付けします。まずデータウェアハウス／ソースシステム、次に BI、プロダクト分析、GitHub、表形式の Drive／ファイル、最後に最適なドキュメントまたはコミュニケーションソースとします。タスクは、接続されたソースを通じて実行可能な状態にしてください。

データウェアハウス以外のタスクにはソース固有のラベルを使い、データウェアハウスのラベルはプロバイダーに依存しない表現にします。1 つのコネクターが複数の枠を担う場合は、文言を繰り返すのではなく、コネクターの実際の機能に応じてタスクを変えてください。以下はデフォルトであり、非表示のプロンプトではありません。

ソース	ラベル	説明
データウェアハウスまたはソースシステム	ビジネスデータを分析	データウェアハウスまたはソースシステムのデータを分析し、傾向、セグメント、外れ値、次のステップを特定します。
BI／ダッシュボード	ダッシュボードの傾向を分析	ダッシュボードまたは BI データを分析し、傾向、ギャップ、追加分析の切り口を特定します。
プロダクト分析	プロダクトの利用状況を分析	イベント、ファネル、リテンション、実験、行動の変化を分析します。
GitHub	GitHub のアクティビティを分析	イシュー、プルリクエスト、レビュー、ブロッカーを分析します。
メール	メールの傾向を分析	スレッドを分析し、テーマ、傾向を示すシグナル、フォローアップ、次のステップを特定します。
Drive	Drive ファイルを分析	関連する Drive データを分析し、調査結果と次のステップを特定します。
カレンダー	会議のパターンを分析	会議のトピック、参加者、長さ、頻度、次のステップを分析します。
Notion	Notion のコンテンツを分析	ページとデータベースを分析し、プロジェクトの状況、決定事項、テーマを特定します。
Slack	Slack のアクティビティを分析	メッセージを分析し、活発なトピック、ブロッカー、決定事項、フォローアップを特定します。
Teams	Teams のメッセージを分析	チャットとチャネルを分析し、トピック、アクション、ブロッカー、決定事項を特定します。
SharePoint	SharePoint ファイルを分析	関連する SharePoint データを分析し、調査結果と次のステップを特定します。

デモデータ

有用な接続ソースがない場合、または選択したワークフローで利用可能な根拠が不足している場合に限り、サンプルデータを使用を表示してください。demo-product-growth.csv をこのスキルからの相対パスで参照し、合成データであることを明記したうえで、行や調査結果を捏造せず、再現可能な SQL で分析します。そのデータを $product-business-analysis、$visualize-data、$build-report に渡し、レポートの配信方法は $build-report にちょうど 1 つ選ばせてください。

ソースの検出と検証

関連するセマンティックレイヤーは出発点となる地図として使い、境界とはみなさないでください。

1. 考えられるすべてのソースを調査する。 タスクに関連するデータが含まれている可能性がある、または解釈を変える可能性がある、接続済みまたは提供済みのすべてのソースを検索します。構造化データソースごとに、関連するスキーマ、データセット、テーブル、ビュー、モデル、指標について、カタログまたはメタデータを改めて検出します。既知のソース、テーブル、ダッシュボード、セマンティックマッピングは出発点であり、探索の終点ではありません。
2. 重複や矛盾を比較する。 ソースが重複する、または相互に矛盾する場合は、所有者、鮮度、定義、粒度、網羅性、直接性を比較します。最も権威のあるソースを使うか、必要に応じて相互補完するソースを組み合わせます。重要な矛盾を明記し、選択したソースが回答の根拠となる理由を説明したうえで、結論を出す前にライブ読み取りで選択したデータを検証します。

ソースアクセスに関するガードレール

ソースにクエリを実行したり、成果物を作成したり、結論を導き出したりする前に、回答に特定の信頼できる情報源が必要かどうかを判断してください。

必須のソースを利用できない場合は、その経路を中止します。必要なソースをユーザーに伝え、信頼性の低い代替ソースを同等のものとして扱わないでください。そのうえで、同じターンを終える前に、必須の「ソースなしで完了する場合の不変条件」を適用し、アップロードされたデータまたは合成であることを明記したデモデータを提案してください。

不足しているソースが任意の補足情報にすぎない場合は、利用可能な最も強い根拠を使って続行し、回答に重大な影響を与える場合は不足情報を明記してください。

対象読者と言語

プラグインの保守担当者ではなく、データ分析のユーザー向けに記述してください。これは、最終回答、セットアップやステータスの確認内容、失敗の説明、ツール実行前の案内、ターン途中の進捗説明に適用されます。

実装作業を、データ分析で何を確認、設定、保存、準備しているのか、そしてそれがなぜ重要なのかという実用的な観点に置き換えてください。ユーザーがデバッグの詳細を求めていない限り、preflight、state file、cache、raw connector id、heartbeat、targetThreadId、schema、API、runtime、metadata、provider taxonomy などの実装用語は避けてください。

ソースリンク

ソースを本文中で参照する場合、ソースに有用な URL があるときは、角括弧付きのテキストだけではなく、クリック可能な Markdown リンクを優先してください。リンクテキストには、ソースのタイトル、記録名、チャンネル／スレッド、会議名／日付などを使用します。たとえば、表示テキストが Meeting notes: May 19 や Slack thread: May 15-21 のクリック可能な Markdown リンクを使用してください。有用な URL や安定したコネクタ表示リンクがない場合に限り、プレーンテキストのラベルを使用し、その不在が重要な場合は (有用なリンクはありません) と記載してください。

ルーティング

実行順序

データ分析プラグインのすべての実行で、以下の順序に従います。

1. 機能の概要だけを求める依頼には Broad Orientation And Help Requests で対応します。自由形式の操作やプロンプトの探索、初回実行時のタスク選択、明示的なガイド付きフローの依頼、より詳しいセットアップの前にデータタスクを選択して実行する必要があるセットアップ関連のプロンプトには、Guided Flow And Source Setup を適用します。
2. データコンテキストの保存、またはセマンティックレイヤーの作成、更新、確認、修復を依頼された場合は、create-data-context にルーティングします。このスキルは、現在のランタイムの分類済み surface 値と mode 値を使って、ChatGPT の個人用 Skills、ローカルの Codex、またはポータブルなパッケージへの保存先を選びます。
3. 既存のセマンティックレイヤーを使ったデータに関する質問には、レイヤーをコンテキストとして扱い、適切な分析ワークフローを続行します。
4. セマンティックレイヤーの検索は、ユーザーがセマンティックレイヤー名またはパスを指定した場合、あるいは現在のランタイムから関連するセマンティックレイヤーを見つけられる場合に限り適用します。
5. ソースへのクエリ、ドキュメント検索、ノートブック作業、レポート作成、ダッシュボード接続、結論の提示を行う前に、Source Discovery And Verification を適用します。
6. ソースへのクエリ、ドキュメント検索、ノートブック作業、レポート作成、ダッシュボード接続、結論の提示を行う前に、Source Access Guardrail を適用します。
7. 回答モードを選択します。実行中にデータを分析して知見を提示する場合は、既定で report を使用します。明示的に簡潔な回答を求められた場合、または解釈を伴わない範囲の限定された検索である場合に限り、inline を使用します。
8. 必要最小限の主要スキルと補助スキルを選択し、インストール済みスキル全体を対象にコンパニオンスキルの確認を1回行い、より適切な分析以外のサーフェス、セマンティックレイヤー、または手法がないか確認します。
9. ソースへのクエリ、レポート作成、補助スキルの実行、最終稿の作成を行う前に、選択したスキルの本文を読み、その指示に従います。
10. 最終回答の前に、対象ワークフローの完了条件を適用します。ユーザーからデータコンテキストの保存またはセマンティックレイヤーの作業を明示的に依頼されていない限り、create-data-context の出力は任意として扱います。

回答モード

Data Analytics の実行で実データまたはサンプルデータを分析し、知見、説明、比較、分解、KPI の状況報告、診断、推奨事項、意思決定支援を提示する場合は、デフォルトで report を選択してください。ユーザーが「レポート」と言う必要はありません。根拠に基づく説明、情報源の文脈、注意事項、ビジュアル、または現在のチャットの応答を超えて再利用できる成果物が役立つ場合は、report を選択してください。inline と report のどちらか迷った場合は、report を選択してください。

inline を使用するのは、ユーザーがチャットでの簡潔な回答を明示的に求めている場合、または、解釈、ビジュアル、情報源の説明、永続的な引き継ぎが不要な、単一の指標値、スキーマやテーブルについての質問、単一の計算など、範囲が明確に限定された事実確認や計算を求めている場合に限ります。プロンプトが短いからといって、自動的にインラインタスクになるわけではありません。比較、ランキング、傾向、セグメント別の分析、集中度、複数の値や時点にわたる変動は、通常レポートを作成してください。

根拠が1つのテーブルやチャートに収まりそうだからといって、プロンプトの範囲が限定されていると判断しないでください。どのディメンション、カテゴリ、コホート、エンティティ、セグメント、または要因が指標の成長、低下、変化、ギャップ、分散をもたらしたかを尋ねる質問は、診断ルートです。$metric-diagnostics を使用し、ユーザーがレポート作成を明示的に免除するか、別の主要成果物を選択しない限り、$build-report を含めてください。また、寄与のパターンを明確にするチャートが役立つ場合は、$visualize-data も含めてください。現在値の確認、合計、単純な時系列、現在値の直接的なランキングは、要因、変動、分散、診断、推奨事項、感度分析、状況報告を求めていない限り、引き続きインラインで回答してください。

すべての report ルートには $build-report を含めてください。ただし、ユーザーがインラインのみ、チャット内の回答のみ、簡潔な回答／成果物なしを明示的に求めている場合、レポート／ファイル／成果物を作成しないよう求めている場合、またはダッシュボード、ノートブック、スプレッドシート、ネイティブ形式のドキュメント、スライドデッキなど、別の主要成果物を選択している場合は除きます。$product-business-analysis、$metric-diagnostics、$kpi-reporting、$market-sizing、およびステークホルダー向けの $analyze-data-quality の実行では、デフォルトで report を選択します。簡潔な KPI の状況更新や状況報告は、ユーザーがレポート、ドキュメント、スライドデッキ、または永続的な成果物も求めていない限り、インライン出力として選択します。「レポート」という言葉がないこと、診断に関する直接的な質問であること、見積もりや状況報告の依頼であることから、レポート不要の意図を推測しないでください。

inline または report を選択した後、結果を理解しやすくするビジュアルが役立つ場合は、$visualize-data を使用してください。特に、カテゴリの比較、構成比の内訳、ランキング、時間の経過に伴う変化、または比較可能な値、行、カテゴリ、時点が多数ある場合に使用します。表を大量に読み込むよりも、ビジュアルを優先してください。また、表現形式の選択、チャートを描画するかどうかの判断、ビジュアルから得られる要点に沿った表や説明の調整は、$visualize-data に任せてください。レポートモードの実行では、チャートや図が必要な場合は $visualize-data を含めてください。主要な分析スキルは、チャートを直接描画するのではなく、ビジュアルの意図と根拠を引き継いでください。

スキルの選択

• 有用なプライマリスキルとサポートスキルを、必要最小限の組み合わせで選びます。
• レポートモードで実行する場合は、進捗報告で選択したルートを一度だけ明示します。例：Route: product-business-analysis + product semantic layer + build-report
• 明示的なセットアップ、利用開始、最初のガイド付きワークフロー、セットアップ状況の確認、オフライン／デモへのフォールバック、ウォークスルー、進行中のガイド付きフローの継続依頼を含む、すべてのデータ分析スキルにおけるソース／タスクのセットアップには、このインデックスのガイド付きゲートを使用します。このゲートでは、求められていない保存済みデータコンテキストやセマンティックレイヤーの作成を行わないでください。
• 通常のデータ作業以外で、セマンティックレイヤーの明示的なセットアップやメンテナンスを行う場合は、create-data-context を使用します。
• プラグインへの言及は出発点として扱い、境界とは見なしません。補完的なサブタスク、実行環境、デリバリー環境、成果物の種類、またはドメイン固有の手法をより適切に担当するインストール済み外部スキルがある場合は、それを追加します。
• バンドル済みのデータ分析スキルと部分的に重複しているという理由だけで、外部スキルを却下しないでください。
• ここでは、実行済みのルート手順を維持しないでください。選択後は、選ばれたスキルが詳細な手順、サポートのトリガー、出力契約を担当します。
• リクエストがプライマリワークフローに該当する場合は、そのワークフロースキルを直接読み込みます。たとえば、KPI 設計のプロンプトでは $design-kpis を、ダッシュボードのプロンプトでは $build-dashboard を、TAM/SAM/SOM のプロンプトでは $market-sizing を、指標の変動に関するプロンプトでは $metric-diagnostics を、プロダクトやビジネス上の意思決定に関する提案中心のプロンプトでは $product-business-analysis を読み込む必要があります。

複数の特化スキルが該当する場合は、最も有用な分析ワークフローとなる順に実行します。たとえば、KPI のレポート作成より先に指標の診断を行ったり、ダッシュボードやレポートの作業より先にセマンティックレイヤーをセットアップしたり、提案をまとめたレポートの作成に先立ってプロダクト／ビジネス分析を行ったりできます。このインデックスはルーターとして維持し、ここでは特化したワークフローのロジックを実行しないでください。

ガイド付きフローや create-data-context の挙動に関わるデータ分析の指示を今後編集する場合、最終化する前にリポジトリのルートから python3 plugins/data-analytics/skills/create-data-context/scripts/validate_data_context_contract.py を実行してください。このバリデーターは、ガイド付きフローとセマンティックレイヤーのセットアップが、それぞれの担当スキルに正しく振り分けられているかを確認します。

余分なセットアップなしで特化スキルに振り分ける例を優先してください。例：

@Data Analytics diagnose why a key business metric moved last week.
@Data Analytics build a KPI framework for the product activation funnel.
@Data Analytics analyze paid workspace retention and recommend what to investigate next.

完了したガイド付きワークフローでウォークスルーを提案した直後の、「はい」「手順を説明してください」「何が起きましたか？」「手順を見せてください」などのフォローアップには、このインデックスに基づいて回答します。非表示の推論を明かさず、観察可能な手順、選択されたワークフロー、コネクターのセットアップ試行、オフラインまたはデモデータへのフォールバック、確認の質問、ソースの不足、成果物の組み立てについて、初心者にもわかりやすく説明してください。

概要の把握とヘルプリクエスト

概要の把握やヘルプを求めるリクエストには、次のように対応します。

• 集中して取り組むワークフローを選ぶ前に、このインデックスを使って、機能全般の概要を求めるリクエストに対応します。
• ユーザーがタスクの選択ではなく概要の把握を望んでいる場合は、what can you do?、show me the capabilities、explain Data Analytics など、機能の概要だけを求めるリクエストをここに振り分けます。
• what should I try?、what should I do?、let's do something、get started with a first task、how do I use Data Analytics?、choose a guided workflow は Guided Flow And Source Setup を通じて案内します。データコンテキストの保存、またはセマンティックレイヤーの作成、更新、確認、修復を求めるリクエストは create-data-context に振り分けます。
• セットアップの履歴にかかわらず、機能の概要にはこのインデックスレベルのヘルプ回答を使用します。明示的なセットアップのリクエストのみ、セットアップ固有の対応に進みます。
• このファイルのスキルマップをもとに、以下のデフォルト形式で回答します。
• 機能やプラグインの詳細を説明する際は、以下の汎用例を3つ使用します。データソースに接続したタスク2つと Upload your own、またはデータソースがない場合のアップロード／サンプルへのフォールバックは、構造化された初回タスクの聞き取りにのみ使用します。
• セットアップ、利用可能なデータソース、Data Analytics の設定についてユーザーが尋ねた場合、または現在のセッションから重要なデータソースの不足が明らかな場合にのみ、セットアップコンテキストの短いセクションを含めます。
• セットアップコンテキストはアナリスト向けに記述します。実際のデータソース名を示し、その表示名、設定済みの優先ルート、セットアップの手順、次に推奨するプロンプトをもとに、ユーザーエクスペリエンスへの影響をモデルの判断で説明してから、最小限の次のアクションまたは代替手段を提示します。
• デフォルトでは影響の大きい不足事項を最大3つまで示し、セットアップコンテキストの箇条書きは合計5つを超えないようにします。固定の影響度カタログに従うのではなく、提案する例との関連性が高い順に不足事項を優先します。
• すべてのデータソースが有効な場合、セットアップコンテキストは Your core Data Analytics sources look ready; I'll still try each source only when a workflow needs it. のような1文にまとめます。
• セットアップコンテキストは、たとえば ライブテーブルを使って指標を適切に検証するには、ウェアハウスまたは SQL のデータソースが必要です。それまでは、SQL、スキーマの詳細、またはエクスポートしたクエリ結果を貼り付けて利用できます。 のように、率直かつ実用的に記述します。
• ステータス名、コネクター ID、実装上の用語をそのまま示さないでください。
• 機能に関する質問に答えるためだけにコネクターからデータを読み取らないでください。コンテキスト内ですでに確認できる、現在のセッションのアプリやツールの利用可否を使います。

概要の把握やヘルプを求めるリクエストには、次のデフォルト形式で回答します。

Data Analytics can help with:
- Metric diagnostics and source-backed explanations for movement
- KPI design, metric definitions, and measurement frameworks
- Product and business analysis for funnels, retention, adoption, pricing, and strategic decisions
- KPI reports, dashboards, notebooks, and reusable semantic layers
- Market sizing, opportunity sizing, and decision-ready recommendations

Setup context:
- {Only include when useful: source readiness or gap plus practical impact}

Good first prompts:
- `@Data Analytics diagnose why a key business metric moved last week.`
- `@Data Analytics build a KPI framework for the product activation funnel.`
- `@Data Analytics analyze paid workspace retention and recommend what to investigate next.`

プラグインの目的

Data Analytics は、接続済みまたは提供されたビジネスデータ、信頼できる情報源のコンテキスト、ダッシュボード、ドキュメント、チャット、ノートブック、スプレッドシート、SQL、セマンティックレイヤーを、情報源に裏付けられた分析成果物に変換します。KPI の定義、指標の変動要因の診断、市場規模の推定、製品やビジネスに関する疑問の分析、データ品質の検証、コンテキストの収集、再現可能なノートブックの作成、ビジュアライゼーションの設計、ダッシュボードの作成、完成度の高いレポートの作成を行い、さらにそれらの成果物を、共有可能な Docs、Slides、スプレッドシート、その他の永続的な引き継ぎ用の媒体に変換できます。

セマンティックレイヤー

セマンティックレイヤーは、製品、ビジネス、指標、データソース、レポートの領域に関する、ソースに裏付けられたローカルスキルです。標準的な指標、テーブル、粒度、結合、フィルター、クエリパターン、注意事項、データソースの優先順位、検証上の不足を定義します。

名前が挙がった製品領域、指標、テーブル、ダッシュボード、SQL クエリ、データソースの選択、結合、注意事項、または繰り返し尋ねられるビジネス上の質問に回答する前に、ユーザーがセマンティックレイヤー、セマンティックレイヤースキル、またはパスを指定した場合、あるいは現在のランタイムから関連するセマンティックレイヤースキルを見つけられる場合に限り、セマンティックレイヤーを使用してください。関連するセマンティックレイヤーがある場合は、テーブルの選択、SQL の作成、ダッシュボードの照合、または指標の定義を行う前に、それを読み込んでください。セマンティックレイヤーをドメイン固有の意味マップとして扱い、接続済みまたは提供されたアプリを参照したうえで、重要度の高い主張を、レイヤーに引用されたソースと照らして検証してください。

セマンティックレイヤーは、データソースの選択、分析上の慣例、明示的に依頼された SQL の提供方法を定める際に役立てられますが、ユーザーが求める出力の範囲を広げるものではありません。セマンティックレイヤーを優先して SQL 全文を含めるのは、現在のユーザーの依頼が、SQL またはクエリの手法を見せる、作成する、レビューする、デバッグする、または提供するよう明示的に求めている場合に限ります。SQL を実行して回答するデータに関する質問は、クエリに基づく回答であっても、それだけでは SQL の提供依頼にはあたりません。

関連するセマンティックレイヤーがなく、ユーザーが繰り返し扱うドメインの質問をしている場合は、create-data-context を使ったセマンティックレイヤーのセットアップを提案してください。ユーザーは、複数の製品領域やビジネス領域に対して複数のセマンティックレイヤーを作成できます。ユーザーが製品横断型のセマンティックレイヤーを明示的に求めていない限り、関連のない製品領域をひとつの広範なレイヤーに統合しないでください。

エビデンスと引き継ぎ

Data Analytics プラグインのファイルでは、~~structured_data のようなレーンのプレースホルダーを使用します。これは、そのカテゴリで利用可能なツール、コネクター、MCP サーバー、プラグインスキル、貼り付けられた結果、アップロードされたファイル、スキーマの説明などを指します。設定済みのアプリとそのカテゴリは、このプラグインの .app.json に記載されています。どの設定済みアプリが各カテゴリに対応できるかを判断する際は、これを正式な対応表として扱ってください。同等の情報を提供できることが確かであれば、ほかの検出可能なアプリ、カスタム MCP サーバー、呼び出し可能なツールもカテゴリに対応できます。必須のコネクター、プラグイン、MCP サーバー、または信頼できる情報源となるレーンが利用できない場合は、Source Access Guardrail に従ってください。任意のレーンが利用できない場合は、貼り付けられたクエリ結果、アップロードされたファイル、SQL スニペット、スクリーンショット、スキーマの説明、またはその他のレビュー済みエビデンスに基づいて作業を続け、その不足が回答に実質的な影響を与える場合は明記してください。

ソースに関するルール：

• SQL、ノートブックのコード、ダッシュボード、レポート、結論を書く前に、信頼できる情報源のコンテキストを収集します。
• 新しい SQL、Python、統計、モデリング、ソースの照合、または重要な指標の計算では、監査可能性が実質的に向上する場合、再現可能なノートブックを優先します。
• 関連する SQL、スクリプト、クエリのパーマリンク、出力、ソースリンク、注意事項を、最終成果物または補足メモに保存します。
• クエリの出所情報は、ユーザーに表示する回答とは分けてください。ユーザーが SQL やクエリの手法を明示的に求めている場合を除き、最終チャットの回答や読者向けレポートの本文に、ソース SQL を貼り付けたり再掲したりしないでください。
• 通常のデータに関する質問では、回答、エビデンス、重要な注意事項を先に示します。SQL 全体は source.query.sql、ソースモーダル、クエリのパーマリンク、ノートブックまたはクエリファイル、補足メモに保存します。表示される引き継ぎ内容では、ソースのパーマリンクまたはソースアクションがあれば十分です。

提供先に関する制約：

• ユーザーが MCP ウィジェットや MCP アーティファクトのレンダリングを希望しない場合でも、起動できる必要があります。その場合は、選択されたチャット、ノートブック、SQL、HTML、BI、Streamlit、スプレッドシート、スライド、またはその他の非 MCP の提供先で作業を続け、ソースのメモはその提供先で通常使用される補足アーティファクトに保存します。
• レポートモードの作業では、MCP と HTML のどちらを選択するかは $build-report が担当します。その他の MCP ウィジェットまたはアーティファクトの提供先では、選択された提供先のルールに従ってください。ウィジェットやアプリ固有のアーティファクトを作成する前に、../../src/analytics-app-core.md を読んでください。
• web_work_mode では、MCP UI ツールが表示されていても、ルーティングポリシー上、MCP UI のレンダリングは利用不可として扱います。Web Work Mode で提供するために Data Analytics の MCP UI ツールを呼び出してはならず、MCP ツールの結果が上にレンダリングされたと説明してもいけません。この制限は、MCP サーバーをデータソースとして使用することを妨げるものではありません。
• mode = work_mode が明示的に設定されており、surface が codex_desktop であると明示されていない場合は、レポートおよびダッシュボードの提供先にも同じ MCP UI の提供制限を適用します。不明な提供先の分類を、MCP アプリのアーティファクトをレンダリングする許可として扱わないでください。HTML、接続済み BI、またはその他の非 MCP の提供先を選択します。
• ユーザー向けの提供先では、隠された推論、認証情報、秘密情報、個人の直接的な連絡先や決済情報を特定する識別子、検証されていない計算結果を開示しないでください。分析に必要な場合は、レビュー済みの顧客名、アカウント名、または企業名を含めてもかまいません。
• インラインまたはダッシュボードの経路で分析対象のソーステーブルが確定したら、安全な場合は、選択された提供先の通常のプレビュー機能を使って、小規模で決定的なプレビューを表示します。
• プレビューが安全でない、利用できない、またはアクセス制限により阻止される場合は、その旨を簡潔に記録し、スキーマ、ドキュメント、またはその他のレビュー済みエビデンスに基づいて作業を続けます。

完了ゲート

完了を報告してください。

• レポートモードの分析で所見が得られた場合、レンダリング済みの MCP アプリレポートまたは HTML レポートが存在するか、具体的なレンダリング上の阻害要因が記録されるまでは、実行は未完了です。チャットの文章、ノートブック、単独のグラフ、インラインウィジェットに暗黙のうちに格下げしないでください。
• レポート実行では、$build-report を通じてレポートの配信モードを必ず1つだけ選択してください。
• $build-report の決定論的な表示面ルールに従ってください。Codex デスクトップでは mcp-app が既定です。Web Work Mode と明確に特定された場合、Codex デスクトップの表示面であるとの確証はないものの Work Mode の兆候が一部ある場合、および MCP アプリのレポートレンダリングに対応していないランタイムでは html を使用します。ランタイムが不明な場合は、ポータブルな html を既定とします。デスクトップで html を使用できるのは、ユーザーまたは後続の変換で明示的に必要とされる場合、または MCP を用いた試行が具体的に失敗した後に限ります。
• インラインまたはチャットの要約だけ、あるいは localhost の URL だけで終わらないでください。チャットの要約は進捗報告として扱ってください。
• 必須の成果物を省略した場合は、最終引き継ぎに省略理由を明記してください。
• 選択したすべての HTML レポートパスで、読みやすく同じデータを示す静的フォールバックを備えた、$build-report のパッケージ化済み Recharts ランタイム契約に従ってください。これには Codex で明示的に選択された HTML、Web Work Mode、PDF、Google Docs、Google Slides への変換に使用する HTML が含まれます。納品する HTML は、別個のグラフファイルに依存してはなりません。
• レポートにグラフ、エビデンステーブル、またはカスタムの可視化が含まれる場合は、埋め込む前に $visualize-data のグラフ契約と QA 要件を満たしてください。

最終レビュー：

• 生成した成果物を開く、読み取る、レンダリングする、または別の方法で検査して、内容を確認してください。
• 分析に使用した決定的なソースに照らして、ソースに基づく主張を確認してください。
• 結論に重大な影響を与える未解決の不足や注意点があれば、明記してください。
• 選択したすべての主要ワークフロースキルを読み、従ったことを確認してください。主要ワークフローを省略した場合は、その理由を最終引き継ぎに記録してください。セマンティックレイヤーの参照、ノートブック、検証、可視化、レポート成果物を、主要ワークフローの契約を満たすものとして扱わないでください。
• 実行が report に分類された場合、後続の $build-report 契約を満たすか、明示的に阻害されるまでは最終化しないでください。
• 選択したレンダリング面が安全でない、利用できない、大きすぎる、または対象を絞った再試行後も失敗する場合は、別の適切な表示面を使って分析を続行し、その理由を進捗報告または最終引き継ぎに簡潔に記載してください。

スキル

design-kpis

目標、主要 KPI、ドライバーメトリクス、ガードレール、スコアカード、測定計画、ローンチや実験の成功基準には、$design-kpis を使用してください。

kpi-reporting

KPI の更新、スコアカード、事業レビュー、経営陣向けの指標要約、目標や進捗状況のレポート、経営陣向けの業績説明には、$kpi-reporting を使用してください。更新で KPI が変動した理由を説明する必要がある場合は、$metric-diagnostics を追加してください。また、ユーザーが明示的に免除するか、別の主要成果物を選択しない限り、最終報告は $build-report を通じて作成してください。

market-sizing

TAM/SAM/SOM、市場機会、支出または売上の市場規模、顧客数、販売数量、商業的な上振れ余地、感度モデルには、$market-sizing を使用してください。その後、ユーザーが明示的に免除するか、別の主要成果物を選択しない限り、最終的な市場規模の回答は $build-report を通じて作成してください。

metric-diagnostics

定義された期間、ベースライン、またはセグメント間の比較において指標を動かした要因の特定、測定上のアーティファクトの除外、確実性に基づく所見の分類には、$metric-diagnostics を使用してください。最終レポートは $build-report を通じて作成してください。

product-business-analysis

推奨事項を伴う意思決定に向けて、製品または事業のデータと背景を分析するには、$product-business-analysis を使用してください。推奨事項が、妥当性を確認した指標の変動に基づく場合は、$metric-diagnostics を追加してください。

analyze-data-quality

データの鮮度、粒度、行数、NULL 値、重複、スキーマのドリフト、結合の破損、外れ値、バックフィル、ソースとダッシュボード間の不一致には、$analyze-data-quality を使用してください。

build-dashboard

分析ダッシュボード、スコアカード、モニタリングページ、BI ビュー、Streamlit ダッシュボード、MCP アーティファクトダッシュボード、BI プラットフォームダッシュボード、およびダッシュボードの QA には、$build-dashboard を使用します。

build-report

ユーザーの依頼に合わせて、データの可視化が分析に役立つ場合はそれを含め、永続的なレポート画面を厳密に 1 つ作成するには、$build-report を使用します。

report-to-google-doc

既存のローカル HTML レポートを、洗練されたネイティブの Google Doc に変換するには、$report-to-google-doc を使用します。

report-to-google-slides

既存のローカル HTML レポートを、洗練されたネイティブの Google Slides デッキに変換するには、$report-to-google-slides を使用します。

report-to-pdf

既存の静的な Data Analytics レポートのエクスポートを、検証済みの PDF アーティファクトに変換するには、$report-to-pdf を使用します。

gather-business-context

ドキュメント、ダッシュボード、チャット、計画メモ、ローンチや実験の資料、信頼できる情報源となるページ、担当者、インシデント、ロードマップ、GTM や顧客のコンテキスト、および過去の意思決定には、$gather-business-context を使用します。

jupyter-notebooks

SQL、Python、統計、モデリング、コホート分析やファネル分析、データ品質チェック、実験、市場規模の推定、診断、およびレポート作成を支援するための、再現可能なノートブックの作成、編集、検証には、$jupyter-notebooks を使用します。

validate-data

手法、データソースの選定、SQL やクエリのロジック、計算、可視化の整合性、留意事項、および結論が証拠に裏付けられているかの QA には、$validate-data を使用します。

visualize-data

レポート、ダッシュボード、デッキ、ノートブック、スコアカード、トレンド、内訳、ファネル、コホート、分布、不確実性、および経営層向け KPI の報告用のチャートを設計、実装、QA するには、$visualize-data を使用します。

create-data-context

セマンティックレイヤーの設定とメンテナンスには、create-data-context を使用します。通常の Data Analytics 作業の前提として、保存済みのデータコンテキスト設定を必須にしないでください。