アナリティクストラッキング自動化

アナリティクストラッキング自動化 は何をしますか？

このスキルは、GA4 + GTMトラッキングのエンドツーエンドの調整役として使用します。

以下の場合に使用します：

• ユーザーが分析から本番公開準備までの完全なGA4 + GTM実装フローを必要としている場合
• リクエストが複数のワークフローフェーズ（発見、スキーマ、同期、検証、公開）にまたがる場合
• 正しいエントリーポイントが不明で、このスキルが適切なフェーズにルーティングする必要がある場合

ユーザーが常に完全なワークフローを望んでいるとは想定しないでください。

自動更新

このインストールされたルートスキルは、続行する前に新しいGitHubバージョンを自己チェックできます。

このバンドル内のタスクを実行する前に：

1. インストールされているSKILL.mdが配置されているディレクトリを特定します。インストーラー管理のコピーは通常、エージェント環境で設定されたスキルディレクトリ（例：$CODEX_HOME/skills/analytics-tracking-automation）または同等のランタイム管理パスの下にあります。
2. node "<bundle-dir>/runtime/skill-runtime/update-check.mjs" --jsonを実行します。
3. 結果のステータスがupdate_availableの場合は、直ちにnode "<bundle-dir>/runtime/skill-runtime/self-update.mjs" --applyを実行します。
4. 更新が成功した場合、続行する前に<bundle-dir>/SKILL.mdを再度読み込み、更新された指示を使用します。
5. 結果のステータスがdisabledの場合は、このバンドルをローカル開発リンクまたはリポジトリチェックアウトとして扱い、更新せずに続行します。

スキルファミリー

スキルファミリーは、1つの傘スキルと7つのフェーズスキルに分割されています：

• tracking-discover: クロールカバレッジ、プラットフォーム検出、新しいアーティファクトのブートストラップ用
• tracking-group: ページグループの作成と承認用
• tracking-live-gtm: スキーマ生成前に実際のライブGTMランタイムを監査する用
• tracking-schema: スキーマ準備、レビュー、検証、承認用
• tracking-sync: GTM設定生成と同期用
• tracking-verify: プレビューQAとオプションの公開ハンドオフ用
• tracking-shopify: Shopify固有のスキーマ、同期、インストール、検証ルール用

リクエストが既に1つのフェーズに限定されており、そのフェーズスキルが利用可能な場合は、ここに完全なランブックをインライン化するのではなく、そちらにルーティングしてください。

site-analysis.jsonがShopifyを示した場合、発見とグループ化は共有したまま、Shopify固有のブランチをtracking-shopifyに任せます。

共有契約

• このリポジトリ内のリポジトリローカルラッパー./event-trackingを使用します。dist/cli.jsがない場合は、最初にnpm run buildを実行します。
• パブリック/ClawHubインストールの場合、event-trackingコマンドを実行する前に、最初にnpx skills add jtrackingai/analytics-tracking-automationを実行する必要があります。
• 各サイトに1つのアーティファクトディレクトリを<output-root>/<url-slug>に保持します。
• ユーザーが既にアーティファクトディレクトリまたはそのファイルの1つを提供している場合は、analyzeから再開するのではなく、最も早い未満たされた前提条件から再開します。
• 現在のチェックポイントまたは次のステップが不明な場合は、./event-tracking status <artifact-dir-or-file>を使用します。
• アーティファクトディレクトリは不明だが出力ルートが既知の場合は、./event-tracking runs <output-root>を使用します。
• ユーザー向けフローには高レベルのエントリコマンドを優先します：run-new-setup、run-tracking-update、run-upkeep、run-health-audit。
• ワークフローモードメタデータは内部ワークフロー状態レイヤーとして扱い、ユーザー向けコマンドインターフェースにはしません。
• PlaywrightベースおよびOAuthプロンプトステップは、デフォルトで非サンドボックスコマンドとして扱います。実際には：analyze、validate-schema --check-selectors、preview、sync。
• --account-id、--container-id、--workspace-idの正確な値が既に確認されていない限り、対話型TTYを使用してプロンプト駆動のGTM同期を最初から実行します。
• GTMアカウント、コンテナ、またはワークスペースをユーザーに代わって自動選択しないでください。
• ユーザーが要求したフェーズ境界を超えて続行しないでください。

会話インテーク

ユーザーがチャットからアクセスし、まだ限定されたフェーズ、アーティファクトディレクトリ、または正確なコマンドを提供していない場合は、意図優先のインテークから開始します。

リクエストを次のいずれかのエントリ意図に分類します：

• resume_existing_run: ユーザーは既にアーティファクトディレクトリまたはそのファイルの1つを持っています。アーティファクトを検査し、statusを使用します
• new_setup: ゼロからの新規トラッキング実装。run-new-setupを優先し、その後推奨される次のステップに従います
• tracking_update: 既存の実装の修正または拡張。run-tracking-updateを優先します
• upkeep: 既存のセットアップの定期メンテナンス、レビュー、または段階的QA。run-upkeepを優先します
• tracking_health_audit: 現在のライブトラッキングの監査のみの評価。run-health-auditを優先します
• analysis_only: 完全なワークフローにコミットせずにクロール/ブートストラップ/発見のみ。tracking-discoverにルーティングし、analyzeの後に停止します

ルール：

• 内部ワークフローメタデータフラグとanalyzeのどちらかをユーザーに選択させないでください。
• 意図があいまいな場合は、「新しいセットアップ」、「既存のトラッキングを更新」、「メンテナンス」、「ヘルス監査」、「分析のみ」、「既存の実行を再開」などのユーザー向け用語を使用して、1つの短い平易な質問をします。
• ユーザーが新しいURLを提供し、トラッキングの設定を依頼した場合、デフォルトでnew_setupにします。
• ユーザーが新しいURLを提供し、サイトの検査、構造の分析、現在のトラッキング信号のレビューのみを依頼した場合、デフォルトでanalysis_onlyにします。
• ユーザーがアーティファクトディレクトリまたはワークフローファイルを提供した場合、analyzeから再開するのではなく、デフォルトでresume_existing_runにします。

ルーティングルール

ユーザーの意図と現在のアーティファクトに基づいてルーティングします：

• 新しいURL、クロールリクエスト、またはまだアーティファクトがない場合：tracking-discoverから開始
• site-analysis.jsonがあり、pageGroupsが欠落しているか未確認の場合：tracking-groupにルーティング
• 確認済みのsite-analysis.jsonがあり、ライブGTMコンテナIDが検出されたが、まだライブベースラインレビューがない場合：tracking-live-gtmにルーティング
• 確認済みのsite-analysis.jsonまたは進行中のevent-schema.jsonがある場合：tracking-schemaにルーティング
• gtm-config.jsonがある場合：tracking-syncにルーティング
• gtm-context.jsonがある場合：tracking-verifyにルーティング。公開は別個の明示的なアクションとして扱います
• Shopifyプラットフォームの確認：共有の初期ステージを維持し、その後tracking-shopifyに引き継ぎます

ルートスキルのみが利用可能な場合は、同じルーティングロジックに従って直接進み、一致するフェーズ境界で停止します。

停止ルール

• prepare-schemaの前にページグループ承認をバイパスしないでください。
• 重要な決定チェックポイントでは、続行する前に常に明示的なユーザー確認を必要とします：
  • pageGroups（confirm-page-groupsの前とprepare-schemaの前）
  • event-schema.json（confirm-schemaの前とgenerate-gtmの前）
  • GTMターゲット選択（sync中のアカウント/コンテナ/ワークスペース）
  • 公開判断（publishの前）
• 確認が欠落しているかあいまいな場合は、停止して質問します。自動的に進めないでください。
• 「完全なワークフロー」、「全流程」、「エンドツーエンド」、「続けて全部」などの広範なリクエストは、スコープの承認のみです。チェックポイントの承認としてはカウントされません。
• ユーザーが現在のターンでそのチェックポイントを明示的に確認しない限り、confirm-page-groups --yesまたはconfirm-schema --yesでユーザーに代わってチェックポイント承認を記録しないでください。
• サイトでライブGTMコンテナが検出された場合、スキーマ生成前にライブベースラインレビューをバイパスしないでください。
• ユーザーが明示的に--forceを希望しない限り、generate-gtmの前にスキーマ承認をバイパスしないでください。
• プレビューQAと公開は別個の判断として扱います。
• tracking-health.jsonを公開ゲートとして扱います。ヘルスが欠落している、手動のみ、またはブロックされている場合、ユーザーが明示的に--forceを希望しない限り、公開にジャンプしないでください。
• Shopifyの手動検証をShopify実行の期待されるパスとして扱い、フォールバックエラーケースとしては扱いません。
• tracking_health_auditを監査専用のワークフローモードとして扱います。ユーザーが明示的にオーバーライドを要求しない限り、GTMデプロイアクション（generate-gtm、sync、publish）を実行しないでください。

再開とクローズアウト

再開時：

• workflow-state.jsonが存在する場合はそれを優先します
• 警告が古いゲートを示す場合は、実際のアーティファクトセットを検査します
• 次のステップが不明な場合はstatusを使用します

フェーズまたは完全なワークフローが終了した場合、クローズアウトは回答を優先します：

• コンパクトで決定準備のできたサマリーを平易な言葉で先頭に置きます
• サマリーの前に生のJSON、生のURLリスト、またはアーティファクトインベントリをダンプしないでください
• ファイル、チェックポイント、次のコマンドは人間が読めるサマリーの後にのみリストします

参考文献

• skill-map.md: 傘スキル/フェーズスキルマップ
• architecture.md: ライフサイクル、チェックポイント、再開セマンティクス
• output-contract.md: アーティファクトファイルとゲートセマンティクス
• shopify-workflow.md: Shopify固有ブランチの期待事項