Write effective prompts

A prompt is a work order in normal language. You do not need to describe implementation details, but you should make product decisions explicit.

The most reliable prompts sound like a clear conversation with a capable teammate. Explain the result, the person using it, and the boundaries. Mango9 can choose the implementation, but it should not have to guess whether “customer” means a shopper, an account owner, or an internal support agent.

Longer is not automatically better. A short prompt with a concrete outcome and two important constraints is usually stronger than a page of broad adjectives. Add detail when it removes a real ambiguity, not simply to make the request look formal.

Example: “Create a daily task view for sales reps. Show overdue work first, let a rep mark a task complete, and keep managers able to see the whole team. Do not redesign the rest of the CRM.”

A practical prompt structure

You can use all five parts for a new workflow, or only the parts that matter for a small correction. Outcome and Acceptance describe the finish line. Users and Scope keep the work connected to the right people and pages. Constraints protect what is already correct.

Read the prompt once as if you were the person receiving it. If two reasonable people could build very different results, add the missing product decision. If the request already makes the finish line obvious, send it without turning it into a specification document.

Example: “Outcome: dispatchers can assign an open job to a technician. Users: dispatchers only. Scope: jobs list and job detail. Constraint: technicians remain read-only. Acceptance: the selected technician appears immediately on both pages.”

Outcome: What should be true when this is finished?
Users: Who uses it and what roles matter?
Scope: Which pages, records, or workflow steps are included?
Constraints: What must stay unchanged?
Acceptance: What should I be able to see or do in Preview?

Example:

Add an inventory intake page for warehouse staff. Each item needs an SKU,
name, quantity, location, supplier, and received date. Staff can add and edit;
managers can also delete. Keep the existing dashboard colors and navigation.
On mobile, the form must fit without horizontal scrolling.

Build in coherent slices

A focused prompt is easier to verify and usually more economical than one that changes unrelated areas. Good slices include:

• one workflow across the pages it genuinely touches;
• one visual system update across existing components;
• one integration with its success and error states;
• one mobile defect with the exact affected surface.

Avoid splitting a feature so narrowly that every prompt needs unfinished work from the previous one. “Add the customer record, its detail page, and the create/edit flow” is one coherent slice. “Change the button color” can be a separate visual slice.

A coherent slice has one reason to exist and one testable user outcome, even if it touches several files or pages. A booking cancellation flow may need a booking record, a confirmation dialog, and an updated schedule; those pieces belong together. A simultaneous homepage redesign does not.

Example: Build “customer intake from form submission to saved customer detail” as one slice. Build “replace the entire brand style” later, after the intake workflow is proven.

State preservation rules

When updating an existing project, name what must remain:

Keep all existing wording, routes, data behavior, and desktop layout.
Only change the mobile filter panel described below.

Preservation rules are most important when most of the page is already correct. Name the stable behavior in plain language: existing routes, wording, permissions, calculations, desktop layout, or data. This prevents a narrow repair from being interpreted as permission for a broader redesign.

Example: “Only change the order-status badge colors. Keep status names, filtering, sorting, permissions, and all card spacing exactly as they are.”

Use references intentionally

A screenshot is most useful when you also explain what to copy:

Use the attached dashboard only for spacing and card hierarchy. Keep our
existing colors, wording, and navigation. Do not copy its brand.

Documents can supply requirements or content. Do not assume Mango9 knows which parts are binding—say what role the document plays.

Separate inspiration from instruction. A screenshot may demonstrate density while your app keeps its own colors. A document may contain approved wording while its old process diagram is background information. State that distinction in the same message as the attachment.

Example: “The attached PDF is authoritative for the refund steps and customer-facing wording. Its screenshots show an older design and should not be copied.”

Example: “Use this website link only as a reference for the large product photography and calm spacing. Keep our navigation, logo, and checkout flow.”

Describe defects with evidence

Include:

1. The page or route.
2. The device or viewport.
3. What you did.
4. What happened.
5. What should happen instead.
6. A screenshot when visual.

Example:

On /contacts at iPhone width, opening Filters pushes the composer upward and
covers the last contact. Filters should overlay the list and the composer must
stay fixed. Desktop is already correct and must not change.

Evidence keeps a repair grounded in something reproducible. “It does not work” could describe a visual overlap, a failed request, missing data, or a permission problem. The route, action, and observed result tell Mango9 where to investigate and give you a clear way to confirm the fix.

Example: “On /orders/42, tapping Refund as a manager closes the dialog but leaves the order Paid. It should show Refunded and add the refund to the activity list. This happens in Chrome and Safari.”

Common prompt mistakes

Most weak prompts are not too short; they leave the important decision unstated. Replace general approval words such as “better,” “professional,” or “fixed” with the visible behavior you want. When you truly want Mango9 to make a reasonable design choice, say which outcomes and boundaries it should optimize for.

Example: Instead of “Make the dashboard better,” write, “Make the dashboard easier for a manager to scan in under a minute: show overdue tasks, pipeline total, and today’s appointments first. Keep all existing records and routes.”

| Instead of | Try | |---|---| | “Make it modern.” | Name the desired hierarchy, density, tone, and one or two references. | | “Fix everything.” | Name the failing workflow and its expected result. | | “Build a complete CRM.” | Define the first users, records, pipeline, and permissions. | | Repeating the same prompt while a build runs. | Let the current build finish or stop it before submitting again. | | Pasting a secret into chat. | Save it under Environment Variables and refer to its variable name. |

Use Publish, Versions, Domains, Billing, and Team controls for those operations instead of asking the builder to click them for you. This keeps the action explicit and avoids unnecessary build work.