Performance regression hunt
Pin the threshold in the acceptance criteria — and make the agent prove it.
Performance fixes are the easiest place for an agent to ship a 'looks faster' diff that regresses production. This template forces a measurable bar: a baseline number on `main`, a benchmark command the agent has to run, and a numeric threshold the change has to beat before it can be merged.
When to reach for this template.
- You have a measurable baseline — a benchmark script, a p95 graph, a load test.
- You can name a numeric pass/fail threshold the change has to clear.
- There's a recent commit range or version delta where the regression appears.
- You're willing to throw the change away if the numbers don't move.
The template.
Drop this into .watchfire/tasks/<n>.yaml, edit the prompt and acceptance_criteria to match your repo, and let the daemon run it.
task_id: perf0008
task_number: 8
title: "Investigate and fix /api/search p95 regression since v1.4.0"
prompt: |
Since v1.4.0, `GET /api/search?q=...` p95
latency has roughly doubled (from ~80ms to
~160ms on the staging dataset). Find the
regression and fix it.
Workflow:
1. Establish a baseline. Run
`npm run bench:search` (existing script,
see `bench/search.ts`) on `main` and
record p50/p95/p99 in your scratch notes.
2. Form a hypothesis from the v1.3.0..v1.4.0
git log and reading the touched files.
3. Implement the smallest plausible fix.
4. Re-run `npm run bench:search` and record
the new numbers.
5. If p95 is not back under 100ms on the same
dataset, throw the change away and try a
different hypothesis. Do not merge a
regression-flavoured improvement.
Ship the diff only if the benchmark passes.
acceptance_criteria: |
- `npm run bench:search` reports p95 under
100ms on the staging dataset after the
change.
- The PR description (paste it into the task's
final commit message) includes before/after
numbers for p50, p95, p99.
- `npm run test` and `npm run lint` pass.
- No changes to the public response shape of
`/api/search`.
- No new runtime dependencies.
status: ready
Common pitfalls.
The shapes of failure most often seen on this kind of task — and the way this template hedges against each.
- No numeric bar. 'Make it faster' lets the agent declare victory after a 2% improvement; pin a real threshold ('p95 under 100ms on the staging dataset').
- No baseline measurement. Without numbers from `main`, you can't tell whether the agent's 'after' is genuinely better or just measured on a quieter machine.
- Letting the agent change the response shape to win the benchmark. Forbid it in the prompt; otherwise the regression silently moves to a different layer.
- Skipping the 'throw it away' rule. Without 'if the bench doesn't pass, drop the change and try a different hypothesis', the agent ships a marginal improvement and calls it done.
Related templates.
Investigate and report (no code changes)
Diagnosis only — the artifact is a Markdown report, not a patch.
Open the template
Fix a bug
Hand the agent a repro and a narrow brief — and get back a fix, not a rewrite.
Open the template
Add tests for an untested module
Backfill coverage against a named bar — not the agent's idea of 'enough tests'.
Open the template
Pair it with a playbook.
These use-case playbooks lean on tasks shaped like this one.
Build your own.
This template is a starting point. Fill in a form to draft your own task in the playground — or read the full task schema to learn every field the daemon understands.
Get started with Watchfire
Install in seconds. Define tasks. Let agents ship code for you.
Download for macOSAvailable for macOS, Linux, and Windows
# Install via Homebrew (macOS)brew tap watchfire-io/tapbrew install --cask watchfire-io/tap/watchfire# Set up your project and gowatchfire initwatchfire task add "Build the login page"watchfire start --allIncludes GUI, CLI, and daemon. Also available via Homebrew.