Tag product and design in Slack for acceptance: @emmy-acceptance-testers
- No acceptance testing needed
- This change will not affect the user experience (bugfix, dependency updates, etc.)
- Acceptance testing prior to merge
- This change can be verified visually via screenshots attached below or by sending a link to a local development environment to the acceptance tester
- Acceptance testing should be done by design for visual changes, product for behavior/logic changes, or both for changes that impact both.
- Acceptance testing in PR Environment
- This change can be verified in a PR environment. Run this Github Action with the existing PR and most recent git sha.
- Acceptance testing after merge
- This change is hard to test locally, so we'll test it in the demo environment (deployed automatically after merge.)
- Make sure to notify the team once this PR is merged so we don't inadvertently deploy the unaccepted change to production. (e.g.
:alert: Deploy block! @ffs-eng I just merged PR [#123] and will be doing acceptance testing in demo - please don't deploy until I'm finished!)
- USED_AI: I attest that I have read, understood, and take ownership of all AI-generated code in this PR.
- NO_AI: I did not use AI.
Optional — for learning, not audited:
- AI tools used: <e.g. GitHub Copilot, Claude Code — shows what's in use>
- Prompt artifacts: <link a prompt/chat if worth keeping; otherwise skip>
- Plan reviewed
- Applied in dev before merge
- Applied in demo after merge
- Applied in prod after merge (note any exceptions or special coordination below)