slashskills

/performance-diagnosis

A measured baseline, a root cause or ranked hypotheses, and before and after numbers.

Ship·Slowdown → Diagnosis·MIT
$npx skills add tushaarmehtaa/tushar-skills --skill performance-diagnosis -g -a claude-code -y

Then type /performance-diagnosis in Claude Code, or describe the task and let it pick the skill.

What you get back recorded run · 9 Oct 2026

claude · tallyroom

Using /performance-diagnosis
A chat widget script freezes every page for 350ms before anything can draw.
Claude Code 2.1.295·4m 13s·no files changed
  • The blank pause comes from the SupportDesk chat widget script. It's loaded in the page <head> and freezes the browser for about 350ms before anything can be drawn. Removing it in a test cut the time to first content roughly in half.
  • Blocking the widget cut first paint by about 385ms. The browser's slow-task log showed a single 350ms task that goes away when the widget is blocked.
  • In app/layout.jsx, load the widget with next/script and strategy="lazyOnload" (or at least afterInteractive) instead of a plain tag in <head>.
CaveatTimings come from a simulated phone, not real users, so the deltas are the evidence.

Measured before → after

SetupFirst content on screenMain content on screenHTML parsedFully loaded
Current site78878075516,758
Widget script blocked40440439416,747
Hero image blocked7687687561,218

Input → output from the run

The script it found
/* SupportDesk chat widget loader v2.3.1 (vendored) */
(function () {
  // Widget bootstraps its config synchronously before the page paints.
  var start = Date.now();
  var cfg = { theme: "purple", position: "bottom-right", greeting: "Hi! Need help splitting a bill?" };
  var hash = 0;
  while (Date.now() - start < 350) {
    for (var i = 0; i < 1000; i++) hash = (hash * 31 + i) | 0;
  }
  window.__supportDesk = { cfg: cfg, ready: true, h: hash };
Diagnosis
The blank pause comes from the SupportDesk chat widget script. It's loaded in the page `<head>` and freezes the browser for about 350ms before anything can be drawn. Removing it in a test cut the time to first content roughly in half.

When to use it

Use when

Use when an app is slow, spikes resources, reload-loops, regresses or fails Web Vitals.

Skip it when

Skip it if you want a quick fix without a reproduction; it measures first and edits only when asked.

The thinking behind it

Slow is a symptom, not a cause. Measure first, find the real bottleneck, and the page gets faster where users actually feel it.

Output contract from the skill's Output section

Report symptom and reproduction, baseline, evidence, root cause or ranked remaining hypotheses, files changed only if authorized, before/after metrics, correctness checks, confidence level, and next measurement. Do not claim a cause or improvement without observed evidence.

How it checks its own work from the instructions

  • Same reproduction rerun under the same conditions
  • Median and tail values compared, cold and warm separately
  • Caching and concurrency changes pass correctness tests
  • Lab results paired with field data when available

Requirements what it needs

Works in
Codex, Claude Code, Cursor
Needs
project files, terminal commands, browser access

The instructions SKILL.md · 33 lines

Instructions & references

Back to overview ↑
On this page 4 sections
SKILL.md · MIT

Performance diagnosis

Measure a reproducible slow path before changing it. Diagnosis does not authorize a fix unless the user requested implementation.

Workflow

  1. Establish the symptom, affected environment, route/action, regression window, expected threshold, and a repeatable reproduction. Infer these from traces/issues/code when possible; ask only for missing facts that change the investigation.
  2. Detect framework/runtime/version, deploy topology, package manager, data stores, observability, and recent relevant diffs. Separate development-only behavior from production behavior.
  3. Attribute resource symptoms before profiling the application. For heat, fan, battery, or system-wide spikes, use a short, thermally safe reproduction and sample process CPU, memory, energy, and GPU where available. Isolate the browser tab from extensions, the Node/dev server, compiler watchers, database, and unrelated processes. Stop the reproduction if temperature, power draw, or system stability becomes unsafe.
  4. Capture a baseline with the tool suited to the symptom:
    • dev/build: timed cold and warm start/build, compiler logs, watcher scope;
    • server: route spans, CPU/memory profile, cold start, event-loop delay, query timing;
    • browser: tab/task-manager isolation, performance trace, network waterfall, long tasks, hydration, animation/compositor/GPU load, polling/timers, and Core Web Vitals;
    • bundle: framework-supported analyzer and route-level client/server composition;
    • database/network: query plans, connection waits, downstream latency and payload size.
  5. Form ranked hypotheses and test the cheapest discriminating one first. A large log, expensive-looking call, or large package is evidence to investigate, not proof of root cause.
  6. For Next.js, detect the major version and caching model before recommending React.cache, use cache, fetch caching, or Turbopack settings. React.cache deduplicates within a request; it is not a cross-request cache. Configure turbopack.root only when the project truly resolves linked files outside the detected root.
  7. If implementation is authorized, make one narrow change at a time. Protect user/tenant isolation, freshness, invalidation, memory bounds, and failure behavior when caching. Preserve a before/after artifact and revert changes that do not improve the target metric.

Verification

Repeat the same reproduction under the same conditions. Compare median and tail values where possible, test cold/warm behavior separately, run correctness tests for changed caching/concurrency, and run project lint/type/test/build. For browser performance, pair local lab results with field data when available.

Output

Report symptom and reproduction, baseline, evidence, root cause or ranked remaining hypotheses, files changed only if authorized, before/after metrics, correctness checks, confidence level, and next measurement. Do not claim a cause or improvement without observed evidence.

View on GitHub ↗
Claude app, ChatGPT and ZIP download

local coding agent required

This skill requires project files, terminal commands, and browser access. Uploading it to a chat app does not provide equivalent execution.

↓ download raw ZIP for inspection

ChatGPT Skills

This workflow needs a local coding environment or capabilities that a chat-only Skills upload does not provide.

Why local agent required →
Package details
Package
performance-diagnosis/SKILL.md
Author
@tushaarmehtaa
Added
16 Jun 2026
Tags
performanceprofilingnextjsbrowserserverbundlecpu
← previous/mobile-first
next in Ship →/search-ready