product-tracking-instrument-new-feature

Name: product-tracking-instrument-new-feature
Author: Accoil

26installs4forks

How to install product-tracking-instrument-new-feature?

accoil/product-tracking-skills/product-tracking-instrument-new-feature

$npx -y skills add Accoil/product-tracking-skills --skill product-tracking-instrument-new-feature

Installs into the current project.

Summary

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 ch

Files · 1

View on GitHub

SKILL.md

1	# Feature Instrumentation
2
3	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.
4
5	## Reference Index
6
7	\| File \| What it covers \| When to read \|
8	\|------\|---------------\|--------------\|
9	\| `references/naming-conventions.md` \| Event/property naming standards \| Naming new events \|
10	\| `references/persistence.md` \| `.telemetry/` folder structure, changelog \| Updating artifacts correctly \|
11	\| `references/event-categories.md` \| Event taxonomy and coverage \| Categorizing new events \|
12	\| `references/anti-patterns.md` \| What to avoid in tracking \| Reviewing new additions \|
13
14	## Goal
15
16	When a feature ships or changes, determine:
17	1. Does this need new tracking?
18	2. Does it modify existing tracking?
19	3. Does it need no tracking changes?
20
21	Then produce a mini delta and update the target plan.
22
23	Output: updated `.telemetry/tracking-plan.yaml` + `.telemetry/delta.md` + `.telemetry/changelog.md`
24
25	## Prerequisites
26
27	Check before starting:
28
29	1. `.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."*
30	2. `.telemetry/product.md` (recommended) — Helps calibrate tracking intensity (core vs supporting features). If missing, proceed but note the context gap.
31
32	## Trigger Scenarios
33
34	\| Scenario \| Response \|
35	\|----------\|----------\|
36	\| New feature ships \| Assess value, design events if needed, update plan \|
37	\| Existing feature changes \| Assess impact on existing events, modify or extend \|
38	\| Feature removed \| Deprecate related events, set removal timeline \|
39	\| Audit findings to fix \| Apply fixes from audit, update plan \|
40	\| Periodic review \| Check for stale events, coverage gaps \|
41
42	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.
43
44	## Process
45
46	### 1. Understand the Change
47
48	Ask:
49	- "What feature shipped or changed?"
50	- "What are the key user actions in this feature?"
51	- "Is this core value or supporting functionality?"
52
53	Or if working from a PR/commit/feature spec, read the context directly.
54
55	### 2. Assess Tracking Need
56
57	Not every feature needs new events. Ask:
58
59	Does this feature introduce new value?
60	- New user action that delivers value → probably needs an event
61	- UI rearrangement of existing functionality → probably doesn't
62
63	Does it extend an existing flow?
64	- New step in existing workflow → maybe extend existing event with property
65	- New variant of existing action → add enum value, not new event
66
67	Is it supporting or core?
68	- Core value feature → first-class event with rich properties
69	- Supporting feature → appropriate but lighter coverage
70
71	The minimalist test: "Will anyone ever query this event in isolation?" If not, it might be better as a property on an existing event.
72
73	### 3. Design the Mini Delta
74
75	For new events:
76	- Follow naming conventions (object.action, snake_case)
77	- Assign category
78	- Define properties with types
79	- Set expected frequency
80	- Assign group level
81
82	For B2C products without group hierarchy, skip group-level assignment — events are user-level only.
83
84	For modified events:
85	- Assess breaking impact:
86
87	\| Change \| Breaking? \| Approach \|
88	\|--------\|-----------\|----------\|
89	\| Add optional property \| No \| Add directly \|
90	\| Add required property \| Yes \| Make optional first, or version bump \|
91	\| Expand enum \| No \| Add new values \|
92	\| Restrict enum \| Yes \| Deprecation period \|
93	\| Rename event \| Yes \| New event + deprecate old \|
94	\| Change property type \| Yes \| New property, deprecate old \|
95
96	For deprecated events:
97	- Mark deprecated with reason and removal date
98	- Document migration path if replacement exists
99	- Keep in plan until removal date, then clean up
100
101	### 4. Check Against Existing Events
102
103	Before adding new events:
104	- Is there a similar event that could be extended with a property?
105	- Would adding to an existing event make sense?
106	- Are you creating a near-duplicate?
107
108	**P

People who liked this also viewed

6 picks

Type