Productivity
Write a PRD
A spec an engineer can pick up cold, including what is not being built.
Fill it in
What you want and why.
What this deliberately does not do.
Testable conditions per story.
Your prompt
Write a PRD for this. [the feature] Open with the PROBLEM and the evidence for it. A PRD that opens with the solution locks in an approach before anyone has argued about whether it is the right one, and engineers then spend the review discussing implementation of the wrong thing. Write non-goals explicitly. They are what stops scope creep, and they are also the fastest way to surface a disagreement, because someone always objects to one. Each user story gets acceptance criteria that are testable. "Works well on mobile" is not testable; "the form is usable at 320px with no horizontal scroll" is. Say what you do NOT know and how you plan to find out, rather than guessing in a document that will be treated as decided.
Use Write a PRDOpens with everything above already filled in.
Why this works
A PRD that opens with the solution locks in an approach before anyone argues about whether it is right, and the review then discusses implementing the wrong thing. This opens with the problem and its evidence, writes non-goals explicitly, and says what it does not know.