Prompt engineering from zero: write a formal letter, not a text message
A language model can't read your mind. Everything you'd take for granted in a casual chat has to be stated outright in the prompt — the six components that make a good one, and the five mistakes beginners make.
The Felesh team6 min
A letter, not a text message
When you message a close friend, you don’t explain everything. They know you, they remember the thread of the conversation, and they catch your meaning from the smallest hint. Now imagine writing the same request as a formal letter: you introduce yourself, you make the subject clear, and you state exactly what you want and expect. Nothing is taken for granted.
A large language model belongs to the second category. It doesn’t know you, it can’t see your mental assumptions, and it cannot fill unspoken gaps with the right guess. That is why the first principle of prompting is to be explicit rather than implicit. Every rule you hold in your head has to be written down; every behaviour you expect has to be described. Like that formal letter, a good prompt should stand on its own — complete, and dependent on no unstated knowledge.
A friend fills the gaps from what they already know; the model has only the page, so everything unsaid has to be written into the prompt.
The six components of a good prompt
A well-structured prompt is usually built from six components. You won’t always need all six, but it helps to know what each one does and which question it answers:
Component
The question it answers
Role
Who am I? The model’s identity and the scope of its responsibility
Context
What do I know? What the model needs to know about its situation
Task
What should I do? The concrete steps and their order
Constraints
Where are my limits? Rules, exceptions, and how to behave safely under uncertainty
Examples
How should I do it? Patterns that guide the model when description alone isn’t enough
Format
How should I respond? The exact structure of the output
The first two components set the model’s identity and awareness: Role says who the model is and what is and isn’t in its remit; Context gives it what it needs to decide — and no more. Task and Constraints are the heart of the prompt: break the work into clear steps and write the rules out plainly, including what the model should do when it is unsure. The last two are the most optional: reach for Examples only when description alone doesn’t carry the point, and specify Format when the output has to follow a particular structure.
One real prompt split into its six components: Task and Constraints carry the work, Role and Context set the scene, and Examples and Format are added only when the output needs them.
Five mistakes beginners make
1. Writing vaguely. “Summarise this” can be read a dozen different ways. Instead, write: “Summarise it in at most three sentences, in plain language.” The more precise the instruction, the more stable and predictable the output.
2. Framing by negation instead of instruction. “Don’t use jargon” works less well than “write in plain, everyday language.” Telling the model what to do is always clearer than listing what it must not do.
3. Overloading it with information. Any sentence the model doesn’t need is noise, and it breaks the model’s focus. Give it only what the task at hand requires — not a long history, and not irrelevant side detail.
4. Leaving no room for doubt. If the model has no way to say “I don’t know,” it fills the gap with a guess — and that is exactly where hallucination begins. Give it explicit permission: “If you don’t have enough information, ask instead of guessing.”
With no way to say “I don't know”, the model fills the empty slot with a guess, and that is where hallucination starts; one line of permission turns the guess into a question.
5. Inconsistent vocabulary. If you call one concept “user” in one place and “customer” in another, the model assumes they are two different things. Choose a single word for each concept and stay loyal to it throughout.
Each beginner mistake and its rewrite: the fix is always to say more precisely what you want, not to add more words.
Start simple
The first prompt is rarely the best one. Begin with a simple version, test it against a few real scenarios, find where it slips, and fix only those parts. Complexity should emerge in answer to a real need, not be imposed from the start. Writing prompts is less a talent than a habit: be clear, assume nothing, and sharpen your structure with each round of testing.
Start with a two-line prompt, run it on real messages, and change only the line that slipped; the rest stays as it was.
