Acceptance criteria

# Acceptance criteria

Use when writing or tightening acceptance criteria for a feature so the work has a clear, testable definition of done.

## Workflow

1. Read the feature description, then the child requirements, then linked ideas and comments and dependencies when they affect edge cases or constraints
2. Confirm the feature is specific enough to define behavior. If it is not, name the missing behavior instead of guessing.
3. Extract the main user outcome and the primary flow
4. Write the happy path first, in the order the user experiences it
5. Add edge cases that materially affect delivery or QA
6. Add explicit constraints and nongoals
7. Add nonfunctional criteria only when the feature, linked context, or user instructions support them
8. Do a quality pass to remove vague, untestable, or implementation-led wording

## Rules

**Format:** Default to given, when, then. Every criterion must be observable and testable. Prefer one behavior per criterion. Use precise actor names and permission roles. State what must not happen when constraints matter.

**Coverage:** Cover these areas when relevant: primary user flow, empty states, error and recovery states, permissions and role boundaries, required fields and validation, record state transitions, existing-data handling, scale-sensitive behavior, integration failures, and explicit non-goals

**Judgment:** Prioritize criteria that resolve likely handoff ambiguity for design, engineering, or QA. Bias toward the smallest complete definition of done that still protects the customer experience. When requirements already define behavior well, tighten them rather than rewriting the feature.

**Stop conditions:** Do not proceed straight to criteria when the target actor, the workflow being enabled, the success condition, or a critical permission rule is missing and would change the outcome. Say what is missing and ask only for that detail.

**General:** Describe external behavior, not implementation. Do not invent configuration, validation, permissions, or system responses the record does not support. Reference the feature by reference number and name. Headers use sentence case. No em dashes, en dashes, or curly quotes.

## Output

```
### Acceptance criteria  
- \*\*Given\*\* <starting context>, \*\*when\*\* <action>, \*\*then\*\* <outcome>.
```

Group criteria by scenario when the feature has distinct modes such as setup, everyday use, and exceptions.

## Quality checks

- The primary flow appears before edge cases
- At least one criterion covers an empty, invalid, or failure state when applicable
- Constraints include what must not happen, not only what must happen
- Wording is specific enough that QA could validate it without interpretation
- No criterion leaks into implementation detail