Rudder Performance Architecture Maintainer
Overview
Find and fix Rudder performance or architecture bottlenecks with measurements, scoped changes, and regression evidence.
When to Use
Use this skill when:
- the user asks why a page/API is slow or refetching
- large org or ZStudio-scale data exposes over-fetching or payload issues
- query keys, staleTime, invalidation, cache, or render cost may be wrong
- architecture boundaries, hot files, or duplicated data paths need cleanup
- the task asks to capture performance know-how
Do not use this skill when:
- pure visual polish
- missing-data diagnosis with no performance question
- release operations
- Desktop startup recovery
Core Pattern
context -> baseline measurement -> path trace -> smallest fix -> regression coverage -> remeasure -> know-how
Quick Reference
| Situation |
Action |
| Broad optimization |
Load checklist and recent-thread signals |
| Known slow path |
Measure before changing |
| Large-org proof |
Calibrate dataset and runtime |
| Architecture fix |
Keep product contracts stable |
Implementation
- Load relevant optimization references for non-trivial work.
- Record workload, dataset, route/API, and baseline measurement.
- Trace UI, API, service, DB, cache, and rendering path end to end.
- Choose the smallest correct fix with rollback boundary.
- Add focused regression coverage and re-measure.
- Record reusable know-how when requested.
Reference files are part of this skill contract. Before executing high-risk actions or final judgments, load references/runbook.md for the detailed legacy workflow, examples, validation cases, and command-level guidance.
Use references/, evals/ when the route needs that detail; keep the entrypoint thin.
Common Mistakes
| Mistake |
Fix |
| Optimizing without a baseline |
Measure first. |
| Tuning the UI while API is the bottleneck |
Trace end to end. |
| Using toy data for scale claims |
Use calibrated dev pressure data or label limitation. |
| Refactoring broad hot files without a slice |
Choose one measurable fix. |
Source: Undertone0809/rudder — distributed by TomeVault.
1---2name: undertone0809-rudder-rudder3description: Rudder Performance Architecture Maintainer4---56# Rudder Performance Architecture Maintainer78## Overview910Find and fix Rudder performance or architecture bottlenecks with measurements, scoped changes, and regression evidence.1112## When to Use1314Use this skill when:1516- the user asks why a page/API is slow or refetching17- large org or ZStudio-scale data exposes over-fetching or payload issues18- query keys, staleTime, invalidation, cache, or render cost may be wrong19- architecture boundaries, hot files, or duplicated data paths need cleanup20- the task asks to capture performance know-how2122Do not use this skill when:2324- pure visual polish25- missing-data diagnosis with no performance question26- release operations27- Desktop startup recovery2829## Core Pattern3031```text32context -> baseline measurement -> path trace -> smallest fix -> regression coverage -> remeasure -> know-how33```3435## Quick Reference3637| Situation | Action |38| --- | --- |39| Broad optimization | Load checklist and recent-thread signals |40| Known slow path | Measure before changing |41| Large-org proof | Calibrate dataset and runtime |42| Architecture fix | Keep product contracts stable |4344## Implementation45461. Load relevant optimization references for non-trivial work.472. Record workload, dataset, route/API, and baseline measurement.483. Trace UI, API, service, DB, cache, and rendering path end to end.494. Choose the smallest correct fix with rollback boundary.505. Add focused regression coverage and re-measure.516. Record reusable know-how when requested.5253Reference files are part of this skill contract. Before executing high-risk actions or final judgments, load `references/runbook.md` for the detailed legacy workflow, examples, validation cases, and command-level guidance.5455Use `references/`, `evals/` when the route needs that detail; keep the entrypoint thin.5657## Common Mistakes5859| Mistake | Fix |60| --- | --- |61| Optimizing without a baseline | Measure first. |62| Tuning the UI while API is the bottleneck | Trace end to end. |63| Using toy data for scale claims | Use calibrated dev pressure data or label limitation. |64| Refactoring broad hot files without a slice | Choose one measurable fix. |6566---67> Source: [Undertone0809/rudder](https://github.com/Undertone0809/rudder) — distributed by [TomeVault](https://tomevault.io).68<!-- tomevault:4.0:skill_md:2026-06-30 -->