Start here
Prompt Engineering in plain language
A useful prompt behaves like a clear work brief: it describes the task, supplies the relevant material and states what a satisfactory result looks like. The reader’s needs matter too. An executive summary and an engineering investigation require different detail even when they use the same source.
The process starts with success criteria. If you cannot tell whether an answer is good, rewriting the prompt can become guesswork. Keep representative examples and compare revisions against them. Some failures need better data, tools or a different model rather than more instructions.
How it works
Specify
Define the task, audience, source material, output format and treatment of missing information.
Test
Try typical, ambiguous and incomplete inputs. Inspect correctness and usefulness against explicit criteria.
Refine
Change a meaningful part of the brief, compare outputs and keep the revision only when it improves the task.
Illustrative example · Fictional data
A meeting-summary prompt that can be checked
- Input
- Fictional note: “Dev will review the draft on Friday. Pricing is unresolved.” Weak request: “Summarise this.”
- Process
- Improved request: “From the note below, list decisions, actions, owners and deadlines. Use only the note. Mark missing values as not specified. Keep unresolved issues separate.”
- Expected output
- Expected action: review draft; owner: Dev; deadline: Friday. Pricing belongs under unresolved issues, with no invented decision.
- How to check it
- Verify fields against the note. Repeat with an absent owner and conflicting dates. A neat table is useful only if its contents are supported.
Where it helps
- Producing consistent drafts for a defined audience.
- Extracting or restructuring supplied information.
- Testing reusable team workflows before sharing a prompt template.
Prompt, workflow or training?
- Prompt
- Instructions and context for an interaction. Useful when the main problem is ambiguity.
- Workflow
- Multiple steps, sources or tools with checks between them. Useful when one response cannot reliably complete the task.
- Fine-tuning
- Additional model training. Consider only after defining and evaluating the recurring behaviour needed.
A few-shot example with an output contract
For a fictional support classifier, define three labels: billing, delivery and other. Supply examples: “I was charged twice” → billing; “My parcel has not arrived” → delivery; “Please change my display name” → other. Then ask for a label and a short evidence phrase from the new message. Choose examples that clarify boundaries, not only easy cases.
Keep test messages separate from demonstrations. Include ambiguous requests and multiple intents. If the application requires one label, define how to handle ambiguity; if it allows several, validate that every returned label belongs to the permitted set. Valid JSON does not establish a correct classification.
Application instructions versus task data
Stable application instructions define the task, boundaries and response contract; the user supplies the current request. Retrieved documents and tool results are evidence to interpret, not authority to rewrite those instructions. Providers expose different message roles and precedence rules, so implement against the API you actually use.
Version prompts with the evaluation set and record the model/configuration used. A change that fixes one example can damage another. Validate structure in code, check facts against sources and keep permissions outside the prompt: saying “do not delete” is not a replacement for denying deletion capability.
Related reading and learning pathways
Common pitfalls
- A role instruction does not give the model professional credentials or access to evidence.
- Longer prompts can introduce conflicting requirements. Keep the priority and output criteria clear.
- A prompt that works on one example may fail on missing information, a new language or a model change.
Put the idea to work
Try it yourself
Use the improved meeting prompt with three notes: one complete, one missing an owner and one with conflicting dates. Score whether it preserves facts, exposes uncertainty and follows the requested structure.
Common questions
Does prompt engineering require coding?
No for many workplace tasks. Code becomes useful for automated evaluation, application integration and repeated processing. Most employees can improve results by writing clear instructions, giving context and examples and asking for a specific output format. Scripting helps when the same prompt runs at scale.
Is there one best prompt framework?
No universal framework fits every task. Clear purpose, relevant context, useful examples and explicit evaluation are more transferable than a fixed acronym. Structures such as role, task, context and format can be useful checklists. Test prompts on real examples and keep the version that performs best for your task.
Can a prompt make every answer accurate?
No. Accuracy also depends on the model, available evidence, task and surrounding checks. Prompts cannot supply facts that were never provided or retrieved. Provide the source material, ask for answers grounded in it and check important outputs. For calculations or live data, connect tools rather than relying on the model alone.
Your next step
Continue learning
Connected concepts
Sources and further reading
Examples on this page are teaching exercises using fictional information. They are not client case studies or measured outcomes.