rudder-design-first-instrumentation

Name: rudder-design-first-instrumentation
Author: rudderlabs

18stars0forks

How to install rudder-design-first-instrumentation?

rudderlabs/rudder-agent-skills/rudder-design-first-instrumentation

$npx -y skills add rudderlabs/rudder-agent-skills --skill rudder-design-first-instrumentation

Installs into the current project.

Summary

Plans instrumentation for new features starting from product requirements before code exists. Use when building new features and need to define events as part of product definition.

Files · 1

View on GitHub

SKILL.md

1	# Design-First Instrumentation
2
3	This skill guides instrumentation planning for new features where events are defined during product definition, before implementation begins.
4
5	## When to Use This Skill
6
7	\| Scenario \| Use This Skill? \|
8	\|----------\|-----------------\|
9	\| Building a new feature, events not yet defined \| Yes \|
10	\| Product requirements include analytics needs \| Yes \|
11	\| PM and engineering collaborating on what to track \| Yes \|
12	\| Existing product needs instrumentation \| No — use `rudder-code-first-instrumentation` \|
13	\| Restructuring existing tracking \| No — use `rudder-code-first-instrumentation` \|
14
15	## The Design-First Workflow
16
17	```
18	┌─────────────────────────────────────────────────────────────────────┐
19	│ DESIGN-FIRST INSTRUMENTATION │
20	└─────────────────────────────────────────────────────────────────────┘
21	│
22	▼
23	┌─────────────────┐
24	│ 1. REQUIREMENTS │ ← What questions must the data answer?
25	└────────┬────────┘
26	▼
27	┌─────────────────┐
28	│ 2. EVENT DESIGN │ ← Define events (names only, no properties yet)
29	└────────┬────────┘
30	▼
31	┌─────────────────┐
32	│ 3. HUMAN │ ← PM/Eng review: Are these the right events?
33	│ CHECKPOINT │
34	└────────┬────────┘
35	▼
36	┌─────────────────┐
37	│ 4. PROPERTY │ ← Define properties for approved events
38	│ DESIGN │
39	└────────┬────────┘
40	▼
41	┌─────────────────┐
42	│ 5. BUILD YAML │ ← Create tracking plan definitions
43	└────────┬────────┘
44	▼
45	┌─────────────────┐
46	│ 6. IMPLEMENT │ ← Code the feature with instrumentation
47	└─────────────────┘
48	```
49
50	## Phase 1: Requirements Gathering
51
52	Start with the questions the data must answer:
53
54	### Questions Template
55
56	```markdown
57	## Feature: [Feature Name]
58
59	### Business Questions
60	- [ ] What is the conversion rate through this feature?
61	- [ ] Where do users drop off?
62	- [ ] How long does it take users to complete the flow?
63	- [ ] What variations do users prefer?
64
65	### Success Metrics
66	- Primary: _______________
67	- Secondary: _______________
68
69	### Funnel Stages
70	1. Entry point: _______________
71	2. Key action: _______________
72	3. Completion: _______________
73
74	### Stakeholders
75	- PM: _______________
76	- Engineering: _______________
77	- Data/Analytics: _______________
78	```
79
80	## Phase 2: Event Design (Names Only)
81
82	Define events as user stories or behavioral descriptions first — no properties yet.
83
84	### Event Description Format
85
86	Use clear, behavioral language:
87
88	```markdown
89	## Events for [Feature Name]
90
91	### Event: Feature Opened
92	- When: User opens the feature for the first time in a session
93	- Why track: Measures feature discovery and initial engagement
94	- Funnel position: Entry
95
96	### Event: Configuration Started
97	- When: User begins configuring the feature
98	- Why track: Measures intent to use feature
99	- Funnel position: Middle
100
101	### Event: Configuration Completed
102	- When: User successfully completes configuration
103	- Why track: Measures successful adoption
104	- Funnel position: Completion
105
106	### Event: Configuration Failed
107	- When: User encounters an error during configuration
108	- Why track: Identifies friction points
109	- Funnel position: Error state
110	```
111
112	### Naming Convention
113
114	\| Pattern \| Example \| Use For \|
115	\|---------\|---------\|---------\|
116	\| Feature + Action (Past Tense) \| `Audience Created` \| Completed actions \|
117	\| Feature + State \| `Checkout Started` \| State transitions \|
118	\| Object + Action \| `Product Viewed` \| Standard interactions \|
119
120	## Phase 3: Human Checkpoint
121
122	Critical: Before defining properties, get alignment on events.
123
124	### Review Checklist
125
126	- [ ] Do these events answer all the business questions?
127	- [ ] Is the funnel complete (entry → middle → completion)?
128	- [ ] Are error states captured?
129	- [ ] Are there redundant events that can be consolidated?
130	- [ ] Do event names follow conventions?
131
132	### Approval Gate
133
134	```markdown
135	## Event Review Sign-Off
136
137	Feature: _______________
138	Date: _______________
139
140	Approved Events:
141	- [ ] Event 1: _______________
142	- [ ] Event 2: _______________
143	- [ ] Event 3: _______________
144
145	Rejected/Deferred:
146	- [ ] _______________
147
148	Approved by:
149	- PM: _______________
150	- Engineering: _______________
151	```
152
153	## Phase 4: Property Design
154
155	After events are approved, define properties for each.
156
157	### Property Design Process
158
159	For each event, ask:
160
161	1. What context is needed to answer the business questions?
162	2. What attributes describe this action?
163	3. What will we group/filter by in dashboards?
164
165	### Property Template
166
167	```markdown
168	## Event: Audience Created
169
170	### Required Properties
171	\| Property \| Type \| Description \| Example \|
172	\|----------\|------\|-------------\|---------\|
173	\| audience_id \| string \| Unique identifier \| "aud_123" \|
174	\| audienc

People who liked this also viewed

6 picks

Type

rudder-design-first-instrumentation

18stars0forks

View on GitHub

How to install rudder-design-first-instrumentation?

rudderlabs/rudder-agent-skills/rudder-design-first-instrumentation

$npx -y skills add rudderlabs/rudder-agent-skills --skill rudder-design-first-instrumentation

Installs into the current project.

Summary

Plans instrumentation for new features starting from product requirements before code exists. Use when building new features and need to define events as part of product definition.

Files · 1

View on GitHub

SKILL.md

1	# Design-First Instrumentation
2
3	This skill guides instrumentation planning for new features where events are defined during product definition, before implementation begins.
4
5	## When to Use This Skill
6
7	\| Scenario \| Use This Skill? \|
8	\|----------\|-----------------\|
9	\| Building a new feature, events not yet defined \| Yes \|
10	\| Product requirements include analytics needs \| Yes \|
11	\| PM and engineering collaborating on what to track \| Yes \|
12	\| Existing product needs instrumentation \| No — use `rudder-code-first-instrumentation` \|
13	\| Restructuring existing tracking \| No — use `rudder-code-first-instrumentation` \|
14
15	## The Design-First Workflow
16
17	```
18	┌─────────────────────────────────────────────────────────────────────┐
19	│ DESIGN-FIRST INSTRUMENTATION │
20	└─────────────────────────────────────────────────────────────────────┘
21	│
22	▼
23	┌─────────────────┐
24	│ 1. REQUIREMENTS │ ← What questions must the data answer?
25	└────────┬────────┘
26	▼
27	┌─────────────────┐
28	│ 2. EVENT DESIGN │ ← Define events (names only, no properties yet)
29	└────────┬────────┘
30	▼
31	┌─────────────────┐
32	│ 3. HUMAN │ ← PM/Eng review: Are these the right events?
33	│ CHECKPOINT │
34	└────────┬────────┘
35	▼
36	┌─────────────────┐
37	│ 4. PROPERTY │ ← Define properties for approved events
38	│ DESIGN │
39	└────────┬────────┘
40	▼
41	┌─────────────────┐
42	│ 5. BUILD YAML │ ← Create tracking plan definitions
43	└────────┬────────┘
44	▼
45	┌─────────────────┐
46	│ 6. IMPLEMENT │ ← Code the feature with instrumentation
47	└─────────────────┘
48	```
49
50	## Phase 1: Requirements Gathering
51
52	Start with the questions the data must answer:
53
54	### Questions Template
55
56	```markdown
57	## Feature: [Feature Name]
58
59	### Business Questions
60	- [ ] What is the conversion rate through this feature?
61	- [ ] Where do users drop off?
62	- [ ] How long does it take users to complete the flow?
63	- [ ] What variations do users prefer?
64
65	### Success Metrics
66	- Primary: _______________
67	- Secondary: _______________
68
69	### Funnel Stages
70	1. Entry point: _______________
71	2. Key action: _______________
72	3. Completion: _______________
73
74	### Stakeholders
75	- PM: _______________
76	- Engineering: _______________
77	- Data/Analytics: _______________
78	```
79
80	## Phase 2: Event Design (Names Only)
81
82	Define events as user stories or behavioral descriptions first — no properties yet.
83
84	### Event Description Format
85
86	Use clear, behavioral language:
87
88	```markdown
89	## Events for [Feature Name]
90
91	### Event: Feature Opened
92	- When: User opens the feature for the first time in a session
93	- Why track: Measures feature discovery and initial engagement
94	- Funnel position: Entry
95
96	### Event: Configuration Started
97	- When: User begins configuring the feature
98	- Why track: Measures intent to use feature
99	- Funnel position: Middle
100
101	### Event: Configuration Completed
102	- When: User successfully completes configuration
103	- Why track: Measures successful adoption
104	- Funnel position: Completion
105
106	### Event: Configuration Failed
107	- When: User encounters an error during configuration
108	- Why track: Identifies friction points
109	- Funnel position: Error state
110	```
111
112	### Naming Convention
113
114	\| Pattern \| Example \| Use For \|
115	\|---------\|---------\|---------\|
116	\| Feature + Action (Past Tense) \| `Audience Created` \| Completed actions \|
117	\| Feature + State \| `Checkout Started` \| State transitions \|
118	\| Object + Action \| `Product Viewed` \| Standard interactions \|
119
120	## Phase 3: Human Checkpoint
121
122	Critical: Before defining properties, get alignment on events.
123
124	### Review Checklist
125
126	- [ ] Do these events answer all the business questions?
127	- [ ] Is the funnel complete (entry → middle → completion)?
128	- [ ] Are error states captured?
129	- [ ] Are there redundant events that can be consolidated?
130	- [ ] Do event names follow conventions?
131
132	### Approval Gate
133
134	```markdown
135	## Event Review Sign-Off
136
137	Feature: _______________
138	Date: _______________
139
140	Approved Events:
141	- [ ] Event 1: _______________
142	- [ ] Event 2: _______________
143	- [ ] Event 3: _______________
144
145	Rejected/Deferred:
146	- [ ] _______________
147
148	Approved by:
149	- PM: _______________
150	- Engineering: _______________
151	```
152
153	## Phase 4: Property Design
154
155	After events are approved, define properties for each.
156
157	### Property Design Process
158
159	For each event, ask:
160
161	1. What context is needed to answer the business questions?
162	2. What attributes describe this action?
163	3. What will we group/filter by in dashboards?
164
165	### Property Template
166
167	```markdown
168	## Event: Audience Created
169
170	### Required Properties
171	\| Property \| Type \| Description \| Example \|
172	\|----------\|------\|-------------\|---------\|
173	\| audience_id \| string \| Unique identifier \| "aud_123" \|
174	\| audienc

People who liked this also viewed

6 picks

Type