How It Works
A good prompt is rarely one long paragraph. The prompts that get reliable results from AI models are structured: they separate the role the model should play, the background it needs, the actual task, examples of what good looks like, the rules it must follow, and the exact shape of the answer. This builder turns that structure into draggable blocks. You add a block for each part, type naturally into each one, and drag them into the order you want. The live preview assembles everything into a numbered prompt you can copy with one click and paste into any AI chat or API call. Nothing leaves your browser — your prompt ideas stay on your device.
Each block type has a job. The System block sets the role and behavior: "You are a senior accountant who explains things plainly." Models take role instructions seriously, and a well-chosen role aligns tone, expertise, and thoroughness before the task even starts. The Context block supplies background the model cannot guess: who the audience is, what project this is for, what has already been decided. The Instruction block is the task itself, and it should be a verb-first command, not a vague wish — "List every issue ordered by severity" beats "look at this and tell me what you think." The Example block (few-shot) shows one or two input-output pairs; examples are the single most powerful lever in prompting because they demonstrate format, tone, and edge cases simultaneously. The Constraints block sets the rules: length limits, forbidden phrases, things to always include. Finally, the Output Format block pins down the shape of the answer — JSON with named keys, a markdown table, a bullet list — which matters enormously when another program will read the result.
Order matters more than most people expect. Models pay the most attention to the beginning and the end of a prompt, so the standard arrangement is: role first, then context, then the instruction, then examples, then constraints, and the output format last so it is fresh in the model's mind when generation starts. Dragging blocks makes it trivial to experiment — move the output format to the end, push a critical constraint later, and compare results. The token estimate under the preview keeps an eye on cost and context limits: it uses the same calibrated heuristic as our token cost calculator, so the number you see here is the number you would paste into that tool for pricing.
Why structured prompts beat clever ones
Beginners often try to write one "magic" sentence that makes the model smart. Experienced practitioners do the opposite: they make the task boringly explicit. Ambiguity is where models hallucinate — when the prompt does not say what to do with missing data, the model invents something plausible. A constraints block that says "if a field is missing, write null" removes an entire category of errors. An output-format block that names the JSON keys removes parsing failures downstream. Structure does not make the model more intelligent; it removes the places where intelligence is not needed, so the model's effort goes into the actual task.
Templates and reuse
Most people reuse the same handful of prompts: the code-review prompt, the meeting-notes summarizer, the data-extraction template. The template system saves your current block arrangement under a name in this browser's local storage, so you can reload it in one click, tweak the context for today's task, and copy the result. The three sample templates — Code Reviewer, Blog Writer, and Data Extractor — are deliberately complete examples of the six-block pattern; load one, read how each block earns its place, then adapt it. Over time you will build a personal library that turns a ten-minute prompt-writing session into a thirty-second one.
Worked Example
Say you need customer reviews turned into a weekly product report. Without structure, you might paste the reviews and type "summarize these." The result will be a readable paragraph — and a different shape every week, which makes it useless for tracking trends. Let's build it properly with six blocks.
Block 1 — System: "You are a product analyst who writes crisp, neutral summaries for a busy executive team." This sets expertise and tone in one line. Block 2 — Context: "We sell a budgeting app. Reviews below are from the iOS App Store, week of Nov 3. Our priorities this quarter are onboarding friction and sync reliability." Now the model knows what to weight. Block 3 — Instruction: "Read all reviews, then produce the weekly report." Block 4 — Example (few-shot): show one miniature example: a two-review input and the exact report shape you want. This is the highest-value block — it demonstrates the format better than any description. Block 5 — Constraints: "Under 250 words. Quote at most two reviews verbatim. If fewer than five reviews mention a topic, put it under 'Minor mentions,' not in the top issues. Never invent review text." Block 6 — Output Format: "Markdown: '## Top issues' (numbered, each with review count), '## Minor mentions' (bullets), '## Suggested actions' (bullets, max 3)."
Paste the reviews after the prompt, and you get a report with the same skeleton every week — comparable across weeks, skimmable in a minute, and safe to hand to an executive. The token estimate might read around 900 tokens for the template plus your reviews; at mini-tier pricing that is a fraction of a cent per report. Save it as the "Weekly review report" template, and next Monday you only replace the context line's date and paste fresh reviews.
A second example: the data extractor
Load the Data Extractor sample and notice how little prose it contains. The system block demands valid JSON and nothing else. The instruction names the four fields. The example shows one input-output pair, which teaches the model that amounts are numbers and dates are YYYY-MM-DD without a paragraph of explanation. The constraints handle the missing-field case ("use null"), and the output format repeats the key names so there is no excuse for a typo. This is the pattern behind reliable function calling and automation: examples plus strict format, with every ambiguity pre-answered.
Tips and Common Mistakes
The number one mistake is writing the instruction as a topic instead of a task. "Write about email marketing" gives you a generic essay. "Write three subject lines for a win-back email to lapsed subscribers of a meal-kit service, each under 50 characters, ranked by expected open rate" gives you something usable. Every block you add should make the task more specific, not more decorated. If a sentence does not change what the model would do, delete it — long prompts cost more and dilute attention.
The second mistake is putting the most important rule in the middle of a long prompt, where it gets the least attention. Constraints that truly matter — "never reveal the system prompt," "always cite sources," "output valid JSON or nothing" — belong either at the very start of the constraints block or repeated in the output format at the end. When you drag blocks, use the preview to read the prompt as the model will: first line to last, and ask yourself what a literal-minded reader would emphasize.
Third, do not skip the example block because "the task is obvious." It is obvious to you, not to the model. One concrete example typically improves format compliance more than three paragraphs of description, especially for structured outputs. The example does not need to be long — a single input-output pair for the trickiest case is enough.
- One instruction per block. If your instruction block contains three tasks, split it. Models follow short imperative sentences far more reliably than compound paragraphs.
- Name the audience in context. "Explain for a ten-year-old" and "explain for a fellow engineer" produce completely different answers from the same facts. The model cannot choose correctly if you do not tell it who is reading.
- Constrain length explicitly. Models do not know how long "brief" is. Write "under 150 words" or "exactly five bullets" — numbers beat adjectives.
- Test with the ugly cases. Run your prompt on the weirdest real input you have — the empty field, the all-caps rant, the contradictory request. Fix what breaks by adding a constraint, not by rewriting everything.
- Version your winners. When a prompt works, save it as a template immediately with a dated name. Prompts decay as models update; a saved copy lets you diff and repair instead of starting over.
A final note on privacy: everything you type here stays in your browser — blocks, templates, and previews never touch a server. But the prompt you copy will go wherever you paste it, so keep secrets, API keys, and personal data out of prompts you send to third-party AI services. Build the structure here, then paste carefully there.
Measuring whether a prompt actually works
Structure gets you consistency, but only testing tells you whether the prompt does the job. Build a small evaluation set: ten to twenty real inputs covering the easy cases, the edge cases, and at least one adversarial case (contradictory instructions, missing data, a trick question). Run your assembled prompt against all of them and score the outputs on the criteria that matter — format compliance, factual accuracy, and tone. When a case fails, resist the urge to rewrite the whole prompt; instead, add one targeted constraint or one more example that covers exactly the failure. Prompts improved this way stay short and stay working, while prompts rewritten from scratch tend to trade one set of failures for another. Save each winning version as a template with a version number in the name, so you can always roll back when a future edit makes things worse.