Specify the task, supply relevant context, define the expected output, and test representative cases. Keep application permissions outside the prompt.
1. Define an output someone can review
Start with the person who will use the result. A support agent may need a short suggested reply plus the policy passages that support it. A finance reviewer may need extracted invoice fields and a list of uncertain values. These are more useful contracts than “act as an expert.”
Write down the facts the assistant may use and what it should do when a required fact is missing. If it cannot find a refund deadline in approved information, it should ask or escalate rather than invent a policy. Keep that behavior explicit and include a missing-information case in your tests.
2. Separate instructions from supplied material
Organize the prompt into the task, available information, output format, and handling of uncertainty. Mark source material as material to analyze. Retrieved documents and customer messages can contain requests that should not become instructions for the application.
Avoid placing passwords, private API keys, or unrelated customer information into a reusable template. Supply only the context needed for this request and apply access checks before constructing it. Clear delimiters improve organization, but they are not a guarantee against malicious instructions in data.
Task: Draft a concise support reply for a human reviewer.
Use only the approved policy excerpts and authorized order facts supplied below.
If the information does not answer the question, list what is missing.
Do not claim that a refund, message, or record update has been completed.
Return:
- Suggested reply
- Supporting source identifiers
- Missing information or review questions
Customer question: {{question}}
Approved policy excerpts: {{policy_excerpts}}
Authorized order facts: {{order_facts}}3. Use examples that teach a distinction
An example should demonstrate a behavior your instructions alone do not explain well. Show a supported answer, a request that needs clarification, and a case that must go to a person. Use sanitized examples that resemble the actual language and document quality your users bring.
Keep examples internally consistent. If an instruction says to name missing evidence but every example confidently fills gaps, the template sends conflicting signals. Separate examples used to develop the prompt from a held-out test set, or you may optimize the demonstration without learning whether the prompt generalizes.
4. Validate the output where it is consumed
If another service needs structured fields, use the provider’s supported structured-output features where appropriate, then validate the result in application code. A syntactically valid object can still contain a nonexistent customer, an impossible date, or a total that does not reconcile.
For human-facing drafts, make review easier by separating proposed text from evidence and uncertainty. Do not treat a model’s confidence statement as a measured probability. A reviewer should see the underlying information and be able to edit or reject the suggestion.
5. Improve one failure category at a time
Record the prompt version, model configuration, source set, and evaluation cases. Group failures: wrong source, missing requirement, unsupported claim, formatting problem, or incorrect tool choice. These groups need different fixes; adding another paragraph of instructions does not repair a missing source document.
Change one relevant part, rerun the same cases, and check for regressions. Measure whether reviewers spend less time correcting the output without losing necessary information. A short, specific prompt with good context can be easier to maintain than a long template that repeats the same demand in different words.
6. Frequently asked questions
Does a longer prompt produce a better answer?
Not necessarily. Additional instructions can add useful context or create contradictions. Judge the result against representative cases, including missing information, rather than by prompt length.
Should every prompt say not to hallucinate?
A general instruction is not enough. Supply appropriate evidence, define an unsupported-answer behavior, and evaluate whether claims are actually supported by the available material.
Where should we keep prompt versions?
Use a controlled versioning process alongside the application configuration. Record the version used for each evaluation and deployment so a behavior change can be investigated or rolled back.
7. Related articles and next steps
Bring representative inputs, expected outputs, and the systems involved. Discuss your requirements with OdooMatrix.