tracking-live-gtm
Use when the user wants to inspect the real live GTM runtime before schema generation or compare multiple live GTM containers.
git clone --depth 1 https://github.com/jtrackingai/analytics-tracking-automation /tmp/tracking-live-gtm && cp -r /tmp/tracking-live-gtm/skills/tracking-live-gtm ~/.claude/skills/tracking-live-gtmSKILL.md
# Tracking Live GTM Use this skill to audit the site's real live GTM setup before event generation. ## Inputs One of: - confirmed `<artifact-dir>/site-analysis.json` - explicit live GTM public IDs when the crawl did not capture them ## Workflow If the telemetry consent prompt appears and no prior choice is recorded, stop and follow [../../references/telemetry-consent.md](../../references/telemetry-consent.md) before continuing. Run the live baseline step before schema preparation whenever the site has a real GTM container installed: ```bash ./event-tracking analyze-live-gtm <artifact-dir>/site-analysis.json ``` If multiple live containers matter and the user already knows the primary comparison target: ```bash ./event-tracking analyze-live-gtm <artifact-dir>/site-analysis.json --primary-container-id GTM-XXXXXXX ``` If the user wants to test the quality of the already-published live GTM setup on the real site, run: ```bash ./event-tracking verify-live-gtm <artifact-dir>/site-analysis.json ``` During review: - show all detected live GTM containers - explain which container is the primary comparison baseline - summarize existing live events, measurement IDs, and obvious issues - when `verify-live-gtm` was run, separate parsed live definitions from browser-verified live firing evidence - if this review is part of `tracking_health_audit`, clearly separate runtime-detected live definitions from any formal preview-verified automation evidence - stop before schema authoring if the user wants to review the live baseline first ## Required Output Produce and share: - `<artifact-dir>/live-gtm-analysis.json` - `<artifact-dir>/live-gtm-review.md` - optional `<artifact-dir>/live-preview-result.json` - optional `<artifact-dir>/live-preview-report.md` - optional `<artifact-dir>/live-tracking-health.json` - updated `<artifact-dir>/workflow-state.json` ## Closeout Style - default to a compact live-tracking summary before listing files - name the detected live events directly instead of only reporting event counts - in `tracking_health_audit`, explicitly separate runtime-detected live definitions from formal preview-verified automation evidence - list artifacts only after the decision-ready summary ## Stop Boundary Stop after the live GTM baseline is reviewed unless the user explicitly asks to continue into schema work. Default next phase: ```bash ./event-tracking prepare-schema <artifact-dir>/site-analysis.json ``` ## References - [../../references/event-schema-guide.md](../../references/event-schema-guide.md) - [../../references/output-contract.md](../../references/output-contract.md) - [../../references/architecture.md](../../references/architecture.md)
Use when you need GA4 + GTM tracking delivery from site discovery through publish, or when the right phase entry point is still unclear.
Use when the user wants crawl coverage, platform detection, dataLayer discovery, or a fresh artifact directory before grouping and schema work.
Use when the work starts from `site-analysis.json` and the user wants page-group authoring, grouping adjustments, or page-group approval.
Use when the user wants schema preparation, event design, selector validation, schema review, or event-spec generation.
Use when the platform is Shopify or the run needs the Shopify-specific schema, sync, install, or verification branch.
Use when the user wants GTM-ready config generation, GTM workspace sync, or container selection from an approved schema.
Use when the user wants preview QA, failure interpretation, release readiness, or an explicit publish handoff.