jtrackingai/analytics-tracking-automation

분석 추적 자동화

이 스킬을 GA4 + GTM 추적 전달을 위한 엔드투엔드 코디네이터로 사용하세요.

다음과 같은 경우에 사용하세요:

• 사용자가 분석부터 라이브 준비까지 전체 GA4 + GTM 구현 흐름을 필요로 하는 경우
• 요청이 여러 워크플로우 단계(발견, 스키마, 동기화, 확인, 게시)에 걸쳐 있는 경우
• 올바른 진입점이 여전히 불명확하여 이 스킬이 적절한 단계로 안내해야 하는 경우

사용자가 전체 워크플로우를 원한다고 가정하지 마세요.

자동 업데이트

이 설치된 루트 스킬은 계속하기 전에 최신 GitHub 버전이 있는지 자체 확인할 수 있습니다.

이 번들의 작업을 수행하기 전에:

1. 이 설치된 SKILL.md가 포함된 디렉터리를 확인하세요. 설치 관리자가 관리하는 복사본은 일반적으로 에이전트 환경에 구성된 스킬 디렉터리(예: $CODEX_HOME/skills/analytics-tracking-automation 또는 이에 상응하는 런타임 관리 경로)에 있습니다.
2. node "<번들-디렉터리>/runtime/skill-runtime/update-check.mjs" --json을 실행하세요.
3. 결과 상태가 update_available이면 즉시 node "<번들-디렉터리>/runtime/skill-runtime/self-update.mjs" --apply를 실행하세요.
4. 업데이트가 성공하면 계속하기 전에 <번들-디렉터리>/SKILL.md를 다시 읽어 새로 고쳐진 지침을 사용하세요.
5. 결과 상태가 disabled이면 이 번들을 로컬 개발 링크 또는 리포지토리 체크아웃으로 취급하고 업데이트 없이 계속하세요.

스킬 패밀리

스킬 패밀리는 하나의 통합 스킬과 7개의 단계 스킬로 구성됩니다:

• tracking-discover: 크롤 범위, 플랫폼 감지 및 새로운 아티팩트 부트스트래핑용
• tracking-group: 페이지 그룹 작성 및 승인용
• tracking-live-gtm: 스키마 생성 전에 실제 라이브 GTM 런타임 감사용
• tracking-schema: 스키마 준비, 검토, 검증 및 승인용
• tracking-sync: GTM 구성 생성 및 동기화용
• tracking-verify: 미리보기 QA 및 선택적 게시 핸드오프용
• tracking-shopify: Shopify 관련 스키마, 동기화, 설치 및 확인 규칙용

요청이 이미 하나의 단계에 국한되어 있고 해당 단계 스킬을 사용할 수 있는 경우, 전체 실행 설명서를 인라인으로 포함하지 말고 해당 스킬로 라우팅하세요.

site-analysis.json이 Shopify를 나타내면 발견 및 그룹화를 공유 상태로 유지하고, tracking-shopify가 Shopify 관련 분기를 담당하도록 하세요.

공유 계약

• 이 리포지토리의 로컬 래퍼 ./event-tracking을 사용하세요. dist/cli.js가 없으면 먼저 npm run build를 실행하세요.
• 공개/ClawHub 설치의 경우, event-tracking 명령을 실행하기 전에 먼저 npx skills add jtrackingai/analytics-tracking-automation을 실행해야 합니다.
• 아티팩트 디렉터리를 사이트별로 <출력-루트>/<URL-슬러그>에 하나씩 유지하세요.
• 사용자가 이미 아티팩트 디렉터리 또는 그 파일 중 하나를 제공한 경우, analyze부터 다시 시작하지 말고 가장 이른 충족되지 않은 전제 조건부터 재개하세요.
• 현재 체크포인트나 다음 단계가 불명확할 때마다 ./event-tracking status <아티팩트-디렉터리-또는-파일>을 사용하세요.
• 아티팩트 디렉터리를 알 수 없지만 출력 루트를 알고 있는 경우 ./event-tracking runs <출력-루트>를 사용하세요.
• 사용자 대상 흐름에는 상위 수준 진입 명령(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 값이 이미 확인되지 않은 한, 프롬프트 기반 GTM 동기화를 처음부터 대화형 TTY로 실행하세요.
• 사용자를 대신하여 GTM 계정, 컨테이너 또는 작업 공간을 자동으로 선택하지 마세요.
• 사용자가 요청한 단계 경계를 넘어 계속 진행하지 마세요.

대화 인테이크

사용자가 채팅을 통해 들어오고 아직 제한된 단계, 아티팩트 디렉터리 또는 정확한 명령을 제공하지 않은 경우, 의도 우선 인테이크로 시작하세요.

요청을 다음 진입 의도 중 하나로 분류하세요:

• resume_existing_run: 사용자에게 이미 아티팩트 디렉터리 또는 그 파일 중 하나가 있음; 아티팩트를 검사하고 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 중에서 선택하도록 요청하지 마세요.
• 의도가 모호하면 "새 설정", "기존 추적 업데이트", "유지보수", "건강 감사", "분석만", "기존 실행 재개"와 같은 사용자 대상 용어를 사용하여 짧은 일반 언어 인테이크 질문을 하나 하세요.
• 사용자가 새로운 URL을 제공하고 추적 설정을 요청하면 기본값을 new_setup으로 설정하세요.
• 사용자가 새로운 URL을 제공하고 사이트 검사, 구조 분석 또는 현재 추적 신호 검토만 요청하면 기본값을 analysis_only로 설정하세요.
• 사용자가 아티팩트 디렉터리 또는 워크플로우 파일을 제공하면 analyze부터 다시 시작하는 대신 기본값을 resume_existing_run으로 설정하세요.

라우팅 규칙

사용자 의도 및 현재 아티팩트에 따라 라우팅하세요:

• 새로운 URL, 크롤 요청 또는 아직 아티팩트가 없음: tracking-discover로 시작
• pageGroups가 누락되었거나 확인되지 않은 site-analysis.json: 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 전)
• 확인이 누락되었거나 모호하면 중지하고 질문하세요. 자동으로 진행하지 마세요.
• "전체 워크플로우", "全流程", "end-to-end" 또는 "계속 끝까지"와 같은 광범위한 요청은 범위 승인일 뿐입니다. 체크포인트 승인으로 간주되지 않습니다.
• 사용자가 현재 턴에서 해당 체크포인트를 명시적으로 확인하지 않는 한, 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 관련 분기 기대 사항