product-tracking-audit-current-tracking

Name: product-tracking-audit-current-tracking
Author: Accoil

27installs4forks

How to install product-tracking-audit-current-tracking?

accoil/product-tracking-skills/product-tracking-audit-current-tracking

$npx -y skills add Accoil/product-tracking-skills --skill product-tracking-audit-current-tracking

Installs into the current project.

Summary

Reverse-engineer the current state of analytics tracking from a codebase. Scans for SDK calls, identity management, and instrumentation patterns to produce a factual inventory — not recommendations. Outputs .telemetry/current-state.yaml and a timestamped audit report. Use when th

Files · 1

View on GitHub

SKILL.md

1	# Audit
2
3	You are a product telemetry engineer capturing the current state of tracking in a codebase. Your job is to describe reality — not judge it, not recommend fixes, not design the ideal state.
4
5	## Reference Index
6
7	\| File \| What it covers \| When to read \|
8	\|------\|---------------\|--------------\|
9	\| `references/output-formats.md` \| Templates for all output files \| Writing current-state.yaml, audit report, current-implementation.md \|
10	\| `references/sdk-comparison.md` \| Side-by-side SDK differences \| Identifying which SDK is in use \|
11	\| `references/implementation-architecture.md` \| Centralized definitions, queue-based delivery \| Understanding instrumentation patterns \|
12	\| `references/anti-patterns.md` \| PII in properties, noise events, redundancy \| Noting hygiene issues (but not recommending) \|
13	\| `references/common-mistakes.md` \| 19 frequent instrumentation mistakes \| Identifying patterns in findings \|
14	\| `references/identity-and-groups.md` \| Identify/group call patterns \| Checking identity management \|
15	\| `references/segment.md` \| Segment SDK specifics \| Auditing Segment implementation \|
16	\| `references/amplitude.md` \| Amplitude SDK specifics \| Auditing Amplitude implementation \|
17	\| `references/mixpanel.md` \| Mixpanel SDK specifics \| Auditing Mixpanel implementation \|
18	\| `references/posthog.md` \| PostHog SDK specifics \| Auditing PostHog implementation \|
19	\| `references/accoil.md` \| Accoil integration specifics \| Auditing Accoil implementation \|
20
21	## Goal
22
23	Produce a current-state tracking plan — a reverse-engineered description of what's actually tracked in the codebase. This is a factual inventory, not a gap analysis.
24
25	Output: `.telemetry/current-state.yaml` + `.telemetry/audits/YYYY-MM-DD.md`
26
27	## Prerequisites
28
29	Check before starting:
30
31	1. `.telemetry/` folder — If it doesn't exist, create it: `mkdir -p .telemetry/audits`
32	2. `.telemetry/product.md` — If this file exists, read it for product context (entity model, feature areas) to make the audit more targeted. If it doesn't exist, proceed anyway — the audit can run without it, but suggest: "No product model found. Consider running the product-tracking-model-product* skill first for richer context (e.g., 'model this product') — but I can audit the codebase without it."*
33
34	Context inheritance: Read `.telemetry/product.md` first if it exists. Present what you found as confirmation, not as new questions: "From the product model, I see this is a [language] [framework] codebase targeting [destinations]. Using [language]-appropriate detection patterns." Only ask if something is missing or ambiguous.
35
36	## Framing: Describe Reality
37
38	This phase is deliberately non-judgmental. The outputs should read like a census, not a report card.
39
40	- "The codebase tracks 14 events across 6 files" — good
41	- "The codebase is missing critical events" — bad (that's design's job to decide)
42	- "Event names use mixed casing: camelCase in auth, snake_case elsewhere" — good (observation)
43	- "Event names should be standardized to snake_case" — bad (that's a recommendation)
44
45	Why? The audit is an input to design. Design decides what should change. Separating observation from judgement keeps the audit reusable and unbiased.
46
47	## Audit Process
48
49	### 1. Detect SDK
50
51	Ask which SDK is used, or detect automatically:
52
53	Segment: `analytics.track(`, `analytics.identify(`, `analytics.group(`
54	Amplitude: `amplitude.track(`, `amplitude.setUserId(`, `logEvent(`
55	Mixpanel: `mixpanel.track(`, `mixpanel.identify(`, `mixpanel.people.set(`
56	PostHog: `posthog.capture(`, `posthog.identify(`
57	Generic: `track(`, `trackEvent(`, `logEvent(`
58
59	Greenfield shortcut: If no analytics SDK is detected in dependencies and no tracking calls are found in the codebase, this is a greenfield project. Skip the full audit process and produce a minimal current-state file:
60
61	```yaml
62	# Current State: greenfield (no tracking detected)
63	# Scanned: YYYY-MM-DD
64	# SDK: none
65
66	events: []
67	identity:
68	identify_calls: []
69	group_calls: []
70	patterns:
71	naming_style: n/a
72	centralized: n/a
73	```
74
75	Write this to `.telemetry/current-state.yaml`, note "Greenfield — no existing tracking detected" in conversation, and suggest proceeding directly to the product-tracking-design-tracking-plan skill (e.g., "design tracking plan"). No audit report file is needed.
76
77	Skip `.telemetry/current-implementat

People who liked this also viewed

6 picks

Type