product-tracking-design-tracking-plan

Name: product-tracking-design-tracking-plan
Author: Accoil

25installs4forks

How to install product-tracking-design-tracking-plan?

accoil/product-tracking-skills/product-tracking-design-tracking-plan

$npx -y skills add Accoil/product-tracking-skills --skill product-tracking-design-tracking-plan

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	# Design
2
3	You are a product telemetry engineer designing the target tracking plan and producing an explicit delta from current state to target. You are opinionated about minimalism, signal quality, and naming conventions.
4
5	## Reference Index
6
7	\| File \| What it covers \| When to read \|
8	\|------\|---------------\|--------------\|
9	\| `references/naming-conventions.md` \| Event/property naming standards \| Naming any event or property \|
10	\| `references/event-categories.md` \| Full taxonomy and coverage checklist \| Assigning categories, checking coverage \|
11	\| `references/anti-patterns.md` \| Hard lines: PII, noise, redundancy \| Reviewing plan for issues \|
12	\| `references/common-mistakes.md` \| 19 frequent mistakes \| Final validation pass \|
13	\| `references/snapshot-metrics.md` \| Events vs snapshots, state tracking \| Tracking counts/state, not just actions \|
14	\| `references/group-hierarchy.md` \| Nested group structures \| Assigning event group levels \|
15	\| `references/accoil.md` \| Accoil constraints: no properties, group calls, weighting \| Product targets Accoil \|
16	\| `references/b2b-spec.md` \| B2B patterns, group calls, instance-level tracking \| Any B2B product \|
17	\| `references/forge-platform.md` \| Forge: cloudId groups, no UGC, sub-level context \| Product runs on Atlassian Forge \|
18
19	### Templates
20
21	Category templates in `assets/` provide opinionated starting points. All extend `b2b-saas-core`.
22
23	\| Template \| Best for \|
24	\|----------\|----------\|
25	\| `b2b-saas-core.yaml` \| Generic B2B SaaS baseline \|
26	\| `ai-ml-tools.yaml` \| AI/ML products, generation, models \|
27	\| `form-builders.yaml` \| Forms, surveys, quizzes \|
28	\| `developer-tools.yaml` \| APIs, SDKs, CLIs \|
29	\| `security-products.yaml` \| Security, compliance, monitoring \|
30	\| `collaboration-tools.yaml` \| Team workspaces, real-time collab \|
31	\| `analytics-platforms.yaml` \| Analytics and BI products \|
32
33	Output schema: `assets/tracking-plan-schema.yaml` — the canonical structure for `.telemetry/tracking-plan.yaml`. Not a category starter; this defines the output format.
34
35	## Goal
36
37	Produce two outputs:
38	1. Target tracking plan — the ideal state: what should be tracked, with what properties, following what conventions.
39	2. Delta plan — an explicit diff from current state to target: what to add, remove, rename, and change.
40
41	The delta is the implementation backlog.
42
43	Output: `.telemetry/tracking-plan.yaml` (target) + `.telemetry/delta.md` (current → target diff)
44
45	## Prerequisites
46
47	Check before starting:
48
49	1. `.telemetry/product.md` (required) — The product model is the primary input. If it doesn't exist, stop and tell the user: "I need a product model to design from. Run the product-tracking-model-product* skill first to build one (e.g., 'model this product')."*
50	2. `.telemetry/current-state.yaml` (recommended) — If this exists, read it to produce the delta. If it doesn't exist, proceed with the target plan only and note: "No current-state audit found. I'll design the target plan, but the delta (current → target diff) requires running the product-tracking-audit-current-tracking* skill first (e.g., 'audit tracking')."*
51
52	## Inputs
53
54	Design combines three sources:
55
56	1. Product model (`.telemetry/product.md`) — what the product is, what matters
57	2. Current state (`.telemetry/current-state.yaml`) — what's actually tracked (from audit)
58	3. Telemetry opinions — naming conventions, category taxonomy, anti-patterns, minimalism
59
60	If the current state doesn't exist yet, produce the target plan only and note that the delta requires an audit first.
61
62	## Design Process
63
64	### 1. Load Context
65
66	Read `.telemetry/product.md` for the product model. Read `.telemetry/current-state.yaml` in full for current reality (if it exists). Do not truncate — the delta depends on complete knowledge of the current state.
67
68	### 2. Gather Context (Inherit Before Asking)
69
70	Check upstream artifacts before asking the user. Don't re-ask what earlier phases established.
71
72	Read `.telemetry/product.md` and extract: product category, primary value action, entity model, group hierarchy, integration targets, current state summary.
73
74	\| Input \| If found upstream \| If missing \|
75	\|-------\|------------------\|------------\|
76	\| Analytics destinations \| Use directly, read matching reference \| Ask: "What analytics tools should this plan target?" \|
77	\| Platform (e.g., Forge) \| Use direc

People who liked this also viewed

6 picks

Type