Put one job first
Name the single task that matters most for this change. A bounded task gives you a clear input, a clear output, and a decision you can make quickly. “Improve the product” is not a task. “Turn a five-item backlog into a dated checklist” is. A model, prompt, interface, or workflow can support other jobs later; do not make the first acceptance test responsible for all of them.
Make acceptance observable
Write the current behavior and the desired behavior in concrete terms. Keep the scope narrow enough that a person can inspect the result without guessing. If the task affects a public interface, evaluate the public interface; passing internal tests alone does not prove that a user can complete the task. Tests are still useful, but they are evidence for the bounded change rather than a substitute for the user-facing check.
Synthetic example: Primary task: “A visitor can find the next appointment from a three-row schedule.”
- Before: The page lists appointments in entry order; the visitor scans all three rows.
- After: The page presents the soonest appointment first and labels its date and time.
- Acceptance: Using the fictional rows 09:30, 14:00, and 11:15, a visitor identifies 09:30 without opening a detail view. A test may also assert the sort order, but inspect the rendered public page as well.
Do not add “also summarize the schedule, send an email, and redesign the calendar” to this acceptance check. Record those as separate tasks with separate criteria. This discipline makes model comparisons fair too: give each candidate the same task, inputs, and rubric instead of changing the goal when an answer disappoints. The models documentation (opens in a new tab) is a source for model-selection facts, not a replacement for your own task definition. Verified 2026-09-06.