Write a project brief - Fabricate

A useful first prompt explains the job the app should do. Start with a narrow outcome, then add detail about the records and rules behind it.

Include five things

Audience: who uses the app and why.
Main action: the most important task they should complete.
Records: what the app saves and which fields matter.
Access: who can read, create, edit, or delete each record.
Acceptance checks: what you will do to confirm the workflow works.

Example: a client request portal

Build a client request portal for a small design agency.
Clients sign in, submit a request with a title and description,
and see only their own requests. An agency administrator can
view all requests and change status between New, In progress,
and Done. Save requests and status changes in the database.

Start with login, the request form, a client list, and an admin
list. Use synthetic examples. Do not add payments or email yet.

I will test with two client accounts. Each client must be unable
to read or modify the other client's requests, including through
API requests. After refresh and signing back in, saved requests
must remain. Show useful empty, loading, and error states.

This is an example specification, not a claim that an app has passed those checks. Verify the generated result using Test your app.

Add features in small steps

Once the main workflow works, request one change at a time. State which behavior must stay the same. For an integration, identify the provider, inputs, expected response, and failure behavior. See Connect an external API.

Ask questions without requesting edits

Use wording such as: “Explain the current data model and its limitations. Do not change files.” Questions use the same chat and consume credits too. Review the answer before requesting a change.

Keep private information out of examples

Use invented names and records. Put provider keys in Environment settings, not in the prompt. Share the shape of an API response without its tokens or personal data.