Write a useful request
A good request describes a user outcome rather than a guessed implementation. State who will use the feature, what they need to accomplish, and what a successful result looks like.
Include the details that change the result
Describe the starting state, the steps a user takes, expected responses, empty and error states, mobile behavior, data rules, and any existing behavior that must remain unchanged. Mention whether the work is a Web app, Native app, or prototype if the project route is not already clear. Attach reference material only when you have permission to use it.
Use reviewable increments
Split unrelated work into separate requests. For a broad or risky change, ask for a plan first and review its scope, files or screens affected, data changes, dependencies, and validation. Correct the plan before execution when it misses a requirement.
Describe evidence, not implementation guesses
When reporting a problem, include the screen, the action you took, expected behavior, actual behavior, and the visible error. A screenshot or exact project event is more actionable than “it is broken.” Avoid prescribing a code change unless you know the relevant constraint.
Protect sensitive information
Do not paste passwords, API keys, payment details, or private customer data into the conversation. Use the appropriate account or organization connection controls and refer to a secret by its configured name, not its value.