agentsclimarketplace

Performance improvement

Skill 05-deepak-patidar/claude-skills/performance-improvement

24 battle-tested, model-agnostic Agent Skills that turn any AI coding assistant into a disciplined senior engineer — security, deployments, databases, payments, multi-tenancy, testing, AI engineering & more. Works with Claude Code, portable to Cursor/Codex.

Install
npx -y skills add 05-deepak-patidar/claude-skills --skill performance-improvement

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Measurement-first performance work — backend latency, database queries, frontend load times, memory, cost. Use when something is slow, when optimizing, before adding caches, or when the user says "performance", "slow", "optimize", "speed up", "latency", "memory", "N+1", or "page load".

SKILL.md

4.4 KB, 940 tokens by cl100k_base, as published. Nobody here has run it

Performance Improvement

The iron law: no optimization without a measurement, and no "it's faster now" without a second measurement. Guessed bottlenecks are wrong more than half the time; optimizing a guess makes code worse and no faster.

The loop (never skip a step)

  1. Define the target. "Fast" is not a spec. Get a number: "list endpoint p95 < 300ms", "page interactive < 2s on mid-range mobile", "report generates in < 30s". Without a target you cannot stop, and unstoppable optimization destroys codebases.
  2. Measure where the time actually goes. Profile or trace the real path with realistic data volume — 10 rows in dev hides everything. One request timed end-to-end, broken into segments: network / app CPU / DB / external calls / rendering.
  3. Fix the biggest segment only. One change at a time.
  4. Re-measure the same way. Keep the change only if the number moved meaningfully. Record before/after in the commit/PR.
  5. Repeat until the target is met, then stop — the target is the permission to stop.

Where the time usually is (check in this order)

Database — the culprit ~70% of the time in CRUD apps

  • N+1 queries: the single most common backend perf bug. Detect by logging/counting queries per request (an ORM loop over rows, each lazy-loading a relation). Fix with joins/eager loading/batched IN queries. Any list endpoint doing >5 queries deserves suspicion.
  • Missing indexes: EXPLAIN ANALYZE the slow query. Seq scan on a big table in a hot path → index the filter/sort columns (composite, leading with equality columns; tenant id first in multi-tenant).
  • Fetching too much: SELECT only needed columns for lists; paginate everything (keyset for deep pages); never load all rows to count them (COUNT(*)) or to filter in app code what SQL can filter.
  • Chatty transactions: many round trips inside one request → batch into fewer statements; move multi-row inserts to bulk operations.

External calls

  • Sequential awaits that could be parallel; missing timeouts (a "slow" system is often one hung dependency); calls in loops that need batching; synchronous calls that belong in a background job (see system-design).

App code

  • Only after DB and I/O are clean: accidental O(n²) (lookup in a list inside a loop → use a set/dict), repeated parsing/serialization of the same data, loading whole files into memory to stream them out.

Frontend

  • Measure with the browser's own tools (Lighthouse/Performance tab) on throttled mobile, not your dev machine.
  • Usual suspects in order: oversized/unoptimized images, render-blocking or oversized JS bundles (analyze the bundle; lazy-load routes and heavy components), waterfalls of dependent fetches (parallelize or move to the server), missing caching headers on static assets, re-render storms (fix state placement before reaching for memo).
  • Perceived speed counts: skeletons, optimistic updates, and streaming beat a spinner even at equal latency.

Caching is the last resort, not the first

A cache is a bug you haven't had yet (staleness, invalidation, memory). Before caching: fix the query, add the index, batch the calls. Cache when the computation is irreducibly expensive and read-heavy — then follow system-design's cache rules (source of truth, invalidation, max staleness, tenant-scoped keys).

Load & capacity sanity

  • Before launch or a big campaign: one basic load test of the golden path at 2–3× expected peak (any tool — k6, locust, even a bash loop with concurrency). You're looking for the knee: where latency bends and errors start.
  • Watch connection limits: DB max_connections vs app pool size × instances is the classic silent ceiling.
  • Memory leaks announce themselves as restarts-fix-it: track RSS over hours under steady load if you suspect one.

Anti-patterns to refuse

  • Micro-optimizing readable code (loop unrolling, clever bit tricks) in an app whose time is 95% I/O.
  • Adding Redis/queues/read-replicas to fix what one index fixes.
  • "It feels faster" as evidence. Numbers or it didn't happen.
  • Benchmarking dev builds, cold caches, or localhost and drawing production conclusions.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most performance cost skills give in 940 tokens

Counted across 803 of the 1,058 authors here whose files we hold, read 2026-08-07

  • Keep skill files under 500 lines or tokensin 82 of 803, across 16 files
  • Use imperative form in instructionsin 80 of 803, across 9 files
  • Draft assertions while test runs are in progressin 75 of 803, across 9 files
  • Create two to three realistic test promptsin 74 of 803, across 9 files
  • Write skill descriptions to be pushyin 72 of 803, across 7 files
  • Save test cases to evals JSONin 72 of 803, across 6 files
  • Ask questions about edge cases and input formatsin 72 of 803, across 7 files
  • Save timing data immediately when runs completein 70 of 803, across 5 files
  • Include all trigger conditions in the skill descriptionin 69 of 803, across 3 files
  • Launch all test runs in a single turn or simultaneouslyin 69 of 803, across 3 files
  • Capture intent before writing a skillin 67 of 803, across 1 file
  • Import directly instead of barrel filesin 52 of 803, across 15 files

Said here and by no other author read

  • Establish a specific performance target before optimizing
  • Profile the real execution path with realistic data
  • Fix only the biggest time segment at a time
  • Re-measure the same metric after changing code
  • Add database indexes for slow query filters
  • Parallelize sequential independent external calls

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 327,069. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.