TL;DR
Good acceptance criteria name the outcome, boundary, edge cases, verification, and stop condition. Paste the closest example below, replace the specifics, then ask AI to plan before it edits.
How to Use These Examples
These are not tickets. They are pass/fail checks you attach to a ticket before AI writes code. If an example mentions a test command, replace it with your local command. If it mentions a manual path, make the path match your product.
For the underlying structure, pair this page with The AI Acceptance Criteria Prompt and The AI Verification Ladder.
UI and Product Flow Examples
1. Add a form field
- Outcome: users can enter the new field and see it preserved after submit.
- Boundary: no redesign of unrelated form sections.
- Edge cases: empty value follows existing validation; long value does not break layout.
- Verification: run form tests and manually submit valid, empty, and long values.
- Stop condition: field works across create and edit paths with no unrelated files changed.
2. Fix a loading state
- Outcome: the page shows the existing loading pattern while data is pending.
- Boundary: no changes to fetching logic unless required to expose state.
- Edge cases: slow response and empty result both render correctly.
- Verification: simulate delayed response and confirm no layout jump on completion.
- Stop condition: loading, success, empty, and error states are all visible and distinct.
3. Improve an error message
- Outcome: users see a specific recovery instruction when the operation fails.
- Boundary: do not alter error codes, logging, or retry behavior.
- Edge cases: network failure and permission failure show different copy.
- Verification: trigger both failures locally or with mocked responses.
- Stop condition: copy is clear, accessible, and matches the existing message style.
API and Data Examples
4. Add an API filter
- Outcome: clients can filter results by the new parameter without changing default output.
- Boundary: no response shape change for existing consumers.
- Edge cases: unknown value returns an empty list; invalid value returns the existing validation format.
- Verification: run API tests for default, valid filter, unknown filter, and invalid filter.
- Stop condition: the endpoint remains backward compatible.
5. Add a database column
- Outcome: the new column is created and existing rows remain readable.
- Boundary: no destructive migration and no unrelated schema cleanup.
- Edge cases: null or default value is handled for old rows; rollback path is documented.
- Verification: run migration up/down in a local copy and execute one read/write path.
- Stop condition: migration, model, and read/write code agree on the same default behavior.
6. Tighten authorization
- Outcome: only the intended role can perform the protected action.
- Boundary: no changes to session storage or unrelated role names.
- Edge cases: unauthenticated user and wrong-role user both fail safely.
- Verification: run permission tests for allowed, unauthenticated, and wrong-role cases.
- Stop condition: denial response uses the existing status code and error shape.
Quality and Refactor Examples
7. Refactor a component
- Outcome: the component is split into smaller units with identical behavior.
- Boundary: no visual, data, or API behavior changes.
- Edge cases: empty state and error state still render as before.
- Verification: run existing component tests and compare the primary screen manually.
- Stop condition: review can map each moved block to its original behavior.
8. Add regression coverage
- Outcome: a failing scenario is covered by a focused test that fails before the fix.
- Boundary: avoid broad snapshot rewrites and unrelated test cleanup.
- Edge cases: include both the regression path and one nearby non-regression path.
- Verification: run the new test alone, then the related test file or suite.
- Stop condition: the test name explains the behavior, not the implementation detail.
9. Remove dead code
- Outcome: unused code is removed without changing runtime behavior.
- Boundary: no renames, formatting sweeps, or opportunistic rewrites.
- Edge cases: confirm no dynamic imports, string references, or config references remain.
- Verification: run search, typecheck, and the smallest affected test suite.
- Stop condition: every deleted symbol has evidence that it was unreachable.
Production Safety Examples
10. Add observability
- Outcome: the changed flow emits a useful event, metric, or log at the decision point.
- Boundary: no secrets, tokens, or personal data in telemetry.
- Edge cases: success and failure paths both include enough context to debug.
- Verification: trigger both paths and inspect local logs or telemetry output.
- Stop condition: an on-call engineer can identify what happened without reproducing the bug.
11. Add a feature flag
- Outcome: the new behavior can be enabled and disabled without redeploying.
- Boundary: default state preserves current production behavior.
- Edge cases: missing flag config and disabled flag both fall back safely.
- Verification: test enabled, disabled, and missing-config paths.
- Stop condition: rollback is documented as "turn flag off" with owner and location.
12. Patch a production bug
- Outcome: the reported failure no longer reproduces using the exact reproduction path.
- Boundary: no redesign of the surrounding subsystem during the patch.
- Edge cases: include the original failure and one adjacent input that should still work.
- Verification: run the regression test and repeat the manual reproduction path.
- Stop condition: root cause, fix, and rollback notes are included in the handoff.
AI-Specific Examples
13. Update a prompt
- Outcome: the prompt produces the target output format on the sample inputs.
- Boundary: no model, temperature, or retrieval changes in the same task.
- Edge cases: include one underspecified input and one adversarial or malformed input.
- Verification: run the existing eval set or a documented before/after sample table.
- Stop condition: quality improves without breaking required output structure.
14. Change model fallback behavior
- Outcome: the system switches to the fallback model only under the defined trigger condition.
- Boundary: no pricing, prompt, or provider abstraction changes unless required.
- Edge cases: primary timeout, primary error, and fallback error are handled separately.
- Verification: simulate each condition and confirm logs name the selected model.
- Stop condition: fallback preserves user-facing safety and acceptable response quality.
15. Add an AI code review check
- Outcome: review output flags the intended risk with a specific, actionable comment.
- Boundary: no broad rewrite of the review system or unrelated prompts.
- Edge cases: include one true positive and one case that should not be flagged.
- Verification: run the check on fixture diffs and inspect false-positive behavior.
- Stop condition: the comment explains what to change and why it matters before merge.
Turn an Example Into a Prompt
Copy-paste prompt
"Use this acceptance criteria pattern for the task below. Rewrite it for my codebase, keep it under 8 bullets, include two edge cases, and ask for missing context before editing files. Task: [paste task]."
When the criteria are clear, move to The AI Plan Before Code. When the risk is unclear, choose a level with The AI Verification Ladder before accepting implementation.