Write acceptance criteria from a product brief

Acceptance criteria should describe observable behavior, including failure paths. Keep undecided product choices visible instead of filling them with assumptions.

Use a reviewable project copy

Give the product or code teammate the relevant specification and a dedicated project folder or branch. Separate a proposed change from permission to release it. Request a diff or evidence table alongside the recommendation, and run checks that exercise the behavior in question. Generated code and test output still need review in the actual project environment.

Inputs for this workflow: Approved product brief and known constraints.

Work through the task

1. Map each user goal to an observable outcome.
2. Identify boundary and failure cases.

A brief you can adapt

Create acceptance.md with scenario, precondition, action and expected outcome. List unresolved choices separately for the product owner.

The filenames above are examples. Replace them with your actual inputs and destination before submitting the task.

Review the deliverable

Check that each criterion can be assessed without interpreting words such as fast or intuitive.

Where this approach can fail

A generated criterion is not a newly approved feature requirement.

For the related desktop setup, see local folder.