Menu
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.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| 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":"HCP"} |
| tools | Read, Write, Edit, Bash, Grep, Glob |
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.
Do not optimize until these exist:
If the user asks for an unrealistic target, keep the ambition but make the loop bounded and measurable.
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
For recursive or hyperparameter work:
Use phrases like "best measured safe variant" instead of "global optimum" unless the search space was actually exhaustive.
A variant cannot become the new default until:
顽皮制造 — Fuse multiple external skill repos/sources into an existing skill to create a unified, more capable version. Use when the user says 'merge these skills', 'combine X into Y', 'absorb the best parts of A/B/C into Z', 'upgrade this skill with features from those repos', or provides multiple GitHub URLs and asks to integrate them into a single skill. Also triggers on 'audit these skills and see if they can enhance ours'.
Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.
Guides systematic root-cause debugging. Use when tests fail, builds break, behavior doesn't match expectations, or you encounter any unexpected error. Use when you need a systematic approach to finding and fixing the root cause rather than guessing.
Structures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, or when you need to organize work across multiple parallel streams.
Breaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible.
Drives development with tests. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality.