Skip to content

Prompting tips

In shortSay who the app is for, what people do in it and what should happen next. Describe the whole app in your first request, then ask for one change at a time. Use Plan when you are unsure, Chat to ask without changing anything, and Edit mode or Clip to point at what you mean. When something breaks, say what you did, what you expected and what happened — and use Versions to go back.

MonstarX builds what you ask for, so the way you ask matters. You do not need special words or technical terms — plain language is best. These tips help you get what you want in fewer requests, which also means less of your plan’s usage.

A good request answers three questions, in your own words:

  1. Who is it for? “Members of my yoga studio”, “our support team”, “parents booking tutors”.
  2. What do they do in it? “See this week’s classes and book a spot”, “look up an order and issue a refund”.
  3. What should happen next? “Send a confirmation email”, “show the booking on a My bookings page”.

Add anything that really matters to you — the name, the look, a rule (“each class holds 12 people”), what not to do — and leave out what does not. MonstarX fills the gaps with sensible choices, and you can change them later.

WeakBetterWhy it is better
“A booking app”“A booking site for my yoga studio: a weekly class timetable, a spot limit for each class, member sign-in, and a confirmation email when someone books.”Says who it is for, what people do, and what happens after.
“Make it look better”“Use a calm green and cream palette, a serif font for headings, and more space between the timetable rows.”Names the change, so there is nothing to guess.
“Fix the bug”“On the Book page, choosing a class that is full still lets me book it. It should show Class full and a Join waitlist button instead.”Says where, what happens, and what should happen.
“Add payments, reviews, a blog, a map and a newsletter”“Add a Reviews section to each teacher’s page: members can leave a 1–5 star rating and a comment.” (then the next one)One feature at a time is easier to check and easier to undo.
“Change the button”Click the button in Edit mode and write: “Make this say Book your first class free.”Pointing removes any doubt about which button.
“Make it like Airbnb”“Show the classes as cards with a big photo on top, the time and teacher below, and a Book button on each.” — and attach a screenshot.Describes (and shows) the part you like, not a whole other product.

Should I ask for a whole app or one feature at a time?

Section titled “Should I ask for a whole app or one feature at a time?”

Both, at different moments:

  • Your first request can describe the whole app. MonstarX turns it into a feature plan — a checklist it works through one feature at a time — so a first request with five or six features is fine. See The feature plan.
  • After that, ask for one change or one feature per request. Each build saves its own version, so if one goes wrong you can undo that one alone. It is also easier to check what changed.

Have several things in mind? Send them one after another: while MonstarX builds, new Build requests wait in the queue and start by themselves. See The queue.

MonstarX has three modes, above the prompt box in every project: Build changes the app, Plan asks questions first and then builds, and Chat answers without changing anything. For a new app, the Plan first switch on the Projects page does the same as Plan.

Use Plan when you are not sure yet, or when a feature has several reasonable ways to go. MonstarX asks you a few questions, one at a time, each with suggested answers to pick from — who uses it, what it is called, how it should look — and builds once you have answered.

It takes a little longer, and it saves you the requests you would otherwise spend on “not like that”. See Plan first.

How do I ask a question without changing anything?

Section titled “How do I ask a question without changing anything?”

Switch to Chat mode. MonstarX can read the code, look at the data, open pages and read the logs to answer you, but it never changes the app. It is the right mode for:

  • “Why does the timetable show last week’s classes?”
  • “What would it take to add payments?”
  • “Which pages can someone see without signing in?”

If the answer proposes a change you like, click Build this under it: MonstarX switches to Build mode and does it. Chat questions are answered right away, even while a build is running. See Modes.

Words are not always the quickest way. Show it instead:

  • Edit mode — click Edit above the preview, click an element or draw around an area, and say what should change there. You can mark up to 20 changes and send them together. See Edit mode.

  • Clip — click Clip, drag a box around anything on the page, and a picture of exactly that goes into your message with the page it came from. Good for “this looks wrong” or “make this match that”. See Clip.

  • Attach pictures — screenshots of an app you like, a sketch, a mockup, your logo. See Attach files.

  • Attach documents — an RFP, a specification, meeting notes, a spreadsheet of your data. MonstarX reads them and builds from them. See Build from documents and From a spreadsheet.

What should I do when something goes wrong?

Section titled “What should I do when something goes wrong?”
  1. Describe what you saw, precisely. Say which page, what you did, what you expected, and what happened instead. Copy any error message word for word.

  2. Show it. Use Clip on the broken part, or attach a screenshot.

  3. Ask before fixing, if you are unsure. In Chat mode, ask “Why does booking a full class still work?” MonstarX looks into it and explains, then Build this fixes it.

  4. If a change made things worse, go back. Open Versions and Restore the version before it, then ask again with more detail. Your app’s data is not affected. See Versions.

If the same fix keeps failing, try a different angle: break it into smaller steps, explain the rule rather than the symptom, or switch the model picker from Auto to a stronger model for that one request. See Choose a model and Troubleshooting.

  • Name things the way your customers do. “Classes”, “members”, “mats” — MonstarX uses your words in the app.
  • Say what should stay the same. “Change the header colour, but keep the logo and the menu as they are.”
  • Say how many and how much. “12 spots per class”, “prices in Australian dollars”, “show 20 per page”.
  • Ask for content, too. “Write the About page for a friendly neighbourhood studio” gives you real text instead of placeholders.
  • Test as a real user. Sign in with the Demo account MonstarX gives you and try the app the way your customers will — then tell MonstarX what felt wrong.
  • Never paste passwords or API keys into the chat. When the app needs a service’s key, MonstarX shows a card to add it securely, or add it under Backend → Secrets. See Secrets.
  • Any language works. Write in the language you think in, and ask for the app in whatever language your customers speak.
How long can a request be?

Up to 100,000 characters, and up to 10 attached files. Most good requests are one to five sentences.

Do I need to use technical words?

No. Plain language works best. Say what people should be able to do, and MonstarX chooses how to build it.

MonstarX did something I did not ask for. What now?

Restore the version before it from Versions, then ask again and say what should not change. You can also ask in Chat mode why it made that choice.

Is it better to write one long request or several short ones?

For a new app, one request describing the whole app is fine — MonstarX plans it as a checklist. For changes, several short requests are better: each build is its own version, easy to check and easy to undo.

Can I write my requests in Japanese or another language?

Yes. Write in any language, and ask for the app in whichever language your customers use. MonstarX itself can be shown in English or Japanese — see Language.