write-acceptance

Installation
SKILL.md

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.

Installs
38
First Seen
13 days ago