rudder-data-path-diagnostician-maintainer

Name: rudder-data-path-diagnostician-maintainer
Author: Undertone0809

247stars30forks

How to install rudder-data-path-diagnostician-maintainer?

undertone0809/rudder/rudder-data-path-diagnostician-maintainer

$npx -y skills add Undertone0809/rudder --skill rudder-data-path-diagnostician-maintainer

Installs into the current project.

Summary

Use when Rudder pages or product surfaces show missing, stale, sparse, empty, slow, or wrong data, including Calendar, runs, issues, dashboard counts, chat output, prod/local org data, API/UI/DB mismatches, or “这个数据从哪来”.

Files · 1

View on GitHub

SKILL.md

1	# Rudder Data Path Diagnostician Maintainer
2
3	Use this skill when the user's real problem is that a Rudder surface does not
4	show the data they expected.
5
6	The goal is to produce an evidence-backed data lineage and root cause, not to
7	guess from the screenshot. Most failures in this class are caused by one of:
8
9	- wrong runtime or organization
10	- empty source records
11	- filtering or date-window mismatch
12	- derived data that is not generated from the records the user expected
13	- API/service aggregation gap
14	- UI rendering or state merge bug
15	- stale seed/demo assumptions
16
17	This skill also has an explanation mode. When the user asks "这个数据从哪来" or
18	"现在的渲染逻辑是怎样的" and the data is no longer missing, explain the
19	lineage from UI query to API route, service aggregation, derived records, and
20	rendering states. In explanation mode, read-only source tracing may be enough;
21	do not force database inspection when code and API contracts already answer the
22	question.
23
24	## Use When
25
26	Use this skill for questions like:
27
28	- "为什么 Calendar 没数据"
29	- "这个 Dashboard 怎么是空的"
30	- "prod z studio 下这里怎么没有 run / issue / calendar"
31	- "这个 UI 的数据从哪里来"
32	- "看起来应该有数据，但页面没有显示"
33	- "这个数字和数据库/API 对不上"
34	- "是不是 seed 数据没有写进去"
35
36	This skill is useful across dev, prod-local Desktop, worktree previews, and
37	local production-style instances.
38
39	## Do Not Use When
40
41	Do not use this skill for:
42
43	- a single agent run transcript failure; use `debug-run-transcript-maintainer`
44	- creating demo or screenshot data from scratch; use `mock-data-maintainer`
45	- pure UI polish where the data is already known; use
46	`rudder-ui-polish-maintainer`
47	- CI, release, npm, Desktop packaging, or Chrome automation infrastructure
48	- destructive cleanup of organizations or databases unless the user explicitly
49	authorizes that separate operation
50
51	## Default Workflow
52
53	### 1. Confirm the symptom and target environment
54
55	Start by pinning down:
56
57	- surface: page, route, tab, card, chart, or screenshot region
58	- expected data: what the user believes should appear
59	- actual data: what is visible or returned
60	- runtime: dev, prod-local Desktop, worktree preview, or remote deployment
61	- organization: org id, URL key, display name, or selected org
62	- date window, filters, and selected project/agent when relevant
63
64	Classify the mode before deep inspection:
65
66	- `diagnosis`: expected data is missing, stale, sparse, or wrong.
67	- `explanation`: the user wants the rendering or derivation logic after the
68	visible symptom is resolved.
69
70	In explanation mode, keep the answer focused on the current code path and
71	source hierarchy. Still name any assumptions about runtime, org, or date window
72	when those affect the answer.
73
74	Verify the live target before trusting assumptions:
75
76	```bash
77	curl -sS <base-url>/api/health
78	curl -sS <base-url>/api/orgs
79	```
80
81	For prod-local or Desktop investigations, require evidence that the active
82	runtime is the expected local environment before inspecting or writing data.
83
84	### 2. Identify the UI data request
85
86	Find the component and data hook or API client that feeds the surface. Record:
87
88	- query key or effect dependency
89	- endpoint path and parameters
90	- selected org/project/agent/date filters
91	- fallback, loading, error, and empty-state behavior
92	- client-side merge or normalization logic
93
94	Do not stop at "the component renders an empty array." Trace where that array
95	comes from.
96
97	### 3. Inspect the API and service chain
98
99	Follow the endpoint into server code:
100
101	- route path and auth/org access checks
102	- request validators and default date windows
103	- service function and aggregation logic
104	- derived sources such as heartbeat runs, automation runs, activity, messenger
105	context snapshots, calendar projections, cost rows, or external sync tables
106	- response shape and filtering rules
107
108	Compare route behavior to the UI expectation. Many bugs are not missing rows;
109	they are mismatched assumptions about which source is authoritative.
110
111	### 4. Read source data safely
112
113	Use read-only API calls or SQL queries first. Verify:
114
115	- records exist for the selected organization
116	- timestamps fall inside the UI date window
117	- statuses match the service filters
118	- linked ids are present and point to the expected issue, agent, project, run,
119	automation, or conversation
120	- soft-deleted, archived, hidden, or permission-gated rows are not being
121	mistaken for visible data
122
123	Keep every query organization-scoped. Do not write, reseed, or delete data
124	while diagnosing unless the user explicitly changes the task from diagnosis to
125	repair.
126
127	### 5. Classify the root cause
128
129	Use one primary classification:
130
131	- `wrong-target`: the browser or process is pointed at the wrong instance or org
132	- `source-empty`: the source table/API has no matching records
133	- `filter-window`: data exists but the sel

People who liked this also viewed

6 picks

Type

rudder-data-path-diagnostician-maintainer

247stars30forks

View on GitHub

How to install rudder-data-path-diagnostician-maintainer?

undertone0809/rudder/rudder-data-path-diagnostician-maintainer

$npx -y skills add Undertone0809/rudder --skill rudder-data-path-diagnostician-maintainer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Rudder Data Path Diagnostician Maintainer
2
3	Use this skill when the user's real problem is that a Rudder surface does not
4	show the data they expected.
5
6	The goal is to produce an evidence-backed data lineage and root cause, not to
7	guess from the screenshot. Most failures in this class are caused by one of:
8
9	- wrong runtime or organization
10	- empty source records
11	- filtering or date-window mismatch
12	- derived data that is not generated from the records the user expected
13	- API/service aggregation gap
14	- UI rendering or state merge bug
15	- stale seed/demo assumptions
16
17	This skill also has an explanation mode. When the user asks "这个数据从哪来" or
18	"现在的渲染逻辑是怎样的" and the data is no longer missing, explain the
19	lineage from UI query to API route, service aggregation, derived records, and
20	rendering states. In explanation mode, read-only source tracing may be enough;
21	do not force database inspection when code and API contracts already answer the
22	question.
23
24	## Use When
25
26	Use this skill for questions like:
27
28	- "为什么 Calendar 没数据"
29	- "这个 Dashboard 怎么是空的"
30	- "prod z studio 下这里怎么没有 run / issue / calendar"
31	- "这个 UI 的数据从哪里来"
32	- "看起来应该有数据，但页面没有显示"
33	- "这个数字和数据库/API 对不上"
34	- "是不是 seed 数据没有写进去"
35
36	This skill is useful across dev, prod-local Desktop, worktree previews, and
37	local production-style instances.
38
39	## Do Not Use When
40
41	Do not use this skill for:
42
43	- a single agent run transcript failure; use `debug-run-transcript-maintainer`
44	- creating demo or screenshot data from scratch; use `mock-data-maintainer`
45	- pure UI polish where the data is already known; use
46	`rudder-ui-polish-maintainer`
47	- CI, release, npm, Desktop packaging, or Chrome automation infrastructure
48	- destructive cleanup of organizations or databases unless the user explicitly
49	authorizes that separate operation
50
51	## Default Workflow
52
53	### 1. Confirm the symptom and target environment
54
55	Start by pinning down:
56
57	- surface: page, route, tab, card, chart, or screenshot region
58	- expected data: what the user believes should appear
59	- actual data: what is visible or returned
60	- runtime: dev, prod-local Desktop, worktree preview, or remote deployment
61	- organization: org id, URL key, display name, or selected org
62	- date window, filters, and selected project/agent when relevant
63
64	Classify the mode before deep inspection:
65
66	- `diagnosis`: expected data is missing, stale, sparse, or wrong.
67	- `explanation`: the user wants the rendering or derivation logic after the
68	visible symptom is resolved.
69
70	In explanation mode, keep the answer focused on the current code path and
71	source hierarchy. Still name any assumptions about runtime, org, or date window
72	when those affect the answer.
73
74	Verify the live target before trusting assumptions:
75
76	```bash
77	curl -sS <base-url>/api/health
78	curl -sS <base-url>/api/orgs
79	```
80
81	For prod-local or Desktop investigations, require evidence that the active
82	runtime is the expected local environment before inspecting or writing data.
83
84	### 2. Identify the UI data request
85
86	Find the component and data hook or API client that feeds the surface. Record:
87
88	- query key or effect dependency
89	- endpoint path and parameters
90	- selected org/project/agent/date filters
91	- fallback, loading, error, and empty-state behavior
92	- client-side merge or normalization logic
93
94	Do not stop at "the component renders an empty array." Trace where that array
95	comes from.
96
97	### 3. Inspect the API and service chain
98
99	Follow the endpoint into server code:
100
101	- route path and auth/org access checks
102	- request validators and default date windows
103	- service function and aggregation logic
104	- derived sources such as heartbeat runs, automation runs, activity, messenger
105	context snapshots, calendar projections, cost rows, or external sync tables
106	- response shape and filtering rules
107
108	Compare route behavior to the UI expectation. Many bugs are not missing rows;
109	they are mismatched assumptions about which source is authoritative.
110
111	### 4. Read source data safely
112
113	Use read-only API calls or SQL queries first. Verify:
114
115	- records exist for the selected organization
116	- timestamps fall inside the UI date window
117	- statuses match the service filters
118	- linked ids are present and point to the expected issue, agent, project, run,
119	automation, or conversation
120	- soft-deleted, archived, hidden, or permission-gated rows are not being
121	mistaken for visible data
122
123	Keep every query organization-scoped. Do not write, reseed, or delete data
124	while diagnosing unless the user explicitly changes the task from diagnosis to
125	repair.
126
127	### 5. Classify the root cause
128
129	Use one primary classification:
130
131	- `wrong-target`: the browser or process is pointed at the wrong instance or org
132	- `source-empty`: the source table/API has no matching records
133	- `filter-window`: data exists but the sel

People who liked this also viewed

6 picks

Type