product-tracking-skills

Proactive tracking coverage monitor. Use automatically after code changes that add new features, modify existing functionality, or change user-facing behavior. Checks whether the tracking plan covers the changes and suggests new events, properties, or tracking updates when gaps are found. Runs in the background and only reports when it finds something actionable. Use proactively whenever feature development is happening — do not wait to be asked.

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 the user wants to know what's currently tracked, audit existing analytics, capture tracking reality before designing a new plan, 'what analytics do we have,' 'what events are tracked,' 'scan for tracking,' or 'tracking inventory.'

Write a business case for adding product telemetry and analytics to a product. Produces a concise, stakeholder-ready document explaining what telemetry enables, what you're currently blind to, what's involved in implementation, and the business value. Sits outside the main telemetry lifecycle — use before committing to the technical work. Use when the user asks to 'write a business case,' 'justify analytics,' 'make the case for tracking,' 'telemetry brief,' 'why add analytics,' 'convince leadership about tracking,' or 'analytics ROI.'

Design an opinionated target tracking plan and produce an explicit delta from current state to target. Combines the product model, current-state audit, and telemetry best practices to decide what events, properties, entities, and group hierarchies should exist. Outputs .telemetry/tracking-plan.yaml and .telemetry/delta.md. Use when the user wants to create or redesign a tracking plan, decide what to track, plan analytics instrumentation, 'design tracking,' 'what should we track,' 'create tracking plan,' or 'plan analytics events.'

Translate a tracking plan into an SDK-specific instrumentation guide. Shows how to make identify, group, and track calls using the target analytics SDK with real template code, architecture guidance, and constraint documentation. Outputs .telemetry/instrument.md. Covers 24 analytics destinations across product analytics, CDPs, web analytics, error monitoring, feature flags, and session tools. Use when the user has a tracking plan and needs to know how to implement it with a specific SDK like Segment, Amplitude, Mixpanel, PostHog, Accoil, Google Analytics, Sentry, LaunchDarkly, or via generic HTTP POST. Also use when user asks 'create instrumentation guide,' 'how to implement tracking,' 'SDK guide,' or 'generate implementation guide.'

Generate real instrumentation code from the tracking plan and instrumentation guide. Produces typed SDK wrapper functions, identity management, and integration guidance. Outputs files in a tracking/ directory. Use when the user wants to generate or regenerate tracking code, implement the delta plan, turn the instrumentation guide into working code, 'implement tracking,' 'generate code,' 'create tracking module,' or 'build analytics SDK wrapper.'

Update the tracking plan when a feature ships, changes, or is removed. Assesses whether new events are needed, extends existing events with properties where possible, and produces a versioned mini-delta with changelog entry. Updates .telemetry/tracking-plan.yaml, delta.md, and changelog.md. Use when the user ships a new feature, modifies existing functionality, wants to keep tracking coherent as the product evolves, 'feature shipped,' 'new feature tracking,' 'update tracking for [feature],' 'what tracking does this feature need,' or 'instrument new feature.'

Build a structured product model by scanning the codebase and talking to the user. Produces .telemetry/product.md — a description of what the product does, who uses it, how value flows, and what entities exist. Use when starting telemetry work on a new codebase, when the user asks to 'model this product,' 'understand this product,' 'what does this product do,' 'map the product,' 'product model,' or when no .telemetry/product.md exists yet. This is the entry point for the telemetry lifecycle.