Writing effective prompts

Start with a result, not a list of tools

Describe who the application serves and the action they should complete. Include real content, important constraints, and a way to check success. You do not need to choose an AI model or manage separate agents.

For example:

Build a landing page for a ceramics workshop. Visitors should understand the schedule and request a place. Use the attached photos, show prices in euros, and make the form usable on a phone. First show me the proposed sections; do not implement yet.

That last sentence asks for a plan. When the direction is settled, explicitly ask Amazi to implement it. If you already know the desired result, you can ask for implementation in the first message.

Say what must remain unchanged

For an existing application, identify the affected page or workflow and any behavior to preserve:

On the orders page, add a filter for unpaid orders. Keep existing sorting and pagination. Reloading the page should retain the selected filter in the URL.

A screenshot helps locate a visual problem. Include the page URL or route and describe what happened, what you expected, and the steps to reproduce it. Do not rely on a screenshot alone to explain hidden behavior.

Distinguish a demo from a working integration

Say whether the first version should use sample data or real persistence. A form that displays a success message is not necessarily saving a record or sending an email. Ask for the complete outcome, such as “save the request, display confirmation only after it succeeds, and show a useful error if it fails.”

If a service needs credentials, use the protected connection flow rather than putting secrets in your prompt. See Connections and environment.

Iterate in reviewable steps

Review the first result before adding unrelated features. Refer to a specific page, element, or earlier message when requesting a change. Ask for a focused explanation if a decision is unclear instead of repeatedly resubmitting the same implementation request.

Keep durable preferences in Project instructions. Put task-specific requirements in chat. Use Testing and verification to define what “done” means for each change.