Acceptance Criteria — Claude Code Guide

An acceptance criterion is a readiness condition

An acceptance criterion describes a verifiable condition after changes are made. It shows what result counts as complete and keeps the agent from making unnecessary edits in neighboring styles, APIs, or components.

A good criterion is observable, concrete, usually contains one main condition, and does not depend on the internal implementation.

Criterion categories

• Functional — what must start working.
• Negative and boundary — what must not happen.
• Compatibility — which contracts and scenarios are preserved.
• UI / output — what the user will see and where.
• Technical — which tests, logs, or signals must be correct.
• Documentation — which hints and instructions need to be synchronized.

A criterion list and Given / When / Then

Functional:
- With a valid refund reason, the request is created.

Negative scenarios:
- An empty or whitespace-only reason does not trigger submission.

Compatibility:
- The POST /api/orders/{id}/refund contract does not change.

UI:
- An error message appears below the field.

Given: the refund form is open and the reason field is empty
When: the operator clicks the submit button
Then: the request is not sent
And: an error message is displayed below the field

Derive criteria from facts

1. Record the affected files and current behavior.
2. Describe how to reproduce the problem.
3. Write down the actual and desired results.
4. List the constraints and immutable contracts.
5. Add a positive scenario that must not be broken.
6. Check each item separately after implementation.

What to avoid

• Subjective words without a measurable result: “convenient,” “better,” “clear.”
• Replacing a criterion with a technical solution: debounce, a hook, or a specific function is an implementation method.
• Combining several different checks into one vague item.
• Forgetting behavior that must remain unchanged.
• Adding unnecessary “just in case” criteria.