The prompt
Score 10 of 10, Excellent
Use it when Something in your code is too slow, and you want an agent to find the cause and prove its fix with measurements rather than guesses.
- {{slow_operation}}
- {{current_timing}}
- {{target_timing}}
- {{location}}
- {{repro}}
- {{suspicion}}
- {{test_command}}
- {{off_limits}}
Full prompt and why it works
Prompt
Goal: Make {{slow_operation}} faster. Today it takes {{current_timing}}; the target is {{target_timing}} under the same conditions, with identical results. Context: - Where it runs: {{location}} - How to reproduce the slow case (input size, data, request): {{repro}} - What I suspect, if anything: {{suspicion}} - Test command: {{test_command}} Constraints: - Measure before changing anything. Write or use a repeatable benchmark for the slow case (for example a script in scripts/bench/ or a benchmark test), run it at least 5 times, and report the median. Use a profiler if the project has one, and find where the time actually goes before choosing a fix. - Reply with what the profile shows and your proposed fix before editing. Wait for my go-ahead if the fix adds a dependency or a cache, changes a database schema or index, or changes a public interface. - Change one thing at a time and re-measure after each change, so every gain is tied to a specific edit. - The output must stay exactly the same, including ordering and error behavior. Do not drop validation, logging or error handling to save time. - Do not touch {{off_limits}}. Do not change or delete existing tests. Done when: - The benchmark median meets {{target_timing}}, or you have reported the best you reached and what limits it. - {{test_command}} passes, and a test confirms that the results for the slow case match the results from before the change. Verify: run the benchmark and the tests, then report a table with the columns Change, Median before, Median after, plus the commands you ran and the last 20 lines of the test output. If the time is spent inside a single slow database query or an external service, rather than in how often or how this code calls them (repeated queries in a loop are this code's problem), stop and tell me instead of optimizing around it.
Variables
- {{slow_operation}}
- What is slow, for example "generating the monthly invoice PDF" or "the /search endpoint".
- {{current_timing}}
- How long it takes now and how you measured it, for example "about 8 seconds for an account with 2,000 invoices".
- {{target_timing}}
- The time you need, for example "under 2 seconds for the same account".
- {{location}}
- Files, functions or endpoints involved, as far as you know.
- {{repro}}
- The input, data or request that triggers the slow case.
- {{suspicion}}
- Your guess at the cause, or "none".
- {{test_command}}
- The command that runs the tests, for example npm test or pytest.
- {{off_limits}}
- Files, folders or systems that must not change.
Why it works
- What good looks like. A benchmark median before and after each change is the proof, so "it feels faster" never counts as done.
- What to avoid. Results, ordering and error behavior must stay identical, and validation or logging cannot be cut to win time.
- If unsure. If the time is spent in a database or external service, the agent stops and reports instead of building workarounds around the real cause.