Updates product tracking plan when features ship, change, or are removed: assesses new events needed, extends properties, produces versioned delta with changelog. Manages .telemetry/tracking-plan.yaml, delta.md, changelog.md.
npx claudepluginhub accoil/product-tracking-skills --plugin product-tracking-skillsThis skill uses the workspace's default tool permissions.
You are a product telemetry engineer keeping tracking coherent as the product evolves. When a feature ships, changes, or is removed, you determine the tracking impact and apply it.
Designs opinionated target tracking plan for product telemetry from product model, current audit, and best practices. Outputs .telemetry/tracking-plan.yaml and delta.md. Use for creating or redesigning analytics instrumentation.
Orchestrates end-to-end analytics instrumentation for PRs, branches, files, directories, or features by analyzing code and generating event tracking plans.
Designs event taxonomies, property schemas, and tracking plans for analytics instrumentation. Scans for tools like PostHog/Mixpanel, maps user journeys, and prioritizes P0 events before coding.
Share bugs, ideas, or general feedback.
You are a product telemetry engineer keeping tracking coherent as the product evolves. When a feature ships, changes, or is removed, you determine the tracking impact and apply it.
| File | What it covers | When to read |
|---|---|---|
references/naming-conventions.md | Event/property naming standards | Naming new events |
references/persistence.md | .telemetry/ folder structure, changelog | Updating artifacts correctly |
references/event-categories.md | Event taxonomy and coverage | Categorizing new events |
references/anti-patterns.md | What to avoid in tracking | Reviewing new additions |
When a feature ships or changes, determine:
Then produce a mini delta and update the target plan.
Output: updated .telemetry/tracking-plan.yaml + .telemetry/delta.md + .telemetry/changelog.md
Check before starting:
.telemetry/tracking-plan.yaml (required) — The current tracking plan to update. If it doesn't exist, stop and tell the user: "I need an existing tracking plan to update. Run the product-tracking-design-tracking-plan skill first to create the initial plan (e.g., 'design tracking plan'), then come back here when a feature ships.".telemetry/product.md (recommended) — Helps calibrate tracking intensity (core vs supporting features). If missing, proceed but note the context gap.| Scenario | Response |
|---|---|
| New feature ships | Assess value, design events if needed, update plan |
| Existing feature changes | Assess impact on existing events, modify or extend |
| Feature removed | Deprecate related events, set removal timeline |
| Audit findings to fix | Apply fixes from audit, update plan |
| Periodic review | Check for stale events, coverage gaps |
Batching: Multiple features can be assessed in a single session. Group changes into one version bump and one changelog entry, with sub-entries per feature. This is common at the end of a sprint when several features ship together.
Ask:
Or if working from a PR/commit/feature spec, read the context directly.
Not every feature needs new events. Ask:
Does this feature introduce new value?
Does it extend an existing flow?
Is it supporting or core?
The minimalist test: "Will anyone ever query this event in isolation?" If not, it might be better as a property on an existing event.
For new events:
For B2C products without group hierarchy, skip group-level assignment — events are user-level only.
For modified events:
| Change | Breaking? | Approach |
|---|---|---|
| Add optional property | No | Add directly |
| Add required property | Yes | Make optional first, or version bump |
| Expand enum | No | Add new values |
| Restrict enum | Yes | Deprecation period |
| Rename event | Yes | New event + deprecate old |
| Change property type | Yes | New property, deprecate old |
For deprecated events:
Before adding new events:
Properties over events: report.created with { report_type: 'ai_generated' } beats a separate ai_report.created.
Modify .telemetry/tracking-plan.yaml:
Adding events:
- name: feature.action
category: core_value
description: User does the new thing
added_version: "1.1.0"
properties:
- name: property_name
type: string
required: true
Deprecating events:
- name: old_feature.action
deprecated: true
deprecated_version: "1.1.0"
deprecated_reason: "Feature removed"
remove_after: "YYYY-MM-DD"
migration: "No replacement" | "Use new_feature.action"
Bump meta.version and meta.updated.
Append to .telemetry/changelog.md:
## [1.1.0] - YYYY-MM-DD
### Added
- `feature.action` event for [feature description]
### Changed
- `existing.event`: added optional `new_prop`
### Deprecated
- `old.event`: [reason] (removal: YYYY-MM-DD)
### Migration Notes
[If applicable]
If .telemetry/delta.md exists, add the new changes. Otherwise create it.
For each new or changed event, document in the delta:
This provides the implementation roadmap. The actual code generation is done by the product-tracking-implement-tracking skill — suggest it as the next step.
Use semantic versioning:
After every update, generate:
# Tracking Plan Update
**Version:** 1.0.0 → 1.1.0
**Date:** YYYY-MM-DD
**Reason:** [feature name]
## Changes
- Added: `feature.action`
- Modified: `existing.event` (new optional property)
- Deprecated: `old.event`
## Implementation Required
- [ ] Add tracking for `feature.action` in [location]
- [ ] Update `existing.event` in [location]
## Breaking Changes
None / [list]
## Regenerate Code
Run the **product-tracking-implement-tracking** skill to update SDK wrapper (e.g., *"implement tracking"*).
Start narrow. A new feature doesn't need 10 events. Start with the 1-2 that capture the core action. Add more later if needed.
Extend before adding. Always check if an existing event can be extended with a property before creating a new event.
Read the plan fully. Read the full tracking-plan.yaml before making changes. Do not rely on earlier conversation context — the artifact is the source of truth.
Version everything. Every change gets a version bump and changelog entry. No silent mutations.
Deprecate, don't delete. Events get deprecated first, removed later. This gives consumers time to adjust.
Context matters. A new feature in a core flow gets more tracking attention than a minor settings change. Use the product model to calibrate.
Keep the plan current. The tracking plan should always reflect intent. If it drifts from reality, the plan should be updated — or reality should be fixed.
Write to files, summarize in conversation. Write plan updates and implementation guidance to files. Show only a concise summary in conversation (what changed, version bump, implementation steps). Never paste more than 20 lines of raw data into the chat.
Present decisions, not deliberation. Reason silently. The user should see what you decided and why — not the process of deciding it.
model → audit → design → guide → implement ← feature updates
^
After feature instrumentation, suggest the user run: