prompt-engineering.siA prompt is a working brief
A model cannot reliably recover requirements you never supplied. “Improve this” leaves the target open: shorter, more persuasive, more accurate, or more complete? Begin by stating what the output must let a person do. Then provide the information needed to produce it.
This does not mean every request needs an elaborate template. A simple rewrite may need one sentence of instruction and the text. A comparison involving conflicting documents needs sources, criteria, and a rule for uncertainty. Add structure in response to a real failure or a known requirement.
A prompt also cannot create access. Requesting current information does not give an offline model a browser. Asking for a spreadsheet analysis does not attach the spreadsheet. Check available files and tools before refining the wording.
Six elements that make a brief usable
| Element | Question to answer |
|---|---|
| Task | What concrete deliverable should exist? |
| Context | What facts or background change the answer? |
| Audience | Who will use this, and what do they already know? |
| Constraints | What must be preserved, excluded, or bounded? |
| Output | What structure will make the result usable? |
| Acceptance | How will you recognize a correct result? |
This six-element checklist is a site-specific organizing aid, not a scientific quality score. Some tasks need fewer elements. The builder counts whether fields are filled; it does not measure truth or model performance.
Worked example: a project update
Weak request: “Write a professional project update.” It leaves the facts, reader, purpose, and definition of professional unspecified.
Write a project update for the launch sponsor. Facts: design is approved; testing has found two payment defects; launch is planned for Friday; the team needs a decision on a limited rollout by Wednesday. Use three headings: Status, Decision needed, Next action. Keep it under 150 words. Do not claim the defects are fixed or invent their severity. Distinguish the scheduled launch from a confirmed launch. Success: the sponsor can see the decision and its deadline without reading twice.
The improvement is not the phrase “launch sponsor.” It is the observable contract: known facts, decision deadline, headings, and claims the model must not invent. A valid answer should preserve the difference between a plan and a completed event.
Use a short test-and-revise loop
- Write the smallest brief that contains the requirements.
- Try it on one ordinary case and one awkward case.
- Record the specific failure: invented owner, wrong format, missing exception, or unclear decision.
- Change the instruction connected to that failure.
- Retest both cases to see whether the change created a new problem.
For the project update, an awkward case is notes with no decision deadline. The prompt should then label the deadline as missing. If it supplies Wednesday anyway, it has copied an incidental fact from the example rather than following the evidence rule.
Know what better wording cannot solve
A clear prompt does not guarantee a correct answer. Missing sources, insufficient permissions, tool failures, and an unsuitable model can dominate the result. When your output will affect a consequential decision, review the evidence and assumptions yourself.
Start with the prompt builder, then use the evaluation guide to check whether your changes help. The goal is a repeatable working process, not a collection of impressive phrases.
Further reading
Official documentation for the general techniques discussed here. Worked examples and checklists on this page are original instructional material.