Prompt Engineering Studio

I kept rewriting the same system prompt from scratch, and I kept leaving something out of it. Usually the line that lets the model say it doesn't know. I would find that out later, from an answer that was wrong and sounded certain. So this page treats a system prompt the way it actually behaves — as a stack of labelled parts you can move around, rather than one long paragraph you reread until your eyes slide off it.

What the studio does

Twelve blocks sit down the left: Role, Context, Task, Constraints, Think Step-by-Step, Output Format, Few-Shot Examples, Self-Verify, Tone & Style, Grounding, Uncertainty, and a plain Separator. Drag one into the editor and it lands as an editable row with starter text already in it. Anything written in [CAPITALS] becomes a chip — click it, type the real value, and it is substituted through that block.

You can write blocks of your own, with a label, an emoji, a colour and a body, reorder them by dragging, and save the whole library to a blocks.json file on your own disk. Finished prompts export as .prompt JSON, a Python string literal, OpenAI or Anthropic messages JSON, Markdown, or plain text, and load back again. Undo goes back fifty steps.

Nothing is sent anywhere. There is no account and no server behind this page: the prompts you keep live in your browser's local storage and in files you choose yourself. There is a privacy note if you want the longer version.

Which blocks actually change the answer

They do not all pull the same weight, and it took me a while to notice which ones I was adding out of habit.

• Grounding and Uncertainty. These two do the most work of the twelve. Grounding confines the model to the material you paste in; Uncertainty gives it explicit permission to answer "I don't know". Without that permission a model fills the gap with something plausible, because filling gaps plausibly is the thing it was trained to do.
• Output Format. Describing the shape of the answer moves the model's effort off formatting and onto content. It also makes the output parseable, which starts to matter the moment you stop reading every answer by hand.
• Few-Shot Examples. Two worked examples beat a paragraph describing what you want. If you only have the patience to write one part of the prompt properly, write the examples.
• Task. Worth being blunt in. "Summarise this" and "Summarise this in six bullets for someone who will not read the document" are different instructions, and the second one is the job. The Do NOT line at the end of that template earns its place too — exclusions cut scope creep faster than more description does.
• Think Step-by-Step. Real gains on multi-step reasoning, arithmetic, anything where one wrong intermediate step poisons everything after it. Close to nothing on lookup and rewriting, where it mostly makes the answer longer.
• Role. The most quoted block and the weakest one. It does set vocabulary and register, which is worth something. But "with fifteen years of experience" does nothing measurable; it stays in the template because people expect to see it there, not because the years help.

About the health score

The panel scores a prompt out of 100: Role 20, Task 20, Constraints 15, Grounding 15, Uncertainty 10, Output Format 10, and 10 for filling in your placeholders, less two for each one still sitting there as a chip. The hallucination badge reads the same blocks from the other side — it watches for grounding, for constraints, and for the permission to be unsure.

It is a checklist with a number on it, and nothing more than that. A prompt can score 100 while saying nothing specific, and a sharp four-line prompt can score 45. Use it to catch what you forgot, not to decide when you are finished.

What it does not do

It does not run anything. There is no model behind this page, no API key to paste in, no usage bill and no queue. You assemble a prompt here and paste it into whatever you already use. Once the page has loaded it goes on working offline, which is a side effect of there being nothing on the other end rather than a feature I built.

Written guides

Most of what I learned building this ended up in ten longer pieces about writing system prompts — why instructions get ignored, how to stop a model inventing facts, choosing few-shot examples, when chain-of-thought is worth paying for, output formats a program can parse, one complete annotated prompt you can take, what the Role block actually changes, what belongs in the system prompt and what in the user message, giving the model permission to say it does not know, and how I test a prompt before changing it. They are collected under guides.