Prompt engineering is the work of turning a requirement into instructions a model can follow, then testing whether those instructions hold up across realistic inputs.
The first draft is rarely the interesting part. The failures tell you what to change.
Write the requirement before the prompt
Define the job in ordinary language. What input will be available? What result does a person need? Which mistakes matter? Who approves the output?
If you cannot answer those questions, a longer prompt will not repair the task. For a support response, the requirement might be: draft a reply from the customer message and current policy, never promise an unapproved remedy, and mark cases that need escalation.
Build an instruction with visible parts
Use a task, context, boundaries and output format. Add examples when the desired distinction is hard to describe. Keep source material separate from instructions so the model can tell what it must follow and what it must analyze.
The basic prompt guide covers this structure. Prompt engineering adds repeatable testing and revision.
Create a small evaluation set
Collect representative examples before tuning the prompt. Include normal cases, missing information, conflicting facts and at least one case the model should refuse or escalate. Remove private data or use an approved test environment.
Write the expected properties of a good result. Exact wording is often unnecessary; you may care that every action has an owner, every factual claim has a source and no deadline appears unless it was supplied.
Test one change at a time
Run the same examples against the initial instruction and record errors. Revise one part, then repeat. If you change the model, prompt, examples and scoring at once, you will not know which change helped.
OpenAI’s official guidance recommends clear instructions and relevant context, but no general recipe removes the need to evaluate your own task. A prompt that works for short emails may fail on a long policy document.
Choose the right fix
If the model lacks a fact, provide the source or retrieval step. If it ignores a boundary, move the rule closer to the task and test an adverse example. If the requested format breaks, supply a concrete schema or example. If the task needs several independent decisions, split it into stages with checks between them.
Do not use prompt wording to solve a permission problem. An agent that can send email or change records needs tool restrictions and approval gates even when its instructions are excellent.
Keep a prompt record
Save the requirement, prompt version, evaluation cases, observed failures and review date. When the model or business rule changes, rerun the cases. This modest record turns a useful chat into a maintained work asset.
Use the Prompt Builder to assemble a first version and the Prompt Improver to spot missing brief fields. Neither tool can judge whether your facts are correct; that remains part of the review.