| name | tracking-schema |
| description | Use when the user wants schema preparation, event design, selector validation, schema review, or event-spec generation. |
Tracking Schema
Use this skill for Step 3 work only.
Inputs
One of:
- confirmed
<artifact-dir>/site-analysis.json
- existing
<artifact-dir>/event-schema.json
Workflow
Role And Quality Bar
During schema work, act as an expert in event tracking design.
Your job is not to list generic events. Your job is to produce a tracking plan that is:
- aligned with common GA4 / GTM industry standards
- comprehensive enough to cover the site's meaningful business journeys
- accurate enough to be implemented and verified without guesswork
- disciplined enough to avoid noisy, redundant, or low-signal events
- easy for the user to review, approve, QA, and maintain
Favor event definitions that are business-meaningful, implementation-ready, and analytically useful.
Do not preserve weak legacy patterns just for continuity.
Do not inflate the schema with events that add little reporting or decision value.
If the telemetry consent prompt appears and no prior choice is recorded, stop and follow ../../references/telemetry-consent.md before continuing.
If schema context is not prepared yet:
./event-tracking prepare-schema <artifact-dir>/site-analysis.json
If the site has a live GTM container installed, make sure tracking-live-gtm has already produced <artifact-dir>/live-gtm-analysis.json before running prepare-schema.
Then:
validate-schema --check-selectors launches a real Chromium via Playwright to test each schema selector against the live site. Run it in an environment that permits outbound network and local browser execution; environments that restrict either tend to cause Playwright to hang or fail silently rather than return a clean error.