Create Acceptance Criteria

# Create Acceptance Criteria

## Recipe

- Category: Planning
- Recommended mode: Plan Mode
- Risk level: Low to Medium
- Estimated scope: Small to Medium

## Purpose

Turn a feature request, product idea, bug fix, or workflow change into precise, observable acceptance criteria that define what “done” means.

This recipe is not for architecture planning or implementation. Its job is to remove ambiguity, expose missing product decisions, define edge cases, and create a testable contract between product intent and implementation.

## Use When

- a request is vague or outcome-focused
- different people may interpret the feature differently
- implementation should not begin before expected behavior is agreed
- a bug fix needs clear regression criteria
- a flow has important permission, state, validation, or failure behavior
- a feature plan needs measurable completion conditions
- QA or browser testing needs a reliable test basis

## Do Not Use When

- the feature itself is not yet understood
- the main decision is architectural rather than behavioral
- the request is only to explore ideas
- implementation details are already fixed but test cases are needed
- the user wants a complete test plan rather than acceptance criteria

## Inputs

- `[REQUEST]`: Original feature, change, or bug-fix request
- `[PRIMARY_ACTOR]`: Main user or role
- `[USER_GOAL]`: Outcome the actor wants
- `[CURRENT_BEHAVIOR]`: What happens now
- `[DESIRED_BEHAVIOR]`: What should happen instead
- `[BUSINESS_RULES]`: Known domain rules
- `[PERMISSIONS]`: Relevant roles, ownership, tenant, or visibility rules
- `[STATE_MODEL]`: Relevant statuses or transitions
- `[ERROR_CASES]`: Known failures or edge cases
- `[OUT_OF_SCOPE]`: Explicit exclusions
- `[QUALITY_REQUIREMENTS]`: Accessibility, responsiveness, performance, reliability, or compliance constraints

## Prompt