By Muhammad Faraz · 3 min read
Describe the job
A prompt should make the intended result understandable. Instead of asking for a better website, specify the audience, the page’s purpose and the information already available. If the task is to summarize notes, say which decisions and open questions matter. Avoid including background that has no bearing on the output.
Provide constraints and examples
State the required format and any facts that must remain unchanged. An example can clarify what you mean by a concise summary or a useful category. Keep examples representative rather than idealized. If you have no evidence for a requested fact, tell the system to identify the gap instead of filling it creatively.
Separate drafting from action
A generated response and a business action have different consequences. Preparing an email draft should not automatically mean sending it. Describe which outputs need review and which data may be used. In a product, make that distinction visible through the interface rather than depending on an invisible instruction alone.
Evaluate and refine
Save a small collection of realistic inputs and compare results after changes. Look for improvements across the collection, not just one successful answer. A longer prompt is not automatically better. Remove instructions that conflict, repeat each other or do not affect the task, and keep the prompt understandable to the team maintaining it.
A concrete before-and-after brief
“Write content for my app” leaves the audience, screen and purpose unspecified. A clearer request is: draft onboarding copy for a scheduling app used by small service teams; explain that managers create shifts and employees confirm availability; use three short screens and avoid promising automatic payroll. This gives the model a task and boundaries. You can now assess whether the result explains the workflow, stays concise and avoids introducing a feature the app does not offer.
Use a repeatable prompt structure
Describe the role of the output, the facts it may rely on, the audience and the required format. Add constraints that protect the meaning, such as preserving product names or identifying missing information. Keep a place for variable input so the prompt can be reused without accidentally retaining a previous customer’s details. Version important changes with a short explanation. This makes the prompt easier for another teammate to maintain and prevents a successful one-off experiment from becoming an undocumented dependency.
Diagnose the kind of failure
An incorrect answer may come from missing context, an ambiguous instruction or an inappropriate task. Do not respond to every failure by adding more emphatic wording. If the source material lacks a delivery date, the right improvement is to surface the missing date, not to demand a more accurate guess. If the output format is inconsistent, clarify the structure and validate the result. Different failures call for different fixes.
Finish with a reviewable output
Ask for an answer the next person can inspect. For a requirements draft, separate confirmed facts, assumptions and questions. For a summary, preserve decisions and their owners. For a code task, describe the expected behavior and verification needed. Avoid requesting hidden reasoning as a substitute for evidence. A useful prompt produces an artifact that can be checked against the original task, with uncertainty visible where it affects the next decision.
