agentsclimarketplace

Performance investigation

Skill RobinGru/AgentSkillForge/skills/performance-investigation

Portable, reusable instruction packages for AI coding assistants.

Install
npx -y skills add RobinGru/AgentSkillForge --skill performance-investigation

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

  • 0 stars0 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

Investigate a measured performance concern with a comparable baseline, bounded hypotheses, discriminating experiments, and proportionate regression protection. Use for observed latency, responsiveness, throughput, memory, or resource problems.

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

4.2 KB, as published. Nobody here has run it

Performance investigation

Treat performance work as an investigation, not a list of optimizations. Change behavior only after measurements identify a plausible bottleneck and an experiment can distinguish it from competing explanations.

Use this skill when

  • A user reports a repeatable slow path, monitoring detects a regression, or a service-level objective or agreed budget is breached.
  • A planned load change, resource limit, or measured responsiveness issue needs a risk assessment.
  • A profiling artifact, trace, metric, or reproducible workload can guide an investigation.

Do not use this skill when

  • Someone requests that code be faster but supplies no signal, affected journey, or target. Request those details and prepare a measurement plan instead.
  • An asset, query, cache, or framework change is proposed without a measurement showing that it affects a measured problem.
  • A structural refactor is the primary task. Use this skill only if measurement establishes a performance cause that the refactor must address.

Workflow

1. Signal

Record the observed issue and its impact: affected journey or operation, users or systems affected, frequency, onset, and reason it matters. Classify the signal as user report, alert, regression, budget breach, reproducible slow journey, resource exhaustion, or planned demand. Do not infer a cause from the symptom.

2. Baseline

Make measurements comparable. Record environment, build or revision, dataset, load shape, tool, sampling method and count, primary metric, side metrics, and known limits. State whether each result is lab data, field data, or both; do not combine them as though they had identical conditions. Preserve enough raw output or an accessible summary for another investigator to repeat the comparison.

3. Partition

Divide the affected path into observable portions before proposing a fix. Check only portions relevant to the signal, such as network transfer, server time, queueing, database or storage, serialization, cache behavior, client main thread, rendering, assets, concurrency, or memory collection. Record unknown portions explicitly.

Use web signals or backend signals when their scope matches the path.

4. Experiment

For each live hypothesis, use experiment design. Change one material variable, choose the smallest test that would produce a different result if the hypothesis were false, and keep comparable conditions. Do not rewrite a suspected N+1 query, render path, or cache layer before a measurement can distinguish it from alternatives.

5. Decide and guard

Retain, revert, or continue investigating based on observed results, not expectation. Any retained performance change needs before-and-after measurements for the primary metric plus relevant side effects. Choose proportionate protection: regression test, repository budget, telemetry, alert, load test, or documented manual check. Example budgets help format local targets; product and repository budgets take precedence.

Output contract

Report Signal, Baseline, Partition, Hypotheses, Experiments, Decision, Before and after, Guard, and Limits. For every experiment include:

  • hypothesis and its supporting facts;
  • smallest discriminating experiment;
  • expected and actual result;
  • decision and next information needed, if inconclusive.

Label claims as measured, observed, inferred, or unknown. State measurement limitations and unverified assumptions. Do not claim improvement without a comparable before-and-after result.

Investigation examples

See investigation examples for small API queueing, Vue input lag, and batch memory-spike investigations. They model questions and experiments, not universal implementation advice.

Keep looking

Skills are one crate of 328,083. 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.