The first thing many builders try, when a model's output disappoints, is to reword the request. They add "you are an expert," or "please," or a promise of a tip, hoping the right phrase will flip a switch. Sometimes the output does change, which makes the habit feel like progress, but it is the slowest possible way to improve a feature, because it treats prompting as a hunt for magic words instead of what it is.
A prompt is a specification you write and revise, like a brief for a contractor, and the model produces better work when the brief names the role, the task, an example, and the rules, not when it lands on the right incantation.
The five parts of a working prompt
A strong prompt is rarely one clever line. It has parts, and naming them is most of the skill.
- The role and the job. One line for who the model is acting as and what it is for: "you are a support agent for a bike shop, answering customer questions." This is the run-time cousin of the project brief that steers a coding assistant, the one Working with AI as a builder covers, except this brief ships inside the product.
- The task, stated exactly. What to do with the input, in plain terms: "answer the question in two or three sentences." Vague tasks get vague output.
- An example. One short pair showing a good input and the answer you want. A single example does more than a paragraph of adjectives, because it shows the standard instead of describing it.
- The rules and the format. What the model must never do, and the structure you need back: "never invent a price; if you are unsure, say so." These are the lines that keep a feature out of trouble.
- The input. The user's actual data, kept separate from your instructions so the two never blur together.
Specific beats clever
The reliable lever is not a better adjective, it is more precision. "Make it more professional" gives the model nothing to act on, so the next attempt is a coin flip. "Use full sentences, no exclamation marks, and address the customer by name" names the behavior you want, so the output lands close. The same move that made your corrections land in the iteration loop makes your prompts land: describe the symptom, the place, and the behavior, not a mood.
When you can show instead of tell, show. One worked example of a good answer pulls the output toward it harder than any amount of "be helpful and thorough," and two or three examples pull harder still.
The prompt is a spec you keep
Because the prompt is a spec, it belongs in one place in your code, not retyped or scattered, so you can read it, improve it, and see what changed. When the model keeps making the same mistake, the fix is a line in the prompt, the same way a repeated wrong turn in a build belonged in your project brief. The difference at run time is that you cannot watch every output, so you change the prompt, then confirm the change helped by testing it against real inputs rather than trusting one lucky reply. Building that test is the subject of The Practice; keeping the prompt in one editable place is what makes the test possible.
Where prompting stops
Prompting is the highest-leverage thing you can do with a model, and it still has a ceiling. The model produces a response to whatever it is given, so a clear prompt makes a good answer far more likely without making it certain, and a user can supply input that pushes against your instructions. That is why the rule "never invent a price" lives in the prompt and also, for anything that matters, in code that checks the output before it ships. Prompting lowers the rate of bad output; it does not lock it out.
Try it now
No setup: Take a vague instruction you might give a model, like "summarize this email," and rewrite it as the five parts above: role, task, one example, rules, and the input slot. Run the vague version and the spec version on the same input in a provider console and read the two outputs next to each other. The gap is the whole lesson.
With your tools: In your project, ask Claude Code to pull your feature's prompt into a single place, then add one rule the model has been breaking and re-run the feature on a few real inputs to see whether the rule holds. If your tools are not set up yet, The Setup Clinic gets you there in one sitting. In Codex or Cursor the move is the same: move the prompt into one constant, add the missing rule, and re-run.
Chapter Summary
- Rewording a request with magic phrases is the slowest way to improve a feature, because prompting is specification, not incantation.
- A working prompt has parts: the role and job, the task stated exactly, one example, the rules and format, and the user's input kept separate.
- Precision beats adjectives: name the behavior you want instead of a mood, and show a worked example instead of describing the standard.
- The prompt is a spec, so keep it in one place in your code, improve it when the model repeats a mistake, and confirm the change by testing real inputs.
- Prompting is the highest-leverage move you have with a model, but it has a ceiling: a clear prompt makes a good answer likely, not certain.
- Keep your prompt rules, but back the ones that matter with code, because the model can drift past an instruction or be talked out of it.
- Next up, Get output you can build on makes the model's reply something your code can use every time.
Sources
- OpenAI, Anthropic, and Google prompt-engineering guides, 2026.