OurSharedCode › Prompt Engineering Studio
These are the things I worked out while building the Prompt Engineering Studio and using it on real work. They are about system prompts specifically — the instructions you write once and then live with — rather than about chatting with a model.
Each one is a technique I use, an honest account of where it stops working, and the prompt text before and after. Where I think a popular idea is oversold I say so, and where I have contradicted myself between two of these pages I have left the contradiction visible and explained it.
Six causes that account for nearly all of it: contradictions you wrote on different days, instructions buried in the quiet middle of a long prompt, negations, vague quantifiers, examples that overrule the prose, and rule lists nobody could follow. Ends with the order I debug in.
"Use only the information provided" is the right idea and leaks in four places. Delimiting the source, giving refusal a defined form, splitting the half of the task that cannot be grounded, and requiring quotes so the output can be checked by a machine rather than trusted.
How many to use, why to choose the awkward cases over the typical ones, and the accidental patterns — length, subject, label balance, order — that your examples teach without your noticing. Two tests that catch it.
Where "think step by step" genuinely pays, where it only adds latency and a parsing problem, what the printed reasoning is and is not evidence of, and why reasoning models change the calculation. Includes the twenty-minute experiment that settles it for your task.
Getting JSON out of a model is easy; getting the same JSON on the two-hundredth call is a different job. Literal schemas, defined empty values, giving the urge to explain somewhere to go — and the five things the parser has to do because no prompt gets you to a hundred per cent.
One complete working prompt for support-ticket triage, built a block at a time with the reason for every line — including the four techniques left out on purpose, which is the part most worth copying.
A persona sets the register and the vocabulary of an answer and not much else. Why the years-of-experience clause does nothing, why the studio still scores the block at twenty points, and the version of it that describes the reader instead of the author.
The system prompt is what you would edit for a release; the user message is what you would edit for a request. Where dates, pasted documents, examples and the format reminder go, and why the system prompt is neither a stronger instruction nor a security boundary.
One line of permission changes the cost of admitting doubt and nothing about what the model knows. Why stated confidence levels are weaker than they look, four ways to make a guess look different from a fact on the page, and the class of error none of them catches.
Every edit fixes one thing and may quietly break another. Twelve saved inputs with yes-or-no checks instead of golden outputs, run before and after each change. What goes in the twelve, how to write a check, and what the set will never tell you.