Prompt Engineering for Beginners: A Practical Framework That Works

A dependable prompt can be built from four parts: Goal, Origin material, Acceptance criteria and Layout. State what must be achieved, provide the information the answer should rely on, define what a good result must satisfy and specify the output format.

Not every task needs a long prompt. Add detail where mistakes are costly or preferences are difficult to infer. For a simple rewrite, audience and tone may be enough. For analysis, define the data, calculation rules, missing-data policy and desired table.

• Goal: the concrete outcome.
• Origin material: facts, text or data the model may use.
• Acceptance criteria: accuracy, scope, tone and constraints.
• Layout: headings, table, JSON, checklist or another usable format.

Weak: “Write a marketing email.” The system must guess the audience, offer, tone, length and evidence. Stronger: “Draft a 120-word email to existing café customers announcing Saturday delivery. Use only the facts below, lead with the customer benefit, include one call to action and do not invent a discount.” Then provide the verified facts.

The stronger version does not guarantee truth, but it reduces ambiguity and creates criteria you can check. The instruction to use only supplied facts is particularly useful for business content.

Explain who will use the result and what happens next. A summary for a senior manager differs from revision notes for a student. If style matters, provide a short approved example and describe which characteristics to copy. Remove confidential information first.

Examples are powerful but can also carry mistakes into the output. Use representative examples, label input and desired output clearly and avoid giving so many that the actual instruction becomes hard to find.

Tell the model to distinguish facts supported by the supplied material from assumptions. Ask it to mark missing information and request clarification rather than filling gaps. For research, require links or citations, then verify them independently.

A useful instruction is: “If the source does not support a claim, write ‘not established from the provided material’.” This makes review easier and discourages plausible filler.

For important tasks, separate planning, drafting and checking. First ask for an outline based on the sources. Correct the outline. Then request one section at a time. Finally, ask for a checklist-based critique. Do not rely on the model’s self-check as the only verification.

In data or coding work, ask for assumptions and a test plan before implementation. Run the resulting code and test edge cases. An explanation is not evidence that code is correct.

When the output is weak, identify the type of failure. Missing detail needs more context. Wrong format needs a concrete schema. Unsupported claims need stricter source boundaries. Excessive length needs a word or item limit. Change one aspect and compare the result instead of repeatedly saying “make it better.”

• What was wrong?
• Which instruction was missing or ambiguous?
• What evidence or example would resolve it?
• How will the revised output be checked?

“Goal: [specific outcome]. Audience and use: [who and why]. Source material: [paste or attach approved information]. Requirements: [must include]. Constraints: [must not include, length, tone, privacy]. Output: [format]. Uncertainty: identify missing information and do not invent facts. Before answering, ask up to three questions if a missing detail would materially change the result.”