Prompting
How to write prompts that get you closer to what you want, faster.
Be specific
The more detail you give, the better the output.
Include what the user sees, what happens when they interact with it, and what's explicitly out of scope.
Start small
Describe the smallest version of your idea that's still useful. Build the core, confirm it works, then expand. It's much easier to add features incrementally than to correct a large build that went in the wrong direction.
One change at a time
Each follow-up message should ask for one thing. Multiple changes in a single message often produce unpredictable results. If something breaks, one change per message makes it easy to trace the cause.
Use Discuss mode before big changes
Before any prompt that could affect a large portion of your app, switch to Discuss Mode first. Ask MonstarX how it would approach the change, without triggering a build. Send your prompt once you're aligned.
Name things precisely
When you're changing something that already exists, describe it exactly as it appears.
| Vague | Specific |
|---|---|
| "Fix the button" | "Change the sign-up button on the landing page to blue (#2563eb)" |
| "Fix the header" | "The nav bar overlaps the hero on mobile. Fix the z-index so the nav stays on top." |
First prompt template
Use this structure when starting a new project:
Build [a short description].
Users can:
- [action 1]
- [action 2]
Requirements:
- [any services or constraints]
Out of scope:
- [what not to include in this version]Bug report template
Use this when something's broken:
Bug: [what is broken]
Steps: [what I did, and what happened]
Expected: [what should have happened]
Do not change: [what is working correctly]Quick reference
- Starting a project — Be specific, set scope, list what's out of scope
- Making a change — One thing at a time, name it precisely
- Before a big change — Use Discuss mode first
- Something broke — Report the bug with steps to reproduce
- Stuck after 2-3 tries — Use Discuss mode and ask for a different approach