write-acceptance
Hand the work to a person to accept
You have finished building something and a person has to see it work before it is real. They come to this with none of the session in their head: not what you decided, not what you already checked, not which of the five buttons on that screen is the new one.
docs/<feature>/ACCEPTANCE.md (in the project's planning folder, unless it
uses another) is the page that closes that gap. It is an ordered checklist
of what is expected of them, and nothing else. You are judged on whether
they can work top to bottom without asking you a single question, and on
whether every step ends in an observable they can actually check.
Know who is reading. Usually the user, who knows the product but not this week's work. Sometimes a tester who has never seen the feature and cannot be assumed to know where anything lives. Write for the second: name the screen, the menu and the button, not "the usual place". A step the user could guess is a step the tester reports back as blocked.