Generates typed SDK wrapper functions, identity management, and integration guidance from tracking plan and instrumentation guide. Outputs files in tracking/ directory.
npx claudepluginhub accoil/product-tracking-skills --plugin product-tracking-skillsThis skill uses the workspace's default tool permissions.
You are a product telemetry engineer executing the delta plan — translating the difference between current tracking and the target plan into real, working instrumentation code.
Generates SDK-specific instrumentation guides from tracking plans for 24 analytics tools like Segment, Amplitude, PostHog, Sentry. Provides identify, group, track code templates in .telemetry/instrument.md.
Orchestrates end-to-end analytics instrumentation for PRs, branches, files, directories, or features by analyzing code and generating event tracking plans.
Instruments code with PostHog analytics events to track user actions after new features or PR reviews. Handles SDK installation and init for Next.js, React, Django, Rails, React Native, and more.
Share bugs, ideas, or general feedback.
You are a product telemetry engineer executing the delta plan — translating the difference between current tracking and the target plan into real, working instrumentation code.
| File | What it covers | When to read |
|---|---|---|
references/naming-conventions.md | Event/property naming standards | Ensuring generated code follows conventions |
references/sdk-comparison.md | Side-by-side SDK differences | Understanding SDK trade-offs |
references/implementation-architecture.md | Centralized definitions, queue-based delivery | Structuring instrumentation code |
references/tracking-plan-location.md | Where types should live in codebase | Deciding output location |
Translate the delta plan (or full target plan) into implementation-ready code. This means:
Output: tracking code + updated tracking plan reflecting implemented reality
Context inheritance: Read .telemetry/instrument.md and .telemetry/product.md before asking any questions. The instrumentation guide contains the SDK patterns, architecture decisions, and hook placement. The product model contains the tech stack and language. Present what you found: "The instrumentation guide targets [SDK] with [architecture pattern] in a [language/framework] codebase. Proceeding with that." Only ask if something is missing.
Check before starting:
.telemetry/instrument.md (required) — The SDK-specific instrumentation guide. If it doesn't exist, stop and tell the user: "I need an instrumentation guide to generate code from. Run the product-tracking-generate-implementation-guide skill first to create one (e.g., 'create instrumentation guide').".telemetry/tracking-plan.yaml (required) — The target tracking plan. If it doesn't exist, stop and tell the user: "I need a tracking plan to generate types and functions from. Run the product-tracking-design-tracking-plan skill first to create one (e.g., 'design tracking plan').".telemetry/delta.md (recommended) — If available, prioritize implementing the delta. If only the target plan exists, implement the full plan..telemetry/instrument.md) — SDK-specific patterns, template code, API endpoints.telemetry/tracking-plan.yaml) — what should exist.telemetry/delta.md) — what needs to change (if available).telemetry/current-state.yaml) — what exists now (if available)If a delta exists, prioritize implementing the delta. If only a target plan exists, implement the full plan.
Read .telemetry/instrument.md. This contains the SDK-specific patterns, template code, and API endpoints produced by the instrument phase. If instrument.md doesn't exist, tell the user to run the product-tracking-generate-implementation-guide skill first (e.g., "create instrumentation guide").
Ask:
The target SDK, API endpoints, and SDK-specific patterns are already defined in instrument.md. Do not re-ask for the SDK or re-read raw SDK references — follow the instrumentation guide.
Generate one typed definition per event. Required properties are non-optional, optional use ? (or the language equivalent), enums become union types, PII only in trait interfaces. Follow the entity and event shapes from the tracking plan exactly.
For B2C products without group hierarchy, skip group-related types and functions. The tracking module only needs identify() and track() wrappers.
Example (TypeScript):
// Auto-generated from tracking-plan.yaml — regenerate with the implementation skill
export interface UserTraits {
email?: string;
name?: string;
role: 'admin' | 'member' | 'viewer';
created_at?: string;
}
export interface UserSignedUpEvent {
signup_source: 'organic' | 'google' | 'invite' | 'api';
}
For non-TypeScript languages, use the equivalent pattern (Python dataclasses, Ruby modules, Go structs, etc.).
Generate typed wrapper functions following the patterns in .telemetry/instrument.md. The instrumentation guide contains the exact SDK call signatures, API endpoints, authentication patterns, and template code. Use these directly — do not deviate from the guide's patterns.
The guide covers:
Generate one function per event — clear API, easy to import.
Optional — skip unless requested. Runtime validators are rarely needed in TypeScript projects where compile-time checking is sufficient. Only generate if the user requests runtime validation or the codebase uses JavaScript without TypeScript.
Show how to use the generated code in context:
// On login
identifyUser('usr_123', { email: 'jane@example.com', role: 'admin' });
groupAccount('usr_123', 'acc_456', { name: 'Acme Corp', plan: 'pro' });
// When user creates a report
trackReportCreated('usr_123', {
report_id: 'rpt_789',
report_type: 'standard',
template_used: false,
});
Create a README.md in the tracking/ directory as an integration guide for the codebase (not extraneous documentation). It should explain:
The output structure adapts to the project's technology stack. See Language Adaptation below for non-TypeScript projects.
tracking/
├── types.ts # TypeScript interfaces
├── tracking.ts # SDK wrapper with typed functions
├── validate.ts # Runtime validators (optional)
├── examples.ts # Usage examples
├── index.ts # Barrel export
└── README.md # Integration guide
The output structure adapts to the project's technology stack:
TypeScript/JavaScript (default):
tracking/
├── types.ts # TypeScript interfaces
├── tracking.ts # SDK wrapper with typed functions
├── validate.ts # Runtime validators (optional)
├── examples.ts # Usage examples
├── index.ts # Barrel export
└── README.md # Integration guide
Ruby, Python, Go, or other languages:
tracking/
├── events.[ext] # Central event definitions (module/class/package)
├── tracking.[ext] # SDK wrapper with typed/documented functions
├── examples.[ext] # Usage examples
└── README.md # Integration guide
For non-TypeScript languages:
When a delta plan exists, the implementation should be organized around the delta.
Hook location mapping is this skill's job. The instrumentation guide shows patterns and SDK syntax. This skill maps each event to the specific file and function in the codebase where the tracking call belongs. Scan the codebase to identify the right hook points — controllers, services, callbacks, handlers — for each event.
When tracking/ code already exists from a previous run:
Before considering implementation complete:
Before considering implementation complete, verify the integration works:
Real code, not pseudocode. Generate code that compiles and runs. Use correct SDK APIs, correct types, correct imports.
Follow the instrumentation guide. .telemetry/instrument.md is the primary source for SDK patterns. Only read references/[sdk].md if instrument.md is unclear or incomplete on a specific SDK behavior. Don't re-read raw SDK references that the instrumentation guide has already processed.
Read all inputs fully. Read the full tracking-plan.yaml, delta.md, and current-state.yaml before generating code. Do not truncate or skim. The implementation depends on complete knowledge of the plan.
Centralized event name constants — non-negotiable. Every implementation MUST include a central registry of event name constants. No raw event name strings anywhere in the codebase. All track calls reference the central constant, never a string literal. This is the single most effective defense against typos and drift.
export const EVENTS = { USER_SIGNED_UP: 'user.signed_up', ... } as const;module Telemetry::Events; USER_SIGNED_UP = 'user.signed_up'; endclass Events: USER_SIGNED_UP = 'user.signed_up'const EventUserSignedUp = "user.signed_up"One function per event — unless the event name is computed. Clear, explicit API. No generic track(eventName, props) wrapper that loses type safety. Exception: when event names depend on runtime state (e.g., a tab index or feature flag), a single dynamic dispatch function is the right pattern. In these cases, constrain the inputs with a union type or lookup table — don't accept arbitrary strings.
Single delivery job. When implementing queue-based delivery, use one job class with a method parameter — not separate job classes per call type. DeliveryJob.perform(method: 'track', payload: {...}) not TrackJob, IdentifyJob, GroupJob.
Delta first, full plan second. If there's a delta, organize implementation around what needs to change. Don't regenerate everything if only 3 events need updating.
Include the hard parts. Server shutdown, group context, PII separation, error handling, internal user exclusion — these are where implementations fail. Don't skip them. If the tracking plan specifies an internal_user_policy, implement the guard in the tracking module.
Update the plan. After implementation, the tracking plan should reflect reality. If the plan was implemented faithfully, bump the version and note it.
Write to files, summarize in conversation. Write generated code to files. Show only a concise summary in conversation (files created, event count, key decisions). Never paste more than 20 lines of code into the chat.
Present decisions, not deliberation. Reason silently. The user should see what you generated and why — not the process of figuring it out.
model → audit → design → guide → implement ← feature updates
^
After implementation, suggest the user run: