rudder-performance-architecture-maintainer

Name: rudder-performance-architecture-maintainer
Author: Undertone0809

247stars30forks

How to install rudder-performance-architecture-maintainer?

undertone0809/rudder/rudder-performance-architecture-maintainer

$npx -y skills add Undertone0809/rudder --skill rudder-performance-architecture-maintainer

Installs into the current project.

Summary

Use when Rudder needs performance or architecture optimization: slow pages, skeleton loops, query cache misses, refetch storms, large-org over-fetching, payload budgets, expensive API/DB paths, hot files, boundaries, measurement, or ZStudio-scale proof.

Files · 1

View on GitHub

SKILL.md

1	# Rudder Performance Architecture Maintainer
2
3	Use this skill when the user wants Rudder to become faster, more stable, or
4	cleaner at the architecture boundary. The default result should be evidence-led
5	optimization that preserves product contracts, not speculative tuning.
6
7	This skill covers two related classes of work:
8
9	- performance fixes: cache behavior, network waterfalls, repeated skeletons,
10	slow queries, refetch loops, expensive renders, build/test slowness
11	- architecture fixes: unstable boundaries, oversized modules, duplicated data
12	paths, unclear ownership, abstractions that make performance hard to reason
13	about
14
15	Read `references/optimization-checklist.md` before doing non-trivial work with
16	this skill. When the user asks for broad optimization or know-how capture, also
17	read `references/recent-thread-signals.md`.
18
19	## Use When
20
21	Use this skill for requests like:
22
23	- "为什么 dashboard 每次都骨架屏"
24	- "全局看看哪里可以做缓存加速"
25	- "这个页面/API 太慢，找一下瓶颈"
26	- "做一版系统性能优化"
27	- "数据量一大之后网页卡，给我优化前后的具体数值"
28	- "用 ZStudio 同等规模的数据在 DEV 里测一下"
29	- "这里是不是 query key / staleTime / invalidation 写错了"
30	- "架构上有什么热点文件或边界可以优化"
31	- "把这次性能优化 know how 沉淀成 skill"
32	- "分析一下最近的 thread 里有没有类似性能/架构任务"
33
34	## Do Not Use When
35
36	Do not use this skill when the primary task is:
37
38	- data exists but a page shows missing, stale, sparse, or wrong data; use
39	`rudder-data-path-diagnostician-maintainer`
40	- a large refactor where the user explicitly wants plan plus execution as the
41	main deliverable; use `architecture-refactor-driver-maintainer`
42	- pure UI polish, spacing, copy, or visual QA
43	- release, package, installer, or Desktop startup recovery
44	- a single agent transcript or runtime failure investigation
45
46	If the task overlaps, choose the skill that matches the user's visible pain. For
47	example, repeated skeleton loading after navigation belongs here; empty dashboard
48	data belongs to data-path diagnosis.
49
50	## Inputs
51
52	Capture or infer:
53
54	- affected surface, route, API, service, or subsystem
55	- user-visible symptom and expected improvement
56	- runtime and organization when live data is involved
57	- current cache, invalidation, polling, and freshness expectations
58	- constraints that must remain stable: API shape, schema, org scoping, runtime
59	contracts, UI behavior
60	- acceptable validation depth for the blast radius
61
62	## Evidence Ledger
63
64	Before proposing a fix, build a small evidence ledger. Keep it in your working
65	notes unless it is useful to show the user.
66
67	```markdown
68	\| Observation \| Evidence \| Implication \|
69	\|---\|---\|---\|
70	\| Page remounts show skeleton \| query key includes moving `to` timestamp \| cache miss, not missing cache library \|
71	\| API is called by multiple cards \| network trace or code search \| candidate for shared query/prefetch \|
72	\| Service loads broad rows then filters \| route/service/SQL inspection \| push filter down or add index/test \|
73	```
74
75	Evidence can come from code search, tests, API calls, browser/network traces,
76	React Query Devtools-style reasoning, logs, SQL `EXPLAIN`, benchmarks, or
77	profiling. Do not tune from screenshots alone.
78
79	## Scale And Runtime Calibration
80
81	When live performance, production-shaped data, or user-visible slowness is part
82	of the task, calibrate the runtime before interpreting numbers:
83
84	- call `/api/health` on the target server and record `instanceId`, `localEnv`,
85	version/build fields, and any `restartRequired` signal
86	- prove whether the browser/dev server is running current code; restart or
87	re-check health before treating browser evidence as current-branch proof
88	- use prod-local data only as a read-only sizing reference unless the user has
89	explicitly authorized writes to that environment
90	- use dev or a disposable organization for pressure proof, implementation
91	verification, and browser testing against current code
92	- if the user asks for a testable surface, seed or create a dev org at
93	comparable scale before measuring; tiny fixtures cannot prove large-org
94	behavior
95	- for transcript-heavy organizations, match payload shape as well as row counts:
96	include large transcript, transcription, log, chat, heartbeat, and activity
97	bodies when they are part of the real bottleneck
98	- if a full production clone fails because of seed tooling, memory, or data
99	shape limits, report that as a blocker and substitute a synthetic
100	scale-equivalent dev org with the limitation stated clearly
101
102	Separate evidence classes in notes and handoffs:
103
104	- `prod-read-only baseline`: current user data shape, sizing, and observed
105	bottlenecks without mutation
106	- `current-code dev proof`: disposable data on the branch under test, suitable
107	for before/after timing and browser verification
108	- `synthetic pressure proof`: generated row counts and heavy payloads

People who liked this also viewed

6 picks

Type

rudder-performance-architecture-maintainer

247stars30forks

View on GitHub

How to install rudder-performance-architecture-maintainer?

undertone0809/rudder/rudder-performance-architecture-maintainer

$npx -y skills add Undertone0809/rudder --skill rudder-performance-architecture-maintainer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Rudder Performance Architecture Maintainer
2
3	Use this skill when the user wants Rudder to become faster, more stable, or
4	cleaner at the architecture boundary. The default result should be evidence-led
5	optimization that preserves product contracts, not speculative tuning.
6
7	This skill covers two related classes of work:
8
9	- performance fixes: cache behavior, network waterfalls, repeated skeletons,
10	slow queries, refetch loops, expensive renders, build/test slowness
11	- architecture fixes: unstable boundaries, oversized modules, duplicated data
12	paths, unclear ownership, abstractions that make performance hard to reason
13	about
14
15	Read `references/optimization-checklist.md` before doing non-trivial work with
16	this skill. When the user asks for broad optimization or know-how capture, also
17	read `references/recent-thread-signals.md`.
18
19	## Use When
20
21	Use this skill for requests like:
22
23	- "为什么 dashboard 每次都骨架屏"
24	- "全局看看哪里可以做缓存加速"
25	- "这个页面/API 太慢，找一下瓶颈"
26	- "做一版系统性能优化"
27	- "数据量一大之后网页卡，给我优化前后的具体数值"
28	- "用 ZStudio 同等规模的数据在 DEV 里测一下"
29	- "这里是不是 query key / staleTime / invalidation 写错了"
30	- "架构上有什么热点文件或边界可以优化"
31	- "把这次性能优化 know how 沉淀成 skill"
32	- "分析一下最近的 thread 里有没有类似性能/架构任务"
33
34	## Do Not Use When
35
36	Do not use this skill when the primary task is:
37
38	- data exists but a page shows missing, stale, sparse, or wrong data; use
39	`rudder-data-path-diagnostician-maintainer`
40	- a large refactor where the user explicitly wants plan plus execution as the
41	main deliverable; use `architecture-refactor-driver-maintainer`
42	- pure UI polish, spacing, copy, or visual QA
43	- release, package, installer, or Desktop startup recovery
44	- a single agent transcript or runtime failure investigation
45
46	If the task overlaps, choose the skill that matches the user's visible pain. For
47	example, repeated skeleton loading after navigation belongs here; empty dashboard
48	data belongs to data-path diagnosis.
49
50	## Inputs
51
52	Capture or infer:
53
54	- affected surface, route, API, service, or subsystem
55	- user-visible symptom and expected improvement
56	- runtime and organization when live data is involved
57	- current cache, invalidation, polling, and freshness expectations
58	- constraints that must remain stable: API shape, schema, org scoping, runtime
59	contracts, UI behavior
60	- acceptable validation depth for the blast radius
61
62	## Evidence Ledger
63
64	Before proposing a fix, build a small evidence ledger. Keep it in your working
65	notes unless it is useful to show the user.
66
67	```markdown
68	\| Observation \| Evidence \| Implication \|
69	\|---\|---\|---\|
70	\| Page remounts show skeleton \| query key includes moving `to` timestamp \| cache miss, not missing cache library \|
71	\| API is called by multiple cards \| network trace or code search \| candidate for shared query/prefetch \|
72	\| Service loads broad rows then filters \| route/service/SQL inspection \| push filter down or add index/test \|
73	```
74
75	Evidence can come from code search, tests, API calls, browser/network traces,
76	React Query Devtools-style reasoning, logs, SQL `EXPLAIN`, benchmarks, or
77	profiling. Do not tune from screenshots alone.
78
79	## Scale And Runtime Calibration
80
81	When live performance, production-shaped data, or user-visible slowness is part
82	of the task, calibrate the runtime before interpreting numbers:
83
84	- call `/api/health` on the target server and record `instanceId`, `localEnv`,
85	version/build fields, and any `restartRequired` signal
86	- prove whether the browser/dev server is running current code; restart or
87	re-check health before treating browser evidence as current-branch proof
88	- use prod-local data only as a read-only sizing reference unless the user has
89	explicitly authorized writes to that environment
90	- use dev or a disposable organization for pressure proof, implementation
91	verification, and browser testing against current code
92	- if the user asks for a testable surface, seed or create a dev org at
93	comparable scale before measuring; tiny fixtures cannot prove large-org
94	behavior
95	- for transcript-heavy organizations, match payload shape as well as row counts:
96	include large transcript, transcription, log, chat, heartbeat, and activity
97	bodies when they are part of the real bottleneck
98	- if a full production clone fails because of seed tooling, memory, or data
99	shape limits, report that as a blocker and substitute a synthetic
100	scale-equivalent dev org with the limitation stated clearly
101
102	Separate evidence classes in notes and handoffs:
103
104	- `prod-read-only baseline`: current user data shape, sizing, and observed
105	bottlenecks without mutation
106	- `current-code dev proof`: disposable data on the branch under test, suitable
107	for before/after timing and browser verification
108	- `synthetic pressure proof`: generated row counts and heavy payloads

People who liked this also viewed

6 picks

Type