Writing prompts
How to phrase a request so Modulify builds the thing you actually wanted.
On this page
Modulify is not matching keywords. It reads your message, the conversation so far, and the project files, then makes real decisions about structure, copy and layout. What you write is the only steering you get, so it is worth writing well.
It builds the whole thing, not a mockup
A request is treated as a request for a working result. Buttons do something, forms submit and validate, routes connect, loading and empty states exist, and pages get metadata. There is no placeholder architecture that looks finished and does nothing.
That cuts both ways. Ask for "a contact section" and you get a working form, not a picture of one. If you genuinely want a static block for now, say so.
Say who it is for and what it must do
The single biggest lever is naming the purpose and the audience rather than the visual style alone. "Modern and clean" describes almost every website. "A booking page for a two-chair barbershop, where the main job is picking a time" describes one.
A pricing section with three tiers.
Middle tier highlighted as the recommended one.
Annual toggle that shows the monthly equivalent underneath.Concrete constraints beat adjectives. Number of items, what goes above what, what must stay, what should never happen.
Point instead of describing
Describing a specific element in words is slow and easy to get wrong. Two features exist so you do not have to.
Click the element in the preview with the select tool and a chip appears in the chat box at your cursor, so you can write around it: "make this [Heading #1] shorter and move it below the image". See Select an element.
Type @ to reference a project file by name, and # to place a file you already attached. Both drop into the sentence exactly where the thing belongs. See Attachments and context.
The position of a chip is meaningful. "Make the [Link #1] in [Section #2] match [Image #1]" tells Modulify which phrase points at which thing, with no ambiguity left to resolve.
Follow-ups inherit the conversation
There is one chat per project and it runs continuously, so you never restate the whole site. "Now make it responsive" is a complete request.
This also affects how the work is sized. When the model is set to Auto, Modulify classifies the request using the last six turns, not just the words you typed, so a three-word follow-up that continues heavy work is still treated as heavy work. See Models and effort.
Very long conversations get compacted automatically, and you will see a marker in the transcript where it happened. Detail from far back may need restating.
One clear request beats five buried ones
A message with five unrelated asks in a paragraph is harder to get right than five messages, and it is harder for you to tell which part went wrong. Group changes that belong together, split changes that do not.
You do not have to wait between them. Send the next one while the first is still running and it joins the message queue.
It will plan and it will ask
For work with several coordinated steps, Modulify writes a task list first and shows it above the chat box as 3/7 tasks, ticking items off as it goes. That panel is your view of what it decided to do, and it is worth a glance early rather than at the end.
When a choice would materially change the result, it stops and asks. A question panel appears above the chat box with two to four short options. Click one, or type a free text answer instead. It waits rather than guessing, so a run that looks stalled is often a question you have not answered.
For anything large or ambiguous, switch the mode picker to Plan and read the approach before it touches anything. See Plan and Build modes.
What it does not know
Modulify knows this conversation, the turn context and the project files. It does not know your name, your account, your plan, your credit balance, your other projects, your teammates or your domain status. Asking it about any of those gets you an honest "I do not have that" and a pointer to the right tab.
It also does not use git. Version history is a real feature in the Versions tab, so ask there rather than asking chat to roll back a commit.
Things to say differently
Some requests fail because of what is being asked for, not how it is phrased.
- Secrets. Never paste an API key into chat. Ask for the integration, and Modulify creates the key in the Secrets tab with the placeholder
REPLACE_MEfor you to fill in. - Env files. Asking for a
.envfile gets redirected to Secrets every time. That is deliberate: a.envin the project would end up in your GitHub repo. - Video, animation and vectors. The image tools produce one still, flat picture. They cannot make a video, an animated GIF, an SVG, an
.icofavicon, or a dependable transparent cutout. Asking for one gets you a plain explanation and the real alternative. - Paid actions. Generating or editing an image spends credits, so Modulify asks before doing it when you did not clearly request it. "Add some images" is read as stock photography, which is free.
Change how it builds, not just what it builds
Two levers sit outside the sentence you type.
Skills are reusable instruction sets, like brand voice, design direction or SEO, attached to the project. They shape every decision made while building, so you stop repeating the same correction.
Connectors give it access to an outside app while it builds, so "pull our team from Notion" becomes possible instead of hypothetical.
Next
- Attachments and context covers images, files and chips.
- Plan and Build modes explains when to plan first.
- Models and effort covers what each setting costs.