Awesome Claude Prompts Unofficial

Optimize code to a measurable target

Give Claude Code a metric and a target value, so it measures first, changes one thing at a time and stops when the number is reached.

Task: Optimize code to a measurable target · Other tasks

Fill in the details

Something that can be measured, such as latency, memory, bundle size or query count.

Optional, but it helps Claude judge how far there is to go.

Optional. A command or script that prints the metric. Without one, Claude proposes a measurement first.

Copy your prompt

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

3 required fields are empty.

What you type is kept in this tab's session storage so a reload doesn't lose it. Use "Clear this task" to remove it. Browsers can restore session data when they reopen tabs, so closing a tab isn't a guaranteed way to erase it.

When to use this template

  • Something is measurably too slow, too large or too expensive, and you can name the number that would be good enough.
  • You want the optimization to stop at a defined point instead of continuing into changes that add complexity for little gain.
  • You need a record of what was tried and what each change bought, for a review or a performance report.

When not to use it

  • You cannot measure the problem yet, only feel it. Start by asking Claude to build a measurement, then come back to this template with the numbers.
  • Measurements already show that the bottleneck is outside your code, for example an undersized database server, and the remedy is operational. If you are not yet sure where the time goes, use this template for steps 1 and 2 first, then decide.
  • The code is about to be rewritten or removed. Spending effort on the old version is rarely worth it.

Why this structure

  • A metric and a target value make "done" unambiguous. Claude can tell when to stop, and you can tell whether it succeeded, without arguing about what "faster" means.
  • Measuring first, with your command or a repeatable measurement Claude writes and shows you, gives a baseline and a check Claude can rerun after every change.
  • Step 2 asks for evidence of where the time goes before any change. Optimizing a guess often spends effort without moving the number.
  • One change at a time with a before and after table shows what each change was worth, so you can keep the ones that mattered and drop the ones that did not.
  • The stop rule in step 4 covers both outcomes: reaching the target, and finding that it is out of reach. Either way you get numbers instead of an open-ended session.
  • The closing rules keep the tests passing and put tradeoffs against correctness, security or readability in your hands rather than Claude's.

Example input (fictional)

What to optimize
the product search endpoint
Metric
p95 latency
Target value
under 500 ms
Current value
about 2 s
How to measure it
npm run perf:search

Follow-ups to send Claude

  • Which change in the table gave the biggest gain for the least added complexity? Would you keep all of them?
  • Add a check to the test suite that fails if the metric goes back above the target.
  • Measure again under the larger data set in fixtures/large and tell me whether the result holds.

Common mistakes

  • Asking to "make it faster" with no number. The work then has no finish line and tends to drift into risky changes.
  • Measuring once. Timings vary between runs; a measurement that is not repeatable cannot tell a real gain from noise.
  • Accepting a gain without checking the tests and the diff. Some speedups come from skipping work that was actually needed.
  • Plan a code change before editing: Have Claude Code read the relevant code and propose a file-by-file plan for a multi-file change, without editing anything until you approve it.
  • Investigate a production incident: Give Claude Code the symptom and when it started; it checks logs, recent deploys and config changes, then names the most likely cause with evidence.
  • Write unit tests: Get unit tests for a function or module in your framework, covering normal cases, edge cases and errors, with each test explained.

See all templates

Sources