swe:performance-hunt git:20260404.775ef0aA

Immutable. This exact content never changes and is served at /api/v1/blob/dc6c8dba28849793.

---
name: "swe:performance-hunt"
description: >-
  Hunts for concrete performance bottlenecks in a scoped repository surface
  using profiler output, benchmarks, query plans, traces, bundle analysis, or
  repo evidence, then returns the smallest high-value follow-up experiments or
  fixes. Use when a user says `find performance bottlenecks`, `why is this
  slow`, `profile this flow`, `hunt hot paths`, or asks for a recurring
  performance review. Do NOT use for live incident response, generic
  observability audits, speculative micro-optimization, or broad architecture
  rewrites with no bottleneck evidence.
compatibility: >-
  Requires a local repository checkout and works best with benchmark harnesses,
  profiler output, flamegraphs, query plans, frontend bundle reports, load-test
  results, or runtime metrics. If runtime evidence is missing, stay grounded in
  repo-visible signals, label inferences clearly, and propose the smallest
  measurement step needed to remove uncertainty.
metadata:
  short-description: Find real performance bottlenecks and next fixes
---

# SWE Performance Hunt

## What This Skill Does

Use this skill to identify performance bottlenecks conservatively and turn them
into a small, reviewable backlog.

The goal is to separate:

- measured bottlenecks
- high-confidence hotspots supported by repo evidence
- weak suspicions that do not yet justify optimization work

The output should be a ranked set of bottlenecks plus the smallest next
experiment or fix for each item that clears the evidence bar.

## When To Use

Use this skill when the user wants to:

- find performance bottlenecks in a service, job, page, query path, or repo
- understand why a specific flow is slow
- audit recent performance regressions with concrete evidence
- rank hot paths before starting optimization work
- run a recurring performance review over time

## Do Not Use

Do not use this skill for:

- live incident response or active outage triage
- generic observability coverage audits
- broad cleanup or refactor planning with no performance target
- speculative micro-optimization with no measured user or system impact
- architecture rewrites that are not justified by bottleneck evidence

## Inputs To Confirm

Confirm or infer:

- repository, service, or package scope
- target flow, workload, or endpoint
- primary metric of interest, such as latency, throughput, memory, startup, or
  bundle size
- available evidence sources such as profiles, traces, benchmarks, or query
  plans
- whether the user wants a report-only pass or a small optimization backlog
- any guardrails around risky changes or expensive tests

If the request is too broad, narrow it to one flow and one metric before doing
deep analysis.

## Evidence Sources

Strong evidence includes:

- profiler output or flamegraphs
- targeted benchmarks
- load-test results
- query plans or database timing data
- frontend bundle analysis or render timing output
- traces or metrics tied to the scoped flow
- recent regression data from CI or performance tests

Useful repo evidence includes:

- obviously expensive loops or repeated work on hot paths
- missing caches or invalidation patterns
- N+1 queries or repeated remote calls
- unnecessary serialization, parsing, or data copying
- oversized client bundles or repeated rerender triggers
- synchronization or locking patterns likely to throttle throughput

If runtime data is absent, use repo evidence carefully and label findings as
inferred until measured.

## Parallelization Rule

Use parallel work only for clearly disjoint surfaces, such as separate services,
pages, or jobs.

- keep each session on one performance surface
- avoid splitting shared libraries or overlapping hot paths across sessions
- return raw evidence from each session, not just conclusions
- rank the combined backlog centrally

If surfaces overlap heavily, keep the hunt serial and smaller.

## Instructions

### Step 1: Define The Performance Surface

Lock the scope to the smallest surface that matches the request, such as:

- one endpoint
- one background job
- one page load
- one query path
- one benchmark suite

Name the primary metric and why it matters.

### Step 2: Gather The Strongest Evidence First

Start from measured evidence when available.

Prefer:

- existing benchmark outputs
- profiler traces
- load-test artifacts
- query plans
- frontend performance reports

Do not lead with optimization folklore when stronger evidence exists.

### Step 3: Map The Critical Path

Trace the work that dominates the scoped flow:

- entry points
- repeated loops or render cycles
- database and network boundaries
- serialization and parsing work
- cache lookups and misses
- synchronous chokepoints

Identify where time, memory, or bytes are likely being spent.

### Step 4: Separate Bottlenecks From Suspicion

Bucket findings into:

- strong evidence: measured bottleneck or direct regression signal
- moderate evidence: repo-backed hotspot with clear likely impact
- weak evidence: plausible issue that still needs measurement

Only recommend fixes or experiments for strong and moderate findings.

### Step 5: Rank By User And System Impact

Prioritize bottlenecks that:

- materially affect the target metric
- sit on a critical or frequent path
- have a small, low-risk next step
- can be verified with narrow checks

Avoid broad rewrites when a smaller validation step would answer the question.

### Step 6: Propose Minimal Follow-Up Work

For each bottleneck that clears the bar, propose:

- the affected surface
- the evidence
- the likely cause
- the smallest practical experiment or fix
- the validation command, benchmark, or measurement to rerun

Prefer measurement-tight loops over broad optimization programs.

### Step 7: Call Out Unknowns

Be explicit about:

- missing runtime data
- surfaces you could not verify
- findings that are currently inferred rather than measured

If the data is too weak, say so and stop at the measurement plan.

## Output Requirements

Provide a report with these sections:

1. Scope and target metric
2. Evidence reviewed
3. Ranked bottlenecks
4. Weak-signal suspicions skipped
5. Proposed follow-up experiments or fixes
6. Unknowns or limits

For each ranked bottleneck, include:

- surface
- target metric or regression
- concrete evidence
- likely cause
- smallest next step
- validation path
- confidence

For each weak-signal item, include:

- surface
- what looked suspicious
- why the evidence is insufficient
- explicit no-fix decision

If there are no credible bottlenecks, say so plainly and explain what evidence
looked healthy.

## Quality Bar

- Stay tied to the scoped flow and metric.
- Prefer measured evidence over performance folklore.
- Distinguish observed bottlenecks from inferred hotspots honestly.
- Recommend the smallest validation-tight next step.
- Do not drift into generic cleanup, observability, or architecture work.