A prompt is not just a question
For a useful workflow, the prompt usually needs the task, the audience, the available evidence, the constraints, and the shape of the desired answer. “Write a post about our product” leaves too much hidden. “Turn these approved product facts into three LinkedIn drafts for operations leaders; do not invent metrics” gives the model a job it can follow.
The parts worth designing
- Instruction: what the model should do.
- Context: the facts or source material it may use.
- Constraints: what it must not invent or change.
- Output contract: headings, fields, JSON, table, or length.
- Examples: a good and bad result when the distinction is hard.
- Evaluation: how a human decides whether the result is acceptable.
What prompt engineering cannot do
A better prompt cannot make missing facts current, turn a weak source into evidence, or remove the need for review in a high-risk workflow. If the problem is missing knowledge, use retrieval or a tool. If the problem is unstable requirements, fix the task definition first.
A useful test
Run the prompt against several ordinary examples and at least one awkward case. If the result only works when you keep adding exceptions, the workflow may need a better input contract or a different system design.