Writing Good Requests
Give Zeneno the client context it needs to work through the build.
Start with what the client needs the app to do. Then describe the people using it and the main journey each person should complete. Name any business rules, data that must persist, required services and visual references.
Separate must-have behavior from ideas that can wait. If a detail is important, say it directly: prices, permissions, approval steps, failure states, and what counts as done. You do not need to prescribe every file or framework.
For a follow-up, point to the current screen or workflow, describe the problem you observed, and give the expected result. Keep unrelated changes for separate requests.
Do
Name the audience and the task they need to complete.
List the required pages, data, roles, and external services.
Give exact business rules and visual direction where they matter.
Describe a successful end-to-end result.
Do not
Assume Zeneno knows which features of a large product you mean.
Leave payments, permissions, or storage requirements until after the build.
Bundle several unrelated changes into one follow-up.
Use only “make it better” when you can identify what feels wrong.