PluginBench
Skill
Pass
Audit score 90

benchmark-optimization-loop

affaan-m/ecc

Systematically benchmark and optimize code performance through measured iteration and variant testing.

What is benchmark-optimization-loop?

This skill guides you through a structured optimization loop: establish a baseline, generate and test variants against a correctness gate, measure performance (latency, throughput, cost), and promote the fastest safe variant. Use it when you need to make something faster or compare implementations by repeated measured tests rather than guessing.

  • Measure baseline performance and identify bottlenecks from evidence
  • Generate single-hypothesis variants and run them with identical input shapes
  • Reject variants that fail correctness, safety, or reproducibility checks
  • Track all variants in a comparison table with metrics and notes
  • Promote the fastest safe variant and codify the winning path
  • Run recursive/hyperparameter searches with a ledger to avoid local optima

How to install benchmark-optimization-loop

npx skills add null --skill benchmark-optimization-loop
Prerequisites
  • An operation or system to optimize that is already working correctly
  • A correctness gate (tests or validation) that must remain green
  • A defined metric to measure (wall time, p95 latency, throughput, cost, memory, error rate)
  • Current baseline measurement
  • A search budget (max variants, max time, max spend, or max data impact)
Claude Code
Cursor
Windsurf
Cline

How to use benchmark-optimization-loop

  1. 1.Establish and measure the baseline performance with your chosen metric
  2. 2.Identify bottlenecks using profiling, logs, or evidence from the baseline run
  3. 3.Define one hypothesis per variant (e.g., 'fewer round trips' or 'more workers')
  4. 4.Run each variant with the same input shape and record results in a variant table
  5. 5.Check each variant against your correctness gate; reject any that fail
  6. 6.Compare all safe variants and select the fastest one as the new winner
  7. 7.Codify the winning variant in a script, config, test, or documentation
  8. 8.Re-run both baseline and winner to confirm and document the performance delta

Use cases

Good for
  • Optimizing a slow database query by testing batching, indexing, and parallel strategies
  • Reducing API latency by trying connection pooling, caching, and worker count variations
  • Comparing two algorithm implementations to choose the one with best measured throughput
  • Hyperparameter tuning for a machine-learning pipeline with cost and accuracy constraints
  • Reducing memory usage of a data processing job by testing different buffer sizes and streaming approaches
Who it's for
  • Backend engineers optimizing application performance
  • Data engineers tuning ETL and batch jobs
  • DevOps engineers reducing infrastructure costs
  • Performance engineers conducting systematic benchmarking
  • Anyone with a measurable performance goal and a bounded search budget

benchmark-optimization-loop FAQ

When should I stop optimizing?

Stop when improvement is within noise, correctness fails, cost exceeds your budget, or the search starts changing more variables than it can explain. Use 'best measured safe variant' language unless you exhaustively searched the space.

How do I handle recursive or hyperparameter optimization?

Persist every run to a ledger, compare against the prior accepted winner (not just the previous run), keep a holdout or replay check, and track which variables changed in each iteration.

What if a variant is faster but I'm not sure the delta is real?

Re-run both the baseline and the variant with the same input to confirm the delta is repeatable and not noise. Document exact commands and measurements.

Can I optimize without a correctness gate?

No. Do not optimize until correctness tests exist and stay green. A fast wrong answer is worse than a slow correct one.

How detailed should my variant table be?

Track at minimum: variant name, hypothesis, command, time, correctness pass/fail, and notes. This makes it easy to compare and explain why each variant won or lost.

Full instructions (SKILL.md)

Source of truth, from affaan-m/ecc.


name: benchmark-optimization-loop description: Use when the user asks to make something faster, try many variants, run recursive optimization, benchmark latency/throughput/cost, or choose the best implementation by repeated measured tests. metadata: origin: ECC tools: Read, Write, Edit, Bash, Grep, Glob

Benchmark Optimization Loop

Use this skill to convert "make it 20x faster" or "try 50 recursive optimizations" into a bounded measured loop that can actually improve a system.

Required Baseline

Do not optimize until these exist:

  • the operation being optimized;
  • the correctness gate that must stay green;
  • the metric: wall time, p95 latency, rows/sec, cost/run, memory, error rate;
  • the current baseline;
  • the search budget: max variants, max time, max spend, max data impact.

If the user asks for an unrealistic target, keep the ambition but make the loop bounded and measurable.

Loop

  1. Measure the baseline.
  2. Identify bottlenecks from evidence.
  3. Generate variants that test one hypothesis each.
  4. Run variants with the same input shape.
  5. Reject variants that fail correctness, safety, or reproducibility.
  6. Promote the fastest safe variant.
  7. Codify the winning path in a script, command, test, config, or doc.
  8. Rerun the baseline and winner to confirm the delta.

Variant Table

Track variants like this:

Variant | Hypothesis | Command | Time | Correct? | Notes
baseline | current path | npm run job | 120s | yes | stable
batch-500 | fewer round trips | npm run job -- --batch 500 | 42s | yes | winner
parallel-8 | more workers | npm run job -- --workers 8 | 31s | no | rate limited

Recursive Search

For recursive or hyperparameter work:

  • persist every run to a ledger;
  • compare against the prior accepted winner, not only the previous run;
  • keep a holdout or replay check;
  • stop when improvement is within noise, correctness fails, cost exceeds the budget, or the search starts changing more variables than it can explain.

Use phrases like "best measured safe variant" instead of "global optimum" unless the search space was actually exhaustive.

Promotion Gate

A variant cannot become the new default until:

  • correctness tests pass;
  • the performance delta is repeated or explained;
  • rollback is obvious;
  • the change is encoded in source control or a durable runbook;
  • the final summary includes exact commands and measurements.