Fix a bug
Hand the agent a repro and a narrow brief — and get back a fix, not a rewrite.
A bug fix is the smallest unit of agent work that pays its way. The win condition is a tight diff against a known repro, not a guided tour of the surrounding module. This template pins the request to the failing input, the file you already suspect, and the validation pattern the rest of the codebase already uses.
When to reach for this template.
- You can reproduce the bug locally and paste the exact repro steps.
- You already know which file or function is implicated.
- You want a fix in one or two files — not a refactor of the module.
- The desired error contract (status code, body shape) is clear up front.
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: bug00001
task_number: 1
title: "Fix 500 on POST /api/orders when items[] is empty"
prompt: |
POST /api/orders returns 500 with an unhandled
TypeError when the request body has `items: []`.
Repro: `curl -X POST localhost:3000/api/orders -H 'content-type: application/json' -d '{"items":[]}'`.
Stack trace points at `services/orders.ts:142`,
where `items[0].price` is read without a length
check.
Return a 400 with body
`{ "error": "items_required" }` when `items`
is missing or empty. Mirror the validation
pattern used in `services/users.ts` for empty
payloads. Do not change the handler signature
or the success-path response shape.
acceptance_criteria: |
- The curl above returns 400 with the documented
error body, not 500.
- A new test in `services/orders.test.ts` covers
the empty-items case and fails on `main`
without the fix.
- `npm run test` passes.
- `npm run lint` passes.
- No changes outside `services/orders.ts` and
`services/orders.test.ts`.
status: ready
Common pitfalls.
The shapes of failure most often seen on this kind of task — and the way this template hedges against each.
- Skipping the repro. If you can't paste a `curl`, a script, or a unit test that fails, the agent can't either — it will guess at what the bug is and 'fix' something else.
- Letting the prompt say 'while you're there, clean up X.' The agent will believe you, the diff balloons, and the fix becomes unreviewable.
- Naming the symptom but not the desired behaviour. 'Don't 500' is not a spec — 'return 400 with body `{error: "items_required"}`' is.
- Forgetting to require a regression test. Without one, the same bug ships again the next time someone refactors the file.
Related templates.
Add tests for an untested module
Backfill coverage against a named bar — not the agent's idea of 'enough tests'.
Open the template
Investigate and report (no code changes)
Diagnosis only — the artifact is a Markdown report, not a patch.
Open the template
Refactor / rename
A mechanical move kept mechanical — so the diff stays cheap to review.
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.