[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6K31RAMAXRR6098PXY3GH3E":3,"skill-same:01M6K31RAMAXRR6098PXY3GH3E":80},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":48,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M6K31RAMAXRR6098PXY3GH3E","rudder-performance-architecture-maintainer",null,"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\u002FDB paths, hot files, boundaries, measurement, or ZStudio-scale proof.","Undertone0809\u002Frudder","Undertone0809","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F72488598?v=4","01M6K2XANP3QJEF503JX2C693T","Zeeland","01M6K2XATQXEYF7N2QG8KZVEEY",297,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fagent-skills-bak\u002Fmaintainer\u002Frudder-performance-architecture-maintainer\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"architecture","rudder performance architecture maintainer","performance","db","skeleton","measurement","loops","scale","org","paths","proof","cache","pages","query","files","payload","use","api","Optimization","2026-11-10 10:12:30",false,"---\nname: rudder-performance-architecture-maintainer\ndescription: \"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\u002FDB paths, hot files, boundaries, measurement, or ZStudio-scale proof.\"\n---\n\n# Rudder Performance Architecture Maintainer\n\nUse this skill when the user wants Rudder to become faster, more stable, or\ncleaner at the architecture boundary. The default result should be evidence-led\noptimization that preserves product contracts, not speculative tuning.\n\nThis skill covers two related classes of work:\n\n- performance fixes: cache behavior, network waterfalls, repeated skeletons,\n  slow queries, refetch loops, expensive renders, build\u002Ftest slowness\n- architecture fixes: unstable boundaries, oversized modules, duplicated data\n  paths, unclear ownership, abstractions that make performance hard to reason\n  about\n\nRead `references\u002Foptimization-checklist.md` before doing non-trivial work with\nthis skill. When the user asks for broad optimization or know-how capture, also\nread `references\u002Frecent-thread-signals.md`.\n\n## Use When\n\nUse this skill for requests like:\n\n- \"为什么 dashboard 每次都骨架屏\"\n- \"全局看看哪里可以做缓存加速\"\n- \"这个页面\u002FAPI 太慢，找一下瓶颈\"\n- \"做一版系统性能优化\"\n- \"数据量一大之后网页卡，给我优化前后的具体数值\"\n- \"用 ZStudio 同等规模的数据在 DEV 里测一下\"\n- \"这里是不是 query key \u002F staleTime \u002F invalidation 写错了\"\n- \"架构上有什么热点文件或边界可以优化\"\n- \"把这次性能优化 know how 沉淀成 skill\"\n- \"分析一下最近的 thread 里有没有类似性能\u002F架构任务\"\n\n## Do Not Use When\n\nDo not use this skill when the primary task is:\n\n- data exists but a page shows missing, stale, sparse, or wrong data; use\n  `rudder-data-path-diagnostician-maintainer`\n- a large refactor where the user explicitly wants plan plus execution as the\n  main deliverable; use `architecture-refactor-driver-maintainer`\n- pure UI polish, spacing, copy, or visual QA\n- release, package, installer, or Desktop startup recovery\n- a single agent transcript or runtime failure investigation\n\nIf the task overlaps, choose the skill that matches the user's visible pain. For\nexample, repeated skeleton loading after navigation belongs here; empty dashboard\ndata belongs to data-path diagnosis.\n\n## Inputs\n\nCapture or infer:\n\n- affected surface, route, API, service, or subsystem\n- user-visible symptom and expected improvement\n- runtime and organization when live data is involved\n- current cache, invalidation, polling, and freshness expectations\n- constraints that must remain stable: API shape, schema, org scoping, runtime\n  contracts, UI behavior\n- acceptable validation depth for the blast radius\n\n## Evidence Ledger\n\nBefore proposing a fix, build a small evidence ledger. Keep it in your working\nnotes unless it is useful to show the user.\n\n```markdown\n| Observation | Evidence | Implication |\n|---|---|---|\n| Page remounts show skeleton | query key includes moving `to` timestamp | cache miss, not missing cache library |\n| API is called by multiple cards | network trace or code search | candidate for shared query\u002Fprefetch |\n| Service loads broad rows then filters | route\u002Fservice\u002FSQL inspection | push filter down or add index\u002Ftest |\n```\n\nEvidence can come from code search, tests, API calls, browser\u002Fnetwork traces,\nReact Query Devtools-style reasoning, logs, SQL `EXPLAIN`, benchmarks, or\nprofiling. Do not tune from screenshots alone.\n\n## Scale And Runtime Calibration\n\nWhen live performance, production-shaped data, or user-visible slowness is part\nof the task, calibrate the runtime before interpreting numbers:\n\n- call `\u002Fapi\u002Fhealth` on the target server and record `instanceId`, `localEnv`,\n  version\u002Fbuild fields, and any `restartRequired` signal\n- prove whether the browser\u002Fdev server is running current code; restart or\n  re-check health before treating browser evidence as current-branch proof\n- use prod-local data only as a read-only sizing reference unless the user has\n  explicitly authorized writes to that environment\n- use dev or a disposable organization for pressure proof, implementation\n  verification, and browser testing against current code\n- if the user asks for a testable surface, seed or create a dev org at\n  comparable scale before measuring; tiny fixtures cannot prove large-org\n  behavior\n- for transcript-heavy organizations, match payload shape as well as row counts:\n  include large transcript, transcription, log, chat, heartbeat, and activity\n  bodies when they are part of the real bottleneck\n- if a full production clone fails because of seed tooling, memory, or data\n  shape limits, report that as a blocker and substitute a synthetic\n  scale-equivalent dev org with the limitation stated clearly\n\nSeparate evidence classes in notes and handoffs:\n\n- `prod-read-only baseline`: current user data shape, sizing, and observed\n  bottlenecks without mutation\n- `current-code dev proof`: disposable data on the branch under test, suitable\n  for before\u002Fafter timing and browser verification\n- `synthetic pressure proof`: generated row counts and heavy payloads that match\n  the stress shape but are not a full clone\n\n## Workflow\n\n### 1. Load Local Context\n\nRead the minimum Rudder context needed for the surface:\n\n- `AGENTS.md`\n- `doc\u002Fproduct\u002FGOAL.md`, `doc\u002Fproduct\u002FPRODUCT.md`, and `doc\u002Fproduct\u002FREADME.md`\n  when the work changes behavior or architecture\n- relevant UI page\u002Fhooks\u002FAPI clients, server routes\u002Fservices, shared contracts,\n  DB schema, and nearby tests\n\nUse `rg` first for call sites, query keys, endpoints, invalidation keys, and\nhot modules.\n\n### 2. Mine Recent Threads When The Task Is Broad\n\nWhen the user asks for global optimization, reusable know-how, or \"recent\nthread\" analysis, inspect recent Codex threads before editing code. Look for:\n\n- prior performance scans and daily health checks\n- repeated slow surfaces, large payloads, or unbounded list symptoms\n- architecture decisions that moved work across UI\u002FAPI\u002Fservice boundaries\n- reviewer-discovered blockers, especially privacy, transactionality, and\n  org-scoping issues\n- validation gaps caused by dev-server restarts, embedded Postgres bootstrap, or\n  dirty shared worktrees\n\nUse the thread evidence as hypotheses, not truth. Re-check the current code and\nruntime before implementing. Store durable patterns in\n`references\u002Frecent-thread-signals.md` or `references\u002Foptimization-checklist.md`.\n\n### 3. Classify The Optimization\n\nPick the dominant class:\n\n- `cache-key-instability`: keys include moving timestamps, object identity, or\n  non-canonical filters\n- `freshness-policy-gap`: stale time, refetch, polling, or invalidation does not\n  match product freshness needs\n- `network-waterfall`: serial requests could be shared, prefetched, batched, or\n  moved server-side\n- `over-fetch`: UI\u002FAPI requests more data than the surface needs\n- `payload-overweight`: item count is bounded but each row carries large\n  transcript, log, activity, or nested hydration bodies\n- `server-hot-path`: service aggregation, DB query, filesystem scan, or external\n  process work is too expensive\n- `render-hot-path`: React render, memoization, virtualization, or derived state\n  work is too expensive\n- `boundary-erosion`: architecture makes data ownership, caching, or performance\n  contracts unclear\n- `validation-slowness`: build\u002Ftest\u002Fdev loop is slow because of avoidable setup,\n  scope, or fixture cost\n- `frontend-race`: a UI workflow depends on multiple ordered requests where the\n  server should own atomicity\n\nName the first broken boundary. Downstream symptoms matter, but the first broken\nboundary is where fixes usually belong.\n\n### 4. Trace The Path End To End\n\nFor UI performance, trace:\n\n```text\nsurface -> hook\u002Fquery key -> API client -> route -> service -> DB\u002Fruntime source\n```\n\nFor server\u002Fruntime performance, trace:\n\n```text\nentrypoint -> facade\u002Fservice -> query\u002Fprocess\u002Ffilesystem -> response contract\n```\n\nRecord:\n\n- query key and parameter canonicalization\n- `staleTime`, `gcTime`, placeholder data, polling, focus\u002Freconnect behavior\n- invalidation and mutation side effects\n- endpoint path, request validators, and org scoping\n- response shape and client-side filtering\u002Faggregation\n- latency, response bytes, item counts, and whether the response includes heavy\n  transcript\u002Flog\u002Factivity bodies\n- expensive loops, broad scans, N+1 calls, and repeated derived computation\n\n### 5. Choose The Smallest Correct Fix\n\nPrefer behavior-preserving changes that make the real contract explicit:\n\n- stabilize query keys before increasing `staleTime`\n- canonicalize date ranges, filters, and sort options at the boundary\n- add explicit `limit`, page, cursor, or preview contracts to broad navigation\n  list calls before optimizing rendering around unbounded data\n- use `placeholderData`, prefetch, or shared queries only when stale display is\n  acceptable and errors remain visible\n- push filters to API\u002FDB when the server owns the data contract\n- batch or share requests when multiple components need the same data\n- move multi-step UI writes into a narrow transactional API when partial success\n  creates broken product state\n- introduce a facade when multiple consumers duplicate data-path or caching\n  semantics\n- add indexes only with evidence and a migration path\n- split hot files by responsibility when that reduces real coupling or clarifies\n  performance ownership\n\nAvoid adding cache as a blanket cover for slow or incorrect code. Cache should\nencode a freshness contract, not hide broken invalidation.\n\nWhen replacing broad list responses with bounded previews, state the semantic\ntradeoff. A preview endpoint can make navigation fast, but it is not equivalent\nto a full aggregate unless the server computes the aggregate separately. If\noffset pagination remains, name the residual skip\u002Fduplicate risk under\nconcurrent inserts and prefer cursor semantics for high-churn lists when scope\nallows.\n\n### 6. Add Regression Coverage\n\nMatch tests to the failure mode:\n\n- cache-key stability: unit-test canonical range\u002Ffilter helpers\n- React Query behavior: component or hook tests for stable keys,\n  `placeholderData`, and invalidation behavior\n- API\u002Fservice hot path: route\u002Fservice tests for filtering, org scoping, and\n  response shape\n- DB query changes: integration tests around date\u002Fstatus\u002Forg boundaries\n- user-visible workflow: E2E test when the repo rules require it\n- multi-step writes: service\u002Froute tests for rollback and UI tests for the\n  single product action\n\nInclude at least one edge case when the optimization depends on dates, org\nboundaries, permissions, async runtime state, or large data volume.\n\n### 7. Validate And Commit\n\nRun the narrow validation first, then the repo-appropriate baseline:\n\n```bash\npnpm lint\npnpm -r typecheck\npnpm test:run\npnpm build\n```\n\nFor visible UI changes, verify in a browser or desktop shell and include final\nscreenshots when useful. If a baseline command fails for unrelated reasons,\nreport the failing suite and keep the optimization commit scoped.\n\nPer repo rules, commit and push completed skill, performance, or architecture\nwork. Stage only files for the current task when the worktree has unrelated\nchanges.\n\n### 8. Record Know How\n\nWhen a performance or architecture investigation produces a durable rule, add it\nto `references\u002Foptimization-checklist.md` or a more specific future reference.\nDo not record one-off local paths, private data, or transient timings as general\nrules.\n\n## Decision Rules\n\n- Measure or trace first; optimize second.\n- Treat repeated skeletons as a cache-key\u002Ffreshness problem until proven\n  otherwise.\n- A changing `now`, `Date`, random id, object literal, or unsorted filter inside\n  a query key is a cache miss factory.\n- Do not persist org-scoped or sensitive data outside the intended cache\n  boundary.\n- Keep API, DB, shared types, and UI contracts synchronized.\n- Preserve organization scoping on every server-side optimization.\n- Prefer one stable abstraction over duplicated ad hoc fixes across pages.\n- Do not change product semantics during a performance refactor unless the user\n  asked for that change and tests cover it.\n- Treat payload size as a first-class metric. JSON transfer, parse, hydration,\n  and render pressure can dominate even when SQL timing looks acceptable.\n- Default navigation\u002Flist calls should have an explicit bounded contract:\n  `limit`, cursor\u002Fpage, field projection, or a documented server aggregate.\n- Do not claim current-code proof from a stale dev\u002Fprod server. Verify health,\n  branch\u002Fbuild freshness, and restart state before using browser numbers.\n- Prefer synthetic scale-equivalent dev proof over unsafe prod mutation. Be\n  explicit when the proof is not a full production clone.\n\n## Output Shape\n\nFor diagnosis:\n\n```markdown\nRoot cause: \u003Cclassification and concrete broken boundary>\n\nEvidence:\n- ...\n\nOptimization:\n- ...\n\nValidation:\n- ...\n\nFollow-up opportunities:\n- ...\n```\n\nFor a quantified optimization report:\n\n```markdown\nRuntime calibration:\n- prod-read-only baseline: \u003Cserver\u002Fversion\u002Forg shape or not used>\n- current-code dev proof: \u003Cserver\u002Fversion\u002Forg shape or not used>\n\nMeasurements:\n| Surface\u002FAPI | Env | Before latency | After latency | Delta | Before bytes | After bytes | Delta | Items before\u002Fafter |\n|---|---:|---:|---:|---:|---:|---:|---:|---:|\n| ... | ... | ... | ... | ... | ... | ... | ... | ... |\n\nInterpretation:\n- ...\n\nResidual risk:\n- ...\n```\n\nFor implementation handoff:\n\n```markdown\nChanged:\n- ...\n\nWhy it is faster\u002Fcleaner:\n- ...\n\nValidation:\n- ...\n\nResidual risk:\n- ...\n```\n\n## Safety\n\n- Keep diagnosis read-only unless the user asked for implementation.\n- Never run destructive cleanup or unscoped SQL as part of performance work.\n- Do not broaden cache lifetime for sensitive, permissioned, or org-scoped data\n  without proving the key includes the correct scope.\n- Do not remove loading, error, or empty states just to hide latency.\n- Do not stage or revert unrelated user changes.\n\n## Validation Cases\n\nSee `references\u002Feval-cases.md` for trigger tests and expected behavior.\n","# Rudder Performance Architecture Maintainer\n\nUse this skill when the user wants Rudder to become faster, more stable, or\ncleaner at the architecture boundary. The default result should be evidence-led\noptimization that preserves product contracts, not speculative tuning.\n\nThis skill covers two related classes of work:\n\n- performance fixes: cache behavior, network waterfalls, repeated skeletons,\n  slow queries, refetch loops, expensive renders, build\u002Ftest slowness\n- architecture fixes: unstable boundaries, oversized modules, duplicated data\n  paths, unclear ownership, abstractions that make performance hard to reason\n  about\n\nRead `references\u002Foptimization-checklist.md` before doing non-trivial work with\nthis skill. When the user asks for broad optimization or know-how capture, also\nread `references\u002Frecent-thread-signals.md`.\n\n## Use When\n\nUse this skill for requests like:\n\n- \"为什么 dashboard 每次都骨架屏\"\n- \"全局看看哪里可以做缓存加速\"\n- \"这个页面\u002FAPI 太慢，找一下瓶颈\"\n- \"做一版系统性能优化\"\n- \"数据量一大之后网页卡，给我优化前后的具体数值\"\n- \"用 ZStudio 同等规模的数据在 DEV 里测一下\"\n- \"这里是不是 query key \u002F staleTime \u002F invalidation 写错了\"\n- \"架构上有什么热点文件或边界可以优化\"\n- \"把这次性能优化 know how 沉淀成 skill\"\n- \"分析一下最近的 thread 里有没有类似性能\u002F架构任务\"\n\n## Do Not Use When\n\nDo not use this skill when the primary task is:\n\n- data exists but a page shows missing, stale, sparse, or wrong data; use\n  `rudder-data-path-diagnostician-maintainer`\n- a large refactor where the user explicitly wants plan plus execution as the\n  main deliverable; use `architecture-refactor-driver-maintainer`\n- pure UI polish, spacing, copy, or visual QA\n- release, package, installer, or Desktop startup recovery\n- a single agent transcript or runtime failure investigation\n\nIf the task overlaps, choose the skill that matches the user's visible pain. For\nexample, repeated skeleton loading after navigation belongs here; empty dashboard\ndata belongs to data-path diagnosis.\n\n## Inputs\n\nCapture or infer:\n\n- affected surface, route, API, service, or subsystem\n- user-visible symptom and expected improvement\n- runtime and organization when live data is involved\n- current cache, invalidation, polling, and freshness expectations\n- constraints that must remain stable: API shape, schema, org scoping, runtime\n  contracts, UI behavior\n- acceptable validation depth for the blast radius\n\n## Evidence Ledger\n\nBefore proposing a fix, build a small evidence ledger. Keep it in your working\nnotes unless it is useful to show the user.\n\n```markdown\n| Observation | Evidence | Implication |\n|---|---|---|\n| Page remounts show skeleton | query key includes moving `to` timestamp | cache miss, not missing cache library |\n| API is called by multiple cards | network trace or code search | candidate for shared query\u002Fprefetch |\n| Service loads broad rows then filters | route\u002Fservice\u002FSQL inspection | push filter down or add index\u002Ftest |\n```\n\nEvidence can come from code search, tests, API calls, browser\u002Fnetwork traces,\nReact Query Devtools-style reasoning, logs, SQL `EXPLAIN`, benchmarks, or\nprofiling. Do not tune from screenshots alone.\n\n## Scale And Runtime Calibration\n\nWhen live performance, production-shaped data, or user-visible slowness is part\nof the task, calibrate the runtime before interpreting numbers:\n\n- call `\u002Fapi\u002Fhealth` on the target server and record `instanceId`, `localEnv`,\n  version\u002Fbuild fields, and any `restartRequired` signal\n- prove whether the browser\u002Fdev server is running current code; restart or\n  re-check health before treating browser evidence as current-branch proof\n- use prod-local data only as a read-only sizing reference unless the user has\n  explicitly authorized writes to that environment\n- use dev or a disposable organization for pressure proof, implementation\n  verification, and browser testing against current code\n- if the user asks for a testable surface, seed or create a dev org at\n  comparable scale before measuring; tiny fixtures cannot prove large-org\n  behavior\n- for transcript-heavy organizations, match payload shape as well as row counts:\n  include large transcript, transcription, log, chat, heartbeat, and activity\n  bodies when they are part of the real bottleneck\n- if a full production clone fails because of seed tooling, memory, or data\n  shape limits, report that as a blocker and substitute a synthetic\n  scale-equivalent dev org with the limitation stated clearly\n\nSeparate evidence classes in notes and handoffs:\n\n- `prod-read-only baseline`: current user data shape, sizing, and observed\n  bottlenecks without mutation\n- `current-code dev proof`: disposable data on the branch under test, suitable\n  for before\u002Fafter timing and browser verification\n- `synthetic pressure proof`: generated row counts and heavy payloads that match\n  the stress shape but are not a full clone\n\n## Workflow\n\n### 1. Load Local Context\n\nRead the minimum Rudder context needed for the surface:\n\n- `AGENTS.md`\n- `doc\u002Fproduct\u002FGOAL.md`, `doc\u002Fproduct\u002FPRODUCT.md`, and `doc\u002Fproduct\u002FREADME.md`\n  when the work changes behavior or architecture\n- relevant UI page\u002Fhooks\u002FAPI clients, server routes\u002Fservices, shared contracts,\n  DB schema, and nearby tests\n\nUse `rg` first for call sites, query keys, endpoints, invalidation keys, and\nhot modules.\n\n### 2. Mine Recent Threads When The Task Is Broad\n\nWhen the user asks for global optimization, reusable know-how, or \"recent\nthread\" analysis, inspect recent Codex threads before editing code. Look for:\n\n- prior performance scans and daily health checks\n- repeated slow surfaces, large payloads, or unbounded list symptoms\n- architecture decisions that moved work across UI\u002FAPI\u002Fservice boundaries\n- reviewer-discovered blockers, especially privacy, transactionality, and\n  org-scoping issues\n- validation gaps caused by dev-server restarts, embedded Postgres bootstrap, or\n  dirty shared worktrees\n\nUse the thread evidence as hypotheses, not truth. Re-check the current code and\nruntime before implementing. Store durable patterns in\n`references\u002Frecent-thread-signals.md` or `references\u002Foptimization-checklist.md`.\n\n### 3. Classify The Optimization\n\nPick the dominant class:\n\n- `cache-key-instability`: keys include moving timestamps, object identity, or\n  non-canonical filters\n- `freshness-policy-gap`: stale time, refetch, polling, or invalidation does not\n  match product freshness needs\n- `network-waterfall`: serial requests could be shared, prefetched, batched, or\n  moved server-side\n- `over-fetch`: UI\u002FAPI requests more data than the surface needs\n- `payload-overweight`: item count is bounded but each row carries large\n  transcript, log, activity, or nested hydration bodies\n- `server-hot-path`: service aggregation, DB query, filesystem scan, or external\n  process work is too expensive\n- `render-hot-path`: React render, memoization, virtualization, or derived state\n  work is too expensive\n- `boundary-erosion`: architecture makes data ownership, caching, or performance\n  contracts unclear\n- `validation-slowness`: build\u002Ftest\u002Fdev loop is slow because of avoidable setup,\n  scope, or fixture cost\n- `frontend-race`: a UI workflow depends on multiple ordered requests where the\n  server should own atomicity\n\nName the first broken boundary. Downstream symptoms matter, but the first broken\nboundary is where fixes usually belong.\n\n### 4. Trace The Path End To End\n\nFor UI performance, trace:\n\n```text\nsurface -> hook\u002Fquery key -> API client -> route -> service -> DB\u002Fruntime source\n```\n\nFor server\u002Fruntime performance, trace:\n\n```text\nentrypoint -> facade\u002Fservice -> query\u002Fprocess\u002Ffilesystem -> response contract\n```\n\nRecord:\n\n- query key and parameter canonicalization\n- `staleTime`, `gcTime`, placeholder data, polling, focus\u002Freconnect behavior\n- invalidation and mutation side effects\n- endpoint path, request validators, and org scoping\n- response shape and client-side filtering\u002Faggregation\n- latency, response bytes, item counts, and whether the response includes heavy\n  transcript\u002Flog\u002Factivity bodies\n- expensive loops, broad scans, N+1 calls, and repeated derived computation\n\n### 5. Choose The Smallest Correct Fix\n\nPrefer behavior-preserving changes that make the real contract explicit:\n\n- stabilize query keys before increasing `staleTime`\n- canonicalize date ranges, filters, and sort options at the boundary\n- add explicit `limit`, page, cursor, or preview contracts to broad navigation\n  list calls before optimizing rendering around unbounded data\n- use `placeholderData`, prefetch, or shared queries only when stale display is\n  acceptable and errors remain visible\n- push filters to API\u002FDB when the server owns the data contract\n- batch or share requests when multiple components need the same data\n- move multi-step UI writes into a narrow transactional API when partial success\n  creates broken product state\n- introduce a facade when multiple consumers duplicate data-path or caching\n  semantics\n- add indexes only with evidence and a migration path\n- split hot files by responsibility when that reduces real coupling or clarifies\n  performance ownership\n\nAvoid adding cache as a blanket cover for slow or incorrect code. Cache should\nencode a freshness contract, not hide broken invalidation.\n\nWhen replacing broad list responses with bounded previews, state the semantic\ntradeoff. A preview endpoint can make navigation fast, but it is not equivalent\nto a full aggregate unless the server computes the aggregate separately. If\noffset pagination remains, name the residual skip\u002Fduplicate risk under\nconcurrent inserts and prefer cursor semantics for high-churn lists when scope\nallows.\n\n### 6. Add Regression Coverage\n\nMatch tests to the failure mode:\n\n- cache-key stability: unit-test canonical range\u002Ffilter helpers\n- React Query behavior: component or hook tests for stable keys,\n  `placeholderData`, and invalidation behavior\n- API\u002Fservice hot path: route\u002Fservice tests for filtering, org scoping, and\n  response shape\n- DB query changes: integration tests around date\u002Fstatus\u002Forg boundaries\n- user-visible workflow: E2E test when the repo rules require it\n- multi-step writes: service\u002Froute tests for rollback and UI tests for the\n  single product action\n\nInclude at least one edge case when the optimization depends on dates, org\nboundaries, permissions, async runtime state, or large data volume.\n\n### 7. Validate And Commit\n\nRun the narrow validation first, then the repo-appropriate baseline:\n\n```bash\npnpm lint\npnpm -r typecheck\npnpm test:run\npnpm build\n```\n\nFor visible UI changes, verify in a browser or desktop shell and include final\nscreenshots when useful. If a baseline command fails for unrelated reasons,\nreport the failing suite and keep the optimization commit scoped.\n\nPer repo rules, commit and push completed skill, performance, or architecture\nwork. Stage only files for the current task when the worktree has unrelated\nchanges.\n\n### 8. Record Know How\n\nWhen a performance or architecture investigation produces a durable rule, add it\nto `references\u002Foptimization-checklist.md` or a more specific future reference.\nDo not record one-off local paths, private data, or transient timings as general\nrules.\n\n## Decision Rules\n\n- Measure or trace first; optimize second.\n- Treat repeated skeletons as a cache-key\u002Ffreshness problem until proven\n  otherwise.\n- A changing `now`, `Date`, random id, object literal, or unsorted filter inside\n  a query key is a cache miss factory.\n- Do not persist org-scoped or sensitive data outside the intended cache\n  boundary.\n- Keep API, DB, shared types, and UI contracts synchronized.\n- Preserve organization scoping on every server-side optimization.\n- Prefer one stable abstraction over duplicated ad hoc fixes across pages.\n- Do not change product semantics during a performance refactor unless the user\n  asked for that change and tests cover it.\n- Treat payload size as a first-class metric. JSON transfer, parse, hydration,\n  and render pressure can dominate even when SQL timing looks acceptable.\n- Default navigation\u002Flist calls should have an explicit bounded contract:\n  `limit`, cursor\u002Fpage, field projection, or a documented server aggregate.\n- Do not claim current-code proof from a stale dev\u002Fprod server. Verify health,\n  branch\u002Fbuild freshness, and restart state before using browser numbers.\n- Prefer synthetic scale-equivalent dev proof over unsafe prod mutation. Be\n  explicit when the proof is not a full production clone.\n\n## Output Shape\n\nFor diagnosis:\n\n```markdown\nRoot cause: \u003Cclassification and concrete broken boundary>\n\nEvidence:\n- ...\n\nOptimization:\n- ...\n\nValidation:\n- ...\n\nFollow-up opportunities:\n- ...\n```\n\nFor a quantified optimization report:\n\n```markdown\nRuntime calibration:\n- prod-read-only baseline: \u003Cserver\u002Fversion\u002Forg shape or not used>\n- current-code dev proof: \u003Cserver\u002Fversion\u002Forg shape or not used>\n\nMeasurements:\n| Surface\u002FAPI | Env | Before latency | After latency | Delta | Before bytes | After bytes | Delta | Items before\u002Fafter |\n|---|---:|---:|---:|---:|---:|---:|---:|---:|\n| ... | ... | ... | ... | ... | ... | ... | ... | ... |\n\nInterpretation:\n- ...\n\nResidual risk:\n- ...\n```\n\nFor implementation handoff:\n\n```markdown\nChanged:\n- ...\n\nWhy it is faster\u002Fcleaner:\n- ...\n\nValidation:\n- ...\n\nResidual risk:\n- ...\n```\n\n## Safety\n\n- Keep diagnosis read-only unless the user asked for implementation.\n- Never run destructive cleanup or unscoped SQL as part of performance work.\n- Do not broaden cache lifetime for sensitive, permissioned, or org-scoped data\n  without proving the key includes the correct scope.\n- Do not remove loading, error, or empty states just to hide latency.\n- Do not stage or revert unrelated user changes.\n\n## Validation Cases\n\nSee `references\u002Feval-cases.md` for trigger tests and expected behavior.\n",{"name":5,"description":7},"main","26d5d68bcbc55caeac1dc6a266d973e8c3831f1c","agent-skills-bak\u002Fmaintainer\u002Frudder-performance-architecture-maintainer",31,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder","https:\u002F\u002Frudderhq.dev","https:\u002F\u002Fgithub.com\u002FUndertone0809","Creator of Rudder, Spark Lab. I design SDKs, infra and software for human and the NEW WORLD.","2026-11-08 00:09:15",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add Undertone0809\u002Frudder --skill rudder-performance-architecture-maintainer",{"tool":58,"command":59},"bunx","bunx skills add Undertone0809\u002Frudder --skill rudder-performance-architecture-maintainer",{"tool":61,"command":62},"pnpm","pnpm dlx skills add Undertone0809\u002Frudder --skill rudder-performance-architecture-maintainer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fagent-skills-bak\u002Fmaintainer\u002Frudder-performance-architecture-maintainer\u002FSKILL.md",true,[66,72,76],{"path":67,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":70,"sourceHtmlUrl":71},"references\u002Foptimization-checklist.md","REFERENCE","参考文档",5094,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fagent-skills-bak\u002Fmaintainer\u002Frudder-performance-architecture-maintainer\u002Freferences\u002Foptimization-checklist.md",{"path":73,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":74,"sourceHtmlUrl":75},"references\u002Frecent-thread-signals.md",5938,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fagent-skills-bak\u002Fmaintainer\u002Frudder-performance-architecture-maintainer\u002Freferences\u002Frecent-thread-signals.md",{"path":77,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Frunbook.md",14114,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fagent-skills-bak\u002Fmaintainer\u002Frudder-performance-architecture-maintainer\u002Freferences\u002Frunbook.md",[81,94,107,133,162,187],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":38},"01M6K33ZG45BN249F4DZRCCSJN","Source Synthesis","Synthesize evidence into a concise conclusion.","https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Ftests\u002Fe2e\u002Ffixtures\u002Fcodex-plugin-research\u002Fskills\u002Fsynthesis\u002FSKILL.md",[],[88,89,90,91,92,93],"Synthesis","source","source synthesis","concise","synthesize","evidence",{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":105,"publishedAt":38},"01M6K33XMZXRM31H2SG618C37F","Evidence Research","Gather and cite evidence before reaching a conclusion.","https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Ftests\u002Fe2e\u002Ffixtures\u002Fcodex-plugin-research\u002Fskills\u002Fevidence\u002FSKILL.md",[100],{"categoryNo":101,"categoryName":102,"taxonomyType":103,"taxonomyTypeDesc":104},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",[106,93,96],"research",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":114,"publishedAt":38},"01M6K33RHAPNGPCM2FGPWTZQ8G","deep-research","Conducts enterprise-grade research with multi-source synthesis, citation tracking, and verification. Produces citation-backed reports through a structured pipeline with source credibility scoring, and grounds abstract findings in concrete examples, cases, counterexamples, or mini-scenarios when helpful. Triggers on \"deep research\", \"comprehensive analysis\", \"research report\", \"compare X vs Y\", \"analyze trends\", or \"state of the art\". Not for simple lookups, debugging, or questions answerable with 1-2 searches.","https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fcommunity-skills\u002Fdeep-research\u002FSKILL.md",[113],{"categoryNo":101,"categoryName":102,"taxonomyType":103,"taxonomyTypeDesc":104},[115,116,106,117,118,119,90,120,121,122,123,124,125,126,127,128,129,130,131,132],"deep research","deep","state","debugging","triggers","for","with","multi","compare","verification","scoring","Art","reports","analyze","analysis","pipeline","Enterprise","examples",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":142,"publishedAt":38},"01M6K33JPMYXHY9E4WR0K9EK0V","visualize","Create safe inline visual explanations in Rudder Chat. Use when asked for a chart, plot, diagram, timeline, comparison, static map, simulator, scenario view, or compact visual that materially improves understanding. Prefer Mermaid for static node-and-edge structures; use Rudder's runtime-neutral HTML\u002FSVG\u002FCSS message envelope for custom geometry. Rudder visuals are declarative and scriptless: convert simulator requests to static scenarios or disclosure-based comparisons and never rely on JavaScript, network access, or external assets.","https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fvisualize\u002FSKILL.md",[139],{"categoryNo":140,"categoryName":141,"taxonomyType":103,"taxonomyTypeDesc":104},"01JBSEEDCAT000000000000009","前端开发",[135,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161],"static","inline","chart","scenario","access","geometry","map","message","compact","back","never","node","mermaid","network","create","diagram","safe","css","markdown",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":171,"publishedAt":38},"01M6K339S5PWH9RTZZA71CPD32","skill-creator","Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.","https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fskill-creator\u002FSKILL.md",[168],{"categoryNo":169,"categoryName":170,"taxonomyType":103,"taxonomyTypeDesc":104},"01JBSEEDCAT000000000000023","Skill与智能体开发",[172,173,174,21,175,176,177,178,120,179,180,181,182,35,183,184,129,185,186,157],"skill creator","creator","run evals","variance analysis","existing skill","Existing","accuracy","From Scratch","users","optimize","evals","edit","improve","benchmark","run",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":193,"publishedAt":38},"01M6K333T855082YFXZ4FW0SE7","rudder-docs","Use when the user asks how Rudder works; needs current Rudder docs, exact behavior, commands, contracts, APIs, or source evidence; asks to create, hire, or configure Rudder agents; or asks to scaffold, develop, or verify Rudder plugins. For explicit creation requests, verify the current interface before acting within existing authorization. Do not use for greetings, ordinary work merely running inside Rudder, routine actions already clear from the active context and typed tools, non-Rudder plugin work, or general coding and research tasks that do not ask about Rudder.","https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Frudder-docs\u002FSKILL.md",[],[194,195,196,89,197,198,199,200,201,202,203,204,205,206,207,208,209,210,157,211],"rudder docs","docs","context","interface","hire","creation","commands","active","do","contracts","ask","work","coding","configure","how","Tools","actions","tasks"]